Image Image Image Image Image
Scroll to Top

Topo

script

10

abr
2012

Sem Comentários

Em Blog

Por Allison

Como criar um aviso de dados não salvos

Em 10, abr 2012 | Sem Comentários | Em Blog | Por Allison

Sabe quando você está escrevendo um e-mail e tenta sair de tela, o browser te da um aviso, comunicando a possível perda de dados? Pois é sobre isso que vamos falar. O Gmail e o Rally fazem isso, mas muita gente ainda não sabe como isso é feito de fato.

Este recurso é muito interessante e pode evitar muita dor de cabeça por parte da pessoa que estiver utilizando o seu sistema. No meu caso, este recurso foi aplicado a um CMS. A finalidade da implantação era para que os jornalistas fossem avisados quando algum dado no formulário fosse alterado, e que se o usuário intencionalmente (ou não) tentasse mudar de página, o dado seria perdido. Se tratando de um CMS focado para jornalistas, no qual o conteúdo digitado é extremamente importante, todos recurso que for desenvolvido para evitar perda de conteúdo é extremamente bem-vindo.

onBeforeUnload Event

O evento onbeforeunload não tem uma finalidade exclusiva para ele. É um evento como outro qualquer, que é invocado sempre que o usuário tenta sair da página atual, mas quando ele não está setado, simplesmente nada acontece. O evento responsável por pedir para que o usuário confirme ou não a mudança de pagina é o evento onbeforeunload. Sempre que ele é setado, você vai ver um confirm dialog, igual o da imagem abaixo.

O problema

Se fosse só setar o efeito e ele fizesse todo o resto, seria fácil, não? Mas não é assim. Temos que fazer um script que peça a intervenção do usuário nas seguinte situações:

Ao fechar aba/navegador;

Ao clicar em qualquer outro link, senão o submit do formulário;

O alerta deve aparecer somente se algo for alterado no formulário.

A Solução

$(function(){
  var formObject = $('.new_materia, .edit_materia');
  formObject.data('original_serialized_form', formObject.serialize());

  $(':submit').click(function() {
    window.onbeforeunload = null;
  });

  window.onbeforeunload = function() {
    if (formObject.data('original_serialized_form') !== formObject.serialize()) {
      return "As mudanças deste formulário não foram salvas. Saindo desta página, todas as mudanças serão perdidas.";
    }
  };
});

Como funciona?

Utilizei o $.data() do jQuery porque eu não gosto do var para declarar variáveis globais;

Utilizei o $.serialize() do jQuery para serializar o formulário para comparar o estado do formulário no futuro. E foi a forma mais inteligente que encontrei para identificar se algo realmente foi mudado;

Por default, eu seto o evento onbeforeunload e dentro dele eu verifico se algo foi mudado no formulário;

O único caso em que eu tenho que remover o evento onbeforeunload é quando existe a intenção de salvar o dado. Aí eu utilizei o :submit com evento $.click() para remover o evento e cancelar o alerta, caso houvesse a intenção de salvar o formulário.

Bom, é isso!

Tags | , , , ,

23

nov
2011

Sem Comentários

Em Blog
HTML

Por Allison

Como Criar um PopUp HTML para Captação de Email no Site!

Em 23, nov 2011 | Sem Comentários | Em Blog, HTML | Por Allison

Hoje vou mostrar como criar um PopUp HTML para Captação de Email através do FeedBurner, como o utilizado aqui no CriarSites.com. Um popup simples e eficaz para aumentar consideravelmente sua lista de email.

A ideia é criar algo simples e chamativo para atrair e fisgar a atenção dos seus visitantes.

O único Problema é que muitos métodos para inserir um popup no site são pagos, e isso dificulta muito para quem esta começando um novo site e não dispõe de muitos recursos financeiros para investir.

obs: Gostaria de deixar uma observação que esse código não foi produzido originalmente por mim, e não tive acesso a quem foi o criador, apenas consegui boa parte do código na internet e fiz algumas adaptações como mostro abaixo. Caso alguém conheça o criador, por favor, deixe nos comentário para dar os créditos a quem mereça por esse fabuloso script.

Para iniciar, clique aqui (clique com o botão direito e em “Salvar destino como“) e realize o download do código java script popup html.

Após realizar o download, verá um arquivo em html, basta clicar com o botão direito no arquivo e selecionar as opções “Abrir Com..”, e “Bloco de Notas”.

Repare que esse é o exato modelo usado aqui no CriarSites.com e diante disso, vou deixar algumas mudanças para realizar no código e personalizar de acordo com seu site.

Ao abrir o arquivo com o bloco de notas, não é necessário mexer em nada no inicio do código, basta ir ate o trecho final e localizar os pontos a serem personalizados de acordo com seu site (nos pontos como mostra a figura acima, destacados pelo comentário “ISSO E UM COMENTARIO PERSONALIZE ESSA LINHA ABAIXO com …”).

Também lembre-se de publicar em seu site/blog as imagens “closeicon.gif” e “rss-feed-gif.gif” e anote o endereço de cada um deles. Depois cadastre-os endereços no código do popup.

Nos locais onde se encontra “CriarSites“, você deve alterar com o nome que aparece no endereço de seu blog no FeedBurner.

Realizadas estas estas alterações, basta inserir todo o trecho do código antes da tag </body> no seu site, ou se estiver usando um blog WordPress, basta criar um widget Texto/HTML e inserir o código já personalizado (por completo).

Pronto, seus problemas para captar e-mails e aumentar consideravelmente sua lista de e-mails está resolvido de uma vez por todas.

Se realmente gostou desta dica, além de deixar seu comentário, procure compartilhar esse artigo pelas redes sociais para ajudar mais webmasters de plantão!

Esse código realmente é um “salva vidas”, assim como o CriarSites.com, rs.

Postado por Rogerio Gomes/WRG

Fonte: CriarSite

Tags | , , , , ,

23

nov
2011

Sem Comentários

Em Blog
PHP

Por Allison

Sistema de login em PHP sem Banco de Dados

Em 23, nov 2011 | Sem Comentários | Em Blog, PHP | Por Allison

Bem, recentemente decidi começar a criar scripts em php e coloca-los no “oSabetudo.com”, para que todas as pessoas interessadas na criação de sites os possam utilizar.

Este é o meu primeiro tópico aqui no “oSabeTudo” onde consta o meu primeiro script. Este script é um simples sistema de login sem a utilizar um banco de dados, que impede os visitantes não logados de aceder a páginas restritas, caso um visitante tente aceder a uma página restrita através do link directo sem que tenha sessão iniciada, a página irá redirecioná-lo para a página de login. Visto que este sistema de login não utiliza banco de dados, você pode apenas ter um utilizador, com uma senha e um login personalizado por si, depois basta divulgar esses dados aos visitantes que quer que acedam a páginas restritas.

Faça o Download do script através do link abaixo:

Download do sistema de login sem banco de dados em php por Daniel O.

Dados:

Por defeito o nome de utilizador e a senha são “user” e “senha” respectivamente (sem as aspas) mas estes dados podem ser alterados por si.

Instalação

Para instalar este script no seu site, basta descompactar os ficheiros e colocá-los na raiz do seu site.

Coloque o seguinte código na secção <body> das páginas que quer tornas restritas.

    // Inicia a sessão
    session_start();
    // Envia o utilizador para a página de login se não efectuar login com sucesso
    if ($_SESSION["Login"] != “TRUE”) {
    header(“Location: login.php”);
    }
    echo(” <form method=\”POST\” action=\”\”>
    <p><input type=\”submit\” name=\”logout\” value=\”Terminar Sessão\” /></p>”);
    if(isset($_POST["logout"])){
    session_destroy();
    header(“Location: login.php”);
    }

Para alterar a senha e o utilizador, basta aceder ao ficheiro “session_start.php”.

Para alterar o utilizador, altere a linha 12 mas mantenha as aspas, por exemplo, para mudar o utilizador de user para teste, basta colocar “teste” com as aspas na linha 12.

Para alterar a senha, basta alterar a linha 14 do arquivo, mas tal como acontece com o utilizador, na senha também tem de manter as aspas.

Fonte: Daniel O./OSabeTudo

Tags | , ,

24

set
2011

Sem Comentários

Em Blog

Por Allison

Boas práticas de programação – filosofias de desenvolvimento

Em 24, set 2011 | Sem Comentários | Em Blog | Por Allison

Vou escrever um resumão de alguns conceitos muito importantes para o desenvolvimento de softwares, independente da linguagem que você estiver “falando”.

Conceitos antigos, mas que muitas vezes não são tão difundidos quanto deveriam.

Para evitar uma confusão durante a leitura e alguns comentários perdidos, informo que o nível desse artigo é mediano. Nem muito avançado, a ponto de que um Dev iniciante fique completamente perdido (talvez apenas não entenda alguns trechos, mas nada que atrapalhe a assimilação do todo), e nem tão básico a ponto de ser desinteressante para quem já tem um pouco mais de experiência.

Um dos conceitos mais importantes diz que seus códigos devem ser de fácil manutenção e é impossível que a sua aplicação seja “simples” de refatorar, se ela tiver rotinas idênticas espalhadas “ao Deus dará”. Note que os conceitos que citarei se aplicam a um mesmo projeto. Durante o desenvolvimento de uma aplicação, leve em conta os seguintes pontos:

SOC = Separation Of Concerns

Separe os interesses. Divida rotinas em trechos tão pequenos quanto possível, e tanto quanto ainda fizer sentido. Quando temos um grande problema para resolver, devemos começar separando esse problemão em probleminhas menores e resolvê-los uma vez. Isolando em pequenas partes focadas você privilegiará até o reaproveitamento do seu código.

DRY = Dont Repeat Yourself

Não repita a si mesmo. Se você já programou um trecho de código que resolve uma dada situação e logo mais adiante se depara com a mesma situação, você não deve desenvolver a mesma rotina outra vez ou muito menos replicar o script. Sem essa de Ctrl+C / Ctrl+V (ou command no caso de usar MAC). Também pode ser conhecido por:

DIE = Duplication is Evil

E é o que realmente é. Duplicação é ruim. Ruim para o desenvolvedor, para o desenvolvimento, para futuras correções… Não duplique códigos.

Existem até Design Patterns específicos que tratam desse tipo de questão.

Desacoplamento é o objetivo. Devemos saber que é impossível termos componentes completamente independentes porém o Strategy, por exemplo, pode nos ajudar nisso.

Trabalho com sistemas web. Programo hoje em dia principalmente em php. Não estou falando que “é ruim” instalar o WordPress 2-3, várias vezes para vários clientes, duplicando o core do WP em vários dominios. Digo para você não se repetir num mesmo site, num mesmo projeto.

Se eu já implementei uma rotina de conexão ao banco de dados, não vou duplicar essa rotina. Não vou ter mais que um único arquivo com os dados de configuração. Não vou jogar por vários cantos da aplicação a lógica do cálculo de descontos do e-commerce. Tenho que analisar bem e centralizar para não me repetir ou “reinventar a roda” que eu mesmo já inventei.

KISS = Keep It Simple, Stupid

Mantenha simples. Descarte toda a complexidade que não for realmente necessária.

Lógico que nem tudo é simples. Existem coisas que realmente não são. Porém a idéia do KISS não é deixar fácil, mas sim evitar complicar. Evitar aumentar o custo entregando exatamente o que foi requisitado. E apenas isso.

Você e sua aplicação só ganharão com isso.

KISS é fazer menos, e não fazer da forma mais fácil.

Mantenha o foco. Desse conceito derivam os dois seguintes:

YAGNI = You Aren’t Going Need It

Bastante parecido com o conceito de cima. “Você não vai precisar disso” nos diz para não complicar ou ficar inventando o que não será usado.

É uma tentação comum querermos desenvolver o sistema mais incrível do mundo com as melhores funcionalidades.

Seja racional. Preveja a expansão e escalabilidade, porém não fique dando voltas atrás do próprio rabo sem sair do lugar ou entregar o que foi pedido por estar implementando algo que não era nem requisito e nem necessário naquele momento.

Worse is better, também nos diz exatamente isso. A qualidade não provém somente de mais funcionalidades. Ao pé da letra, “quanto pior, melhor”. Devemos prezar pela praticidade e usabilidade, mesmo que sejamos obrigados a impor limites. Algumas expansões são óbvias e não vamos deixar de fazê-las, porém analise se neste momento é necessária ou não.

Além desses pontos, nunca devemos nos esquecer de identar, comentar, documentar…

Um não concorre com o outro. Use todos juntos, como complementos. Aplicar um desses conceitos te leva ao seguinte.

Ainda não tenho conhecimento suficiente para ensinar. Continuo estudando e espero ter contribuido com alguma coisa, assim como contribui com o meu próprio aprendizado ao me propor a escrever esse texto.

Fonte: William Bruno/IMaster

Tags | , , , , ,

18

ago
2011

Sem Comentários

Em Blog

Por Allison

Dez duras verdades sobre o HTML5

Em 18, ago 2011 | Sem Comentários | Em Blog | Por Allison

O momento é propício para admitir que existem limitações sérias com o modelo

Para muitos profissionais de TI o HTML5 representa a chegada de algumas novas características interessantes, com potencial para provocar uma mudança de paradigma na programação Web. Polvilhe um pouco de HTML5 em seu código e seus sites serão mais rápidos e mais extravagantes. Mas a realidade do que HTML5 pode fazer por aqueles que procuram APPs na Web está aquém do hype.

O momento é propício para admitir que existem limitações sérias com o modelo. Não só há razões para lamentar sobre o fato de o HTML5 não realizar todos os nossos sonhos de atingir o nirvana na Web, como até mesmo razões para abster-se de usar o HTML5, em alguns casos.

A verdade é que, apesar de suas capacidades poderosas, o HTML5 não é a solução para todos os nossos problemas. Suas características adicionais são convincentes e ajudam a tornar aplicativos Web concorrentes formidáveis para aplicativos nativos, mas questões com segurança, limitações para armazenamento local de dados, os desafios de sincronização e as políticas de uso, deveriam ser suficientes para frear todas as expectativas. Afinal, cada tecnologia tem suas limitações.

Listamos dez duras verdades que os desenvolvedores Web devem considerar para tirar o máximo do HTML5.

1:: Segurança é um pesadelo

Na ponta cliente, o problema fundamental é que o usuário final tem controle sobre o código executado na máquina. No caso de aplicações Web, quando o seu browser vem com uma ferramenta de depuração, é mais fácil do que nunca abusar desse controle.

Com um depurador JavaScript como o Firebug, quem tem alguma curiosidade sobre o que o Facebook, o Google, ou qualquer outro site está fazendo pode simplesmente começar a inserir breakpoints e ver o código. Isso é ótimo para depurar e aprender como operar sites, mas também é um pesadelo para a segurança.

Suponha que você tenha o interesse em mudar o valor de uma variável. O Firebug ou qualquer um dos depuradores presentes em outros navegadores pode ajudá-lo a ajustar as variáveis como você desejar. Quer enganar seus amigos e fazê-los crer que você está em determinado local, longe do local onde você de fato está? É fácil editar as variáveis latitude e longitude para colocar seu browser em qualquer lugar do mundo. Todas as características puras do seu aplicativo Web podem ser modificados, e o browser torna mais fácil essa modificação do que um APP de código nativo.

Isso significa que os aplicativos baseados em clientes HTML5 podem não ser confiáveis para a coleta dos dados, e é melhor para que todos tenham consciência de suas capacidades.

2 :: O armazenamento local de dados é limitado

A permissão para o armazenamento de até 4Gbytes de dados estruturados pelo banco de dados presente no browser, no lado do cliente _ de forma parecida a como vinha ocorrendo com o uso das cookies, mas tentando eliminar as limitações impostas, como o tamanho de 4Kb _ é uma das funcionalidades mais badaladas do HTML5.

O desenvolvedor deve lembrar, no entanto, que o armazenamento local é por site e estará disponível para seus scripts toda vez que o site que originalmente armazenou os dados for acessado, de modo a poupar largura de banda e melhorar o desempenho.

E também que os banco de dados dos browsers não dão aos usuários o mesmo poder sobre seus dados que eles teriam em outros aplicativos.

Por exemplo: o usuário não pode mover os dados armazenados para outra máquina, fazer cópias, fazer um backup, ou abri-lo com um aplicativo diferente do navegador. Os arquivos não são projetados para se mover facilmente, embora seja possível fazê-lo se o usuário souber onde e como localizá-los. Até porque, não são como planilhas ou documentos de texto, fáceis de abrir com qualquer editor.

3:: Dados locais podem ser manipulados

O usuário não pode ter controle sobre os dados armazenados localmente, mas o site central também pode ter problemas por causa com a sincronização e até mesmo com a segurança desses dados.

Não há como o desenvolvedor garantir que o banco de dados local nunca será manipulado pelo usuário. Embora não existam ferramentas que tornem a edição dos dados locais e/ou a atualização de privilégios, tarefas fáceis para os usuários, ainda assim elas podem vir a ocorrer. Brechas de segurança do código JavaScript , por exemplo, são apenas um dos caminhos possíveis para tal.

4:: A sincronização dos aplicativos offline é um pesadelo

A possibilidade de armazenamento local de dados local do HTML5 melhora imensamente a capacidade de usar aplicativos Web no modo offline. O único problema é a sincronização de dados.

Se um aplicativo Web está conectado à Internet, pode sempre salvar os dados para a nuvem. Quando está offline, as alterações não são sempre armazenados na nuvem. Quando alguém muda de navegador ou usa uma máquina diferente, cópias começam a proliferar e as dificuldades de sincronização também.

Os desenvolvedores devem se preocupar em fornecer a interface para que o usuário possa lidar com a sincronização. A especificação HTML5 não oferece qualquer ajuda.

Programadores gerenciar essas dores de cabeça utilizando sistemas de controle de versão, que se tornaram cada vez mais sofisticados para lidar com esse problema. No entanto, apenas ter a tecnologia não significa que ela seja de fácil uso. A fusão de vários repositórios GIT pode levar tempo.

5:: A nuvem lhe deve nada

Não é justo culpar HTML5 por todos os problemas estruturais com o armazenamento de dados na nuvem, mas a nuvem é uma parte essencial do modelo, que tira proveito dela para corrigir todas as dores de cabeça da instalação de software e backup de dados.

Dadas as limitações de armazenamento local de dados do HTML5, a maior parte do armazenamento de dados das APPs Web continuará nos servidores, e há momentos em que esta abordagem poderá ser devastadora.

Recentemente o Facebook decidiu que não gostava de um plug-in baseado em Linux para fazer upload de fotos. O plug-in foi removido, juntamente com todas as fotos que foram enviadas ao usá-lo.

Essas histórias não são comuns, mas estão se tornando cada vez mais frequentes, por muitas razões. E podem vir a ser um problema ainda maior se considerarmos que muitos termos de serviço de aplicações Web não responsabilizam os fornecedores por perdas de dados, deixando o usuário sem nenhum recurso legal para recuperá-los. Alguns dos acordos de serviço mais ultrajantes insistem que os dados podem até mesmo serem excluído sem “nenhuma razão” para tal.

A estrutura do HTML5 praticamente garante que qualquer do dado em cache local no navegador do usuário será armazenado na nuvem, fora de seu alcance e controle. O hype HTML5 diz que esta é uma característica fantástica, mas esquece que ele pode se voltar facilmente contra o modelo.

6:: Upgrades forçados não são para todos

Uma história, apócrifa, circula na rede. Consta que determinada pessoa usou uma conta de Gmail para conexões casuais com pessoas em bares. Quando o Google+ foi lançado, todas as lembranças dessas pessoas vieram à tona, porque endereços antigos para os fóruns de discussão voltaram à superfície. Todos os dias, velhos conhecidos reaparecem lá pedindo para serem incluídos em círculos de discussão.

Quando as empresas Web necessitam fazer o upgrade de seus serviços, normalmente o fazem de uma vez, contemplando todos os usuários ao mesmo tempo. Se, por um lado, isso livra os usuários de terem que gerenciar a instalação do upgrade, por outro acaba virando um pesadelo para qualquer um que não queira usar os novos recursos.

E este não é apenas um problema para a privacidade das pessoas, como no caso acima.


7:: Web Workers não oferecem priorização

eb Workers estão entre os recursos mais intrigantes do HTML5. Ele acelera o carregamento de páginas web cheias de código javascript, por ser capaz de executá-los em processos separados do restante da página web. Em outras palavras, o HTML5, com o Web Workers permite que o navegador se comporte como um sistema operacional, ainda que parcialmente.

Infelizmente, não há maneira de gerenciar a carga de trabalho de forma eficaz ou de definir prioridades.

8:: Incompatibilidades de formato abundam

Não culpe os comitês do HTML5 pelo fato de os desenvolvedores de browsers não tenham decidido implementar todos os vários formatos áudio e vídeo. São os desenvolvedores que têm que lidar com as consequências quando um arquivo que funciona perfeitamente em um browser não faz nada em outro. Há um teste para isso? Desenvolvedores de API foram espertos o suficiente para incluir a função canPlayType, mesmo que ela não seja suportada por todos os navegadores.

9:: Implementações são browser-dependentes

A visão idílica do HTML5 é uma coisa, a realidade grungy de suas implementações é outra. Verdade. Os programadores estão tentando fazer o seu melhor para construir os sonhos dos arquitetos, mas algumas tags e objetos não funcionam corretamente.

Por exemplo, há muitos desejos sobre a API de geolocalização do HTML5. Ela oferece alguma proteção para a privacidade e um pouco de controle sobre a precisão. Mas em determinado browser, sempre dá time out.

Em última instância, esta é mais uma reclamação sobre como os navegadores não conseguem implementar recursos HTML5 de forma consistente, ao contrário de um ser que visa a estrutura da API em si.

10:: Idiossincrasias de hardware impõem novos desafios

Também parece injusto reclamar sobre como alguns desenvolvedores de browser vão além do dever de proporcionar um desempenho muito melhor. Mas nenhuma boa ação fica impune.

A Microsoft tem feito um grande trabalho de melhorar o desempenho de objetos Canvas no IE, integrando-os com os drivers de baixo nível de hardware. A empresa encomendou jogos simples, como pirateslovedaisies.com, para demonstrar o recurso.

Mas agora os programadores devem prestar atenção para saber se esse recurso adicional está disponível ou não, e se seu código está sendo executado.

Fonte: CIO

Tags | , , , , , , , ,

16

ago
2011

Sem Comentários

Em Blog

Por Allison

Novo MS SQL Server Development Tools

Em 16, ago 2011 | Sem Comentários | Em Blog | Por Allison

Desenvolvimento SQL Server dentro do Visual Studio

O Microsoft SQL Server Development Tools (SSDT) – codinome “Juneau” – permite aos desenvolvedores SQL Server utilizar recursos do Visual Studio até então restritos ao desenvolvimento com linguagens como C# e Visual Basic. Liberado juntamente com a versão CTP do SQL Server “Denali”, a versão preview do pacote contém funcionalidades que trazem melhorias para todo o ciclo de desenvolvimento com o SQL Server.

Uma das principais melhorias é a disponibilização de uma experiência semelhante à do SQL Server Management Studio (SSMS) para edição online de objetos do banco de dados dentro do Visual Studio. Através da aba Server Explorer, presente no Visual Studio há algumas versões, é possível navegar nos objetos do banco de dados numa hierarquia semelhante à do SSMS. É também possível editar qualquer tabela através de um editor visual, o Table Designer, ou do editor TSQL. As mudanças são sincronizadas automaticamente.

Também há novidades no desenvolvimento offline. Além de permitir a criação de um projeto de banco de dados a partir de um banco já existente, em que os objetos ficam armazenados como scripts .sql, com o SSDT é possível usar as mesmas funcionalidades de edição de tabelas sobre os scripts (no Table Designer e no editor TSQL). Para o deploy das modificações, a ferramenta permite gerar um script com as modificações realizadas em cada objeto, realizando as adaptações de sintaxe necessárias a qualquer versão do SQL Server, incluindo o Azure.

Figura 1. Seleção da versão do SQL Server a ser utilizada pelo projeto

Para o desenvolvimento de rotinas TSQL, um editor embutido no Visual Studio permite a utilização da funcionalidade IntelliSense, já existente no SSMS. Há também recursos semelhantes aos de linguagens como C# e VB, por exemplo a navegação entre definições e referências de funções e procedures, refatoração contextual de código e checagem automática de erros de acordo com a versão do SQL Server configurada.

Figura 2. Navegação entre definição e referências de funções e procedures

O SSDT trará uma integração mais próxima com o Entity Framework, ferramenta de ORM da Microsoft. Através da criação de um ADO.NET Entity Data Model (modelo de dados de entidade), será possível criar o modelo com base em um banco de dados existente e configurar como será realizada a propagação de modificações realizadas do modelo para a camada de dados, e vice-versa. A integração permitirá ainda que a depuração da aplicação seja realizada fim a fim – incluindo o debug de funções e procedures do banco de dados – de forma totalmente integrada.

A versão preview do SSDT já funciona com o Visual Studio 2010, mas a versão oficial somente será liberada com a próxima versão do Visual Studio. Além disso, o pacote também será disponibilizado de forma standalone, usando o Visual Studio Shell.

Houve comentários na comunidade com relação à ausência de funcionalidades já existentes na aba Server Explorer, além da não disponibilização da integração com o Entity Framework, na versão preview. É esperado, entretanto, que as mesmas estejam presentes na versão final do SSDT.

Fonte: InfoQ

Tags | , , , , , , ,

25

jul
2011

Sem Comentários

Em Blog

Por Allison

Mais HTML5 no segundo Platform Preview do IE10

Em 25, jul 2011 | Sem Comentários | Em Blog | Por Allison

A equipe do Internet Explorer anunciou o segundo platform preview para o IE10. Esta versão preliminar apresenta muitas novas funcionalidades, especialmente no suporte a novos padrões do HTML5, como CSS3 Positioned Floats, HTML5 sandbox e HTML5 Forms. Oferece também as novas APIs setImmediate e Page Visibility, além do suporte a scripts assíncronos. O IE10 usa a mesma engine para HTML5 apresentada recentemente nas demonstrações do Windows 8.

Algumas das principais funcionalidades apresentadas são:

  • Suporte aos Positioned Floats do CSS3: permite que um determinado conteúdo da página seja agrupado a outros elementos, colocando esse conteúdo em destaque;
  • HTML5 SandBox: recurso de segurança que previne comportamentos maliciosos de sites de terceiros, como interceptação de cookies, submissão de formulários ou redirecionamentos de página indesejados;
  • HTML5 Forms: validação básica para formulários HTML;
  • Suporte a Drag and Drop em HTML5;
  • API setImmediate, uma alternativa à API setTimeout com desempenho melhor, para quebrar em partes a execução de operações longas em JavaScript;
  • Media Query Listeners: permite executar um script em resposta a mudanças numa media query (por exemplo, para trocar uma imagem, usando uma versão com resolução mais alta ou mais baixa conforme o tamanho da janela);
  • Async Scripts: habilita o download assíncrono de scripts JavaScript, sem bloquear o download do conteúdo restante da página;
  • API requestAnimationFrame: nova API que permite criar animações mais suaves e eficientes;
  • Web Workers: cria containers para execução de JavaScript, de forma independente do código da página web.

Todas essas funcionalidades são explicadas, com demonstrações e exemplos no Platform Preview. O guia do desenvolvedor mostra detalhes sobre como acessar e testar os novos recursos do HTML5 e de tecnologias relacionadas.

Fonte: InfoQ

Tags | , , , , ,