Bom, antes de iniciarmos o aprendizado sobre Media Queries, precisamos entender o que são Media Types.

O CSS pode ser usado para especificar como o documento será exibido em diferentes tipos de mídias, tais como celulares, desktop e impressos.

Existem dez tipos de media types definidas na especificação CSS 2.1. São elas:

Existem 5 métodos que podem ser usados para especificar as media types. São eles:

Os métodos mencionados acima são utilizados também nas media queries. Bem, mas o que são media queries? Vamos entendê-las!

Por um longo tempo temos sido capazes te especificar estilos para diferentes tipos de mídia usando CSS, sendo os “print” e “screen” os mais reconhecidos. Com CSS3 essas media types foram extendidas, permitindo novas expressões. São as chamadas “media queries”, que nos dão grande controle quando precisamos adicionar estilos específicos para visualização em determinados tipos de dispositivos.

As medias queries geralmente consistem de uma media type e nenhuma ou muitas palavras-chave, como por exemplo:

Sintaticamente, as media features assemelham-se às propriedades CSS. Elas possuem nomes e aceitam certos valores. Existem, contudo, diversas diferenças importantes entre as propriedades e as media features. São elas:

Exemplo: “color” pode formar expressões sem valor -> (“(color)”) ou com valor -> (“(min-color: 1)”).

Abaixo segue uma lista completa de todas as media features:

Você pode usar múltiplas expressões em uma media query se você juntá-las com a palavra-chave “and”.

Um exemplo claro é se formos aplicar para dispositivos do tipo hand-held, mas somente se a largura da área de visualização for maior que 20em e menor que 40 em.

É possível usar múltiplas declarações media queries separando-as por vírgula.

Exemplo:

É possível utilizar a palavra “not” caso queira ignorar algum dispositivo.

Exemplo:

É possível usar a palavra “only” para aplicar as regras somente para as media queries determinadas.

As media queries não são suportadas para IE8 e inferiores, somente para:

Vale ressaltar que os browsers que não suportam as media queries podem suportar as medias types.

A keyword “only” é, algumas vezes, usada para esconder o CSS de alguns dispositivos que não suportam media queries, mas podem ler as media types.

Media Queries em iPhones

O iPhone não suporta a media type handheld. A Apple recomenda que as media queries sejam usadas para Iphone.

Exemplo: as regras serão aplicadas para iPhone que tem uma largura máxima de dispositivo de 480px.

Fonte: Blog Virtualize

Veja perfil e 3 post(s)

Saber XML é muito importante para quem trabalha com desenvolvimento.

Se você trabalha com algum framework, provavelmente já teve que fazer a configuração do framework em um arquivo XML.

Pensando nisso, escrevi uma série de tutoriais que podem lhe ajudar a entender mais sobre esse mundo do XML e não cometer mais erros!

Segue série de artigos:

Veja perfil e 23 post(s)

No post Como Montar um Grid utilizando Ext JS, citei que era possível carregar os dados de um grid através de JSON. O post de hoje tem como objetivo de fazer uma breve introdução sobre JSON.

JSON (JavaScript Object Notation – Notação de Objetos JavaScript) é uma formatação leve de troca de dados, também conhecido como um sucessor do XML. JSON é em formato texto muito simples e ao mesmo tempo elegante, além de ser em formato para troca de informações entre o browser e o servidor.

O JSON também é mais rápido e mais leve que o XML. Enquanto que no XML tratamos todos os dados como string, os objetos JSON são tipados (string, number, array, boolean).

Um objeto JSON pode ter a forma de duas estruturas:

Exemplos

O objeto meuPrimeiroJSON possui 3 propriedades, ou 3 pares nome/valor. O nome de cada par é: nome, sobrenome e idade. O valor pode ser qualquer objeto Javascript. Neste exemplo, o valor de cara par, respectivamente: Loiane, Groner, 23. Note que nome e sobrenome são strings e a idade é um número.

Como já citado, o formato dos dados é chamado de JSON. O que o torna poderoso é o fato do valor porder ser qualquer tipo de dados, desde uma string até arrays e outros objetos, podendo formar tipos complexos de dados, como os da estrutura abaixo:

Para converter um texto JSON em um objeto JSON, utilizamos a função eval(), que invoca o compilador javascript, que irá converter o texto e criar a estrutura de um objeto:

Você pode trabalhar com JSON e diversas linguagens, inclusive java!

Os códigos js do post você pode fazer o download aqui

Conclusão

Esta foi uma rápida introdução de como representar um objeto JSON. Para maiores detalhes, visite: http://www.json.org/

Como dito acima,JSON é uma opção para transitar dados entre o browser e o servidor.

Como desenvolvedora Java, tenho que saber como integrar JSON com a minha linguagem predileta. Então vamos lá:

Como Json pode ser útil para os desenvolvedores java?

Algumas bibliotecas JSON para o Java

Além de poder trabalhar com JSON com alguns frameworks como Struts e Spring.

Atualmente estou trabalhando com Json-lib.

Escolha a sua lib e seja feliz!

Até a próxima

Fonte: Blog da Loiane

Veja perfil e 23 post(s)

Nos ciclos de desenvolvimento de sistemas, costumamos ter as fases de análise e design. Vamos ver neste artigo, um exemplo de AD orientada a objetos com UML.

Na fase de análise os envolvidos devem obter uma idéia clara do que o sistema deverá fazer, sem se preocupar com detalhes relacionados à maneira como ele irá implementar as funcionalidades levantadas nos requisitos do projeto.

Para buscar este entendimento, podemos utilizar interessantes propostas de mercado, baseado no levantamento e análise dos requisitos do projeto através de Casos de Uso da UML (Unified Modeling Language).

Após entrevistar os envolvidos no projeto da área de negócios do cliente, podemos analisar os Cenários de Caso de Uso identificados, elaborando e refinando diagramas de Caso de uso e de Atividades. Todas as informações levantadas devem ser registradas em algum documento formal baseado em propostas de mercado, veja propostas de Especificação de Caso de Uso e Relatório Sintético de Caso de Uso na referência bibliográfica deste artigo. Estes documentos devem ser validados pelos envolvidos no projeto e divulgados para toda a equipe do mesmo.

Veja abaixo, representação UML do Caso de Uso de um sistema no cenário responsável pela emissão de conta de restaurante.

Este digrama UML mostra claramente um usuário (Ator) e uma funcionalidade do sistema (Caso de Uso) que estaremos implementado em nosso sistema e deve ser elaborado na fase de análise de nosso projeto, vindo a incorporar a documentação técnica a ser aprovada e enviada para os desenvolvedores da aplicação.

A Especificação de Caso de Uso deve conter uma série de informações adicionais. Neste exemplo, poderíamos citar as informações e processamento abaixo para ser possível encerrar a conta:

Como parte da análise, torna-se extremamente interessante termos o Diagrama de Atividades relacionado ao Caso de Uso. Este diagrama deve ser validado com os donos do requisito, para aprovação e corroboração de nosso entendimento do que deve ser efetivamente desenvolvido, mostrando inclusive regras de negócio envolvidas, quando possível.

Observe no diagrama abaixo como este diagrama torna muito claro o funcionamento, sequencia de eventos e regras de negócio envolvidos no mesmo.

Na fase de análise, podemos definir sem detalhamento as classes envolvidas no Caso de Uso, sendo que na fase de design teremos que detalhar as mesmas. Neste momento, algumas classes sugeridas na fase de análise podem deixar de ser consideradas enquanto muitas outras provavelmente irão aparecer, conforme evoluímos em nosso trabalho.

Veja abaixo, diagrama de classes inicial de nosso processo de modelagem.

Já na fase de design, temos que ter as classes muito bem definidas para termos um desenvolvimento correto, documentado, com facilidades de manutenção corretiva e evolutiva como a modelagem sugerida abaixo.

Na verdade, considero todo este processo muito empolgante e ainda existe muitos detalhes bem interessantes a se considerar na modelagem, tais como patterns, arquitetura, persistência de dados, …

Luck favors the prepared mind!

Veja exemplo completo juntamente com templates em Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1

O RGBA não é exatamente uma propriedade existente no CSS3 como muitos dizem, mas sim, um novo modelo de cores introduzido no CSS3.

Assim como no modelo RGB, temos a seguinte correspondência:

Para o RGBA existe também o A, ou alfa, que permite mencionar a opacidade de uma cor. Isso permite que o desenvolvedor tenha em mãos uma grande quantidade de cores diferentes e maior flexibilidade na criação de projetos web.

Para obter a cor red, precisaríamos da gama rgb(255,0,0) ou rgb(100%, 0%,0%). Caso você queria adicionar uma opacidade de 50% à essa cor, utilizaria o código abaixo:

ou

O efeito visual para o código acima segue abaixo:

A opacidade varia de 0 à 1.

Essa propriedade funciona em:

Fácil e muito funcional, não?!

Retirado de Eu Faço Programas

Olá pessoal, tudo certo?

Estou devendo este artigo sobre Windows Server AppFabric aqui para o Profissionais TI faz algum tempo. Promessa é dívida, certo Jackson?! Então vamos lá!

Para quem ainda não ouviu falar sobre Windows Server AppFabric, esse pacote representa um importante componente de infraestrutura na plataforma Microsoft. Lançado em Março de 2010, ele integra um conjunto de serviços para hosting, caching, integração, composição e monitoração de serviços e workflows na plataforma Microsoft.

Atualmente, já temos os serviços de caching e hosting disponíveis para download. Os demais devem ser publicados como CTP ao longo de 2011.

Para informações atualizadas sobre o roadmap e links para download, confira sempre o portal do AppFabric, no link:

Ref.: http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx

Assim, vamos focar nessa artigos as principais funcionalidades do AppFabric Hosting Services e do AppFabric Caching Services.

Uma visão geral sobre o Windows Server AppFabric

Quando pensamos em serviços de modo geral na plataforma Microsoft, pensamos em nosso velho amigo WCF – Windows Communication Foundation. Ele representa o principal mecanismo para construção de interfaces de serviços e transporte de mensagens, suportando diversos protocolos como HTTP, SOAP, WS-I, TCP, MSMQ, NAMED PIPE, etc. além de ser altamente extensível e configurável. É muito provável que você já esteja trabalhando com serviços WCF em suas aplicações corporativas ou web services.

Da mesma forma, podemos usar o WCF Workflow Services, uma implementação de serviços via workflow usando o WF – Windows Workflow Foundation, disponível na versão WF4/WCF4 no Visual Studio 2010. A grande vantagem desse tipo de template é sua capacidade de construir workflows sofisticados, oferecendo uma interface de serviços WCF para suas chamadas e requisições.

Muito bem, a grande pergunta é: onde você publica seus serviços?

Muitas empresas utilizam apenas o IIS – Internet Information Services como ponto principal para hosting de serviços. Isso limita o atendimento de requisições somente para o HTTP/SOAP, como protocolos básicos de comunicação. Na plataforma Windows Server 2008, outra opção também importante é a utilização do WAS – Windows Process Activation Services, que amplia os protocolos suportados para requisições de serviços WCF. Um post publicado pelo especialista Microsoft Rafael Godinho faz uma breve introdução aqui, confira:

Hospedando um serviço WCF no WAS – Windows Process Activation Services
Ref.: http://blogs.msdn.com/b/rafaelgodinho/archive/2009/05/07/hospedando-um-servi-o-wcf-no-was-windows-process-activation-services.aspx

Nesse contexto, o Windows Server AppFabric adiciona funcionalidades sobre a dupla IIS/WAS, ampliando seu poder de hosting com novos recursos para gerenciamento, monitoração e administração de serviços e workflows na plataforma.

O Windows Server AppFabric oferece uma infraestrutura através de 2 principais serviços:

Assim, quando instalamos o Windows Server AppFabric em um servidor Windows Server 2008, recebemos três novos componentes na interface de administração do IIS Manager:

Dentro dessas funcionalidades, diversos recursos para administração e observação de comportamento sobre o ambiente estão disponíveis, o que aumenta o poder de monitoração da plataforma sobre aplicações e soluções baseadas em serviços WCF/WF.

Monitoração com Windows Server AppFabric

Um assunto de destaque sobre o Windows Server AppFabric é sua capacidade de monitoração e tracking de informações sobre o que acontece com nossos serviços. Quando falamos sobre monitoração de serviços e workflows na plataforma Windows, temos diversas ferramentas disponíveis:

Qual dessas ferramentas você mais utiliza? Para responder, você pode perguntar: mas para que situação você quer ativar a monitoração?

Correto! Temos duas situações de monitoração importantes no dia-a-dia:

Ainda, podemos dizer que existem duas demandas diferentes sobre monitoração, de acordo com o profissional de TI envolvido:

O desenvolvedor espera do ambiente algumas informações sobre o comportamento de seus serviços e workflows, em tempo de desenvolvimento. Seria interessante obter, por exemplo, o histórico de chamadas sobre um WCF Service, ou ainda, o histórico de eventos e atividades executadas por um workflow. Claro, podemos sempre utilizar o ambiente de testes do Visual Studio 2010 para essas ações, mas algumas situações, especialmente cenários de persitência, colaboração de workflows, correlação de mensagens, etc, exigem a depuração em ambiente servidor. Um ambiente de testes e homologação torna-se uma ferramenta quase obrigatória para esses cenários.

O profissional de TI, administrador de rede ou IT Pro, por sua vez, espera informações detalhadas sobre o comportamento da aplicação em produção. Uma demanda constante é obter o mapa de valores sobre a saúde da aplicação em execução. Em caso de problemas, a ferramenta de monitoração precisa permitir uma inspeção rápida sobre a configuração ativa, assim como informações sobre onde o problema está ocorrendo e qual sua gravidade.

Nesse contexto, o Windows Server AppFabric está integrado com o Event Tracing for Windows para a monitoração de serviços WCF e workflows WF. De fato, o Windows Server AppFabric instala em sua máquina o serviço Event Collector Service, que consolida em base de dados os eventos capturados pelo ETW. Isso garante uma base de dados de monitoração histórica, sobre a qual podemos realizar nossas análises e observações.

Podemos ainda configurar diferentes níveis de monitoração, que são opções disponíveis na configuração do AppFabric. Assim, podemos usar os chamados tracking profiles pré-configurados para nossa aplicação. Os principais tracking profiles disponíveis com a instalação do Windows Server AppFabric são:

Para conferir essas opções de configuração, o ponto de partida sempre será o IIS Manager, que você encontra na pasta de Ferramentas Administrativas do Painel de Controle do Windows Server. De imediato, notamos um grande diferencial sobre a plataforma com a instalação do Windows Server AppFabric: simplesmente não temos uma interface de consolidação de eventos quando hospedamos nossos serviços e workflows apenas sobre o IIS. Por isso, não deixe de instalar em seu ambiente o AppFabric, para aproveitar os benefícios dessa monitoração integrada.

Outro ponto de destaque em relação monitoração sobre AppFabric é que podemos personalizar um tracking profile para nossos workflows. Isso é feito através da configuração de uma seção no arquivo de Web.Config de nosso workflow, indicando quais eventos e variáveis gostaríamos de exportar para o ambiente de monitoração do AppFabric.

Persistência de workflows

Outro recurso importante da infraestrutura Windows Server AppFabric é sua integração com uma base SQL Server, permitindo a criação automática de um repositório para persistência de workflows de longa duração. Esse cenário é muito comum em ambiente corporativo, onde soluções baseadas em human workflows podem executar workflows que duram dias para serem finalizados. Nesse período de tempo, o workflow é descarregado da memória até a chegada de uma mensagem esperada, o que provoca sua nova ativação e processamento.

O Windows Server AppFabric trabalha então com dois repositórios de dados importantes:

Existem diversos cenários envolvendo persistência de mensagens e workflows que são resolvidos diretamente quando trabalhamos com o trio WCF/WF/APPFABRIC. Se este é o caso em sua empresa, não deixe de conferir mais essa funcionalidade.

Caching Distribuído de Dados

Finalmente, mais uma funcionalidade de destaque do Windows Server AppFabric é o AppFabric Caching Services. Esse serviço permite a criação de uma camada de cache unificado entre vários servidores de um cluster, combinados através do AppFabric.

Além da possibilidade de criação de um cache unificado, o serviço oferece uma API que pode ser usada em qualquer aplicação .NET para a manipulação de dados do cache de forma programática.

Comando como GET, ADD, PUT e REMOVE estão disponíveis para nossas aplicações, permitindo uma fácil utilização de uma camada de cache unificada. Aplicações de alto desempenho como portais ASP.NET, por exemplo, podem ainda utilizar sessões armazenadas diretamente numa camada de cache implementada via AppFabric Caching Services.

Todos os recursos do Windows Server AppFabric estão instrumentados via scripts e linhas de comando PowerShell 2.0, o que facilita o trabalho de administração e configuração em ambiente corporativo. Se você é um profissional de rede, deve estar familiarizado com os  scripts em PowerShell e cmdlets. O AppFabric disponibiliza diversos módulos de script para configuração, criação instrumentação e consultas sobre caching e serviços hospedados na infrastrutura.

Este mini-artigo fez apenas uma visão rápida sobre alguns recursos da plataforma Windows Server AppFabric. Sem dúvida, AppFabric é um forte aliado seu na administração e implementação de soluções otimizadas para serviços e workflows. E o mais importante: o Windows Server AppFabric é gratuíto, disponível para download agora mesmo! Confira:

Ref.: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=467e5aa5-c25b-4c80-a6d2-9f8fb0f337d2

Tenho publicado diversos posts no meu blog, sobre a infraestrutura AppFabric e seu impacto para a arquitetura de soluções. Para esses posts, tenho usado a tag [appfabric]. Fique a vontade para conferir e deixar seus comentários:

Ref.: http://blogs.msdn.com/b/wcamb/archive/tags/appfabric/

Por enquanto é só!

Um abraço grande!

Waldemir Cambiucci
Blog: http://blogs.msdn.com/wcamb/
Twitter: http://twitter.com/wcamb/

Esse artigo visa dar uma explicação mais clara do padrão de projetos MVC, onde se separa completamente em 3 partes independentes o controller (lógica da aplicação), o view (visual) e o model (acesso ao banco). Antes vamos ver alguns pontos fortes e fracos desse padrão para desenvolvimento web.

Na imagem ao lado podemos distinguir alguns diretórios que são de bastante importância para nós:

Diretório “application”:

Este diretório irá conter toda a sua aplicação e seus códigos personalizados. Se você precisa alterar alguma coisa em alguma classe do core do codeigniter deverá sobrescrever dentro do diretório application. Por exemplo, se deseja fazer com que a classe de paginação (que se encontra dentro de system/libraries/Pagination.php) escreva links com uma classe em particular, deverá sobrescrever essa classe dentro do diretório application/libraries. Mais a frente explicarei como criar e alterar bibliotecas no ci.

Diretório “cache”:

Este diretório pode aliviar um pouco seu servidor caso sua aplicação tenha muitos acessos. Não é necessário configurar nada ali dentro, mas esse diretório precisa ter permissão de escrita ativada para o cache funcionar sem erro. O diretório application Aqui dentro temos todos os arquivos necessários para sua aplicação rodar em qualquer núcleo (core) do codeigniter. Segue abaixo uma introdução aos diretórios mais importantes:

O diretório “config”:

Nesse diretório encontramos arquivos de configurações como constantes personalizadas, configurações de banco de dados e do próprio funcionamento do codeigniter.

O diretório “controllers”:

Aqui é onde encontraremos os controllers da nossa aplicação, mais abaixo teremos uma explicação do que são, pra que servem e como utilizá-los

O diretório “models”:

Nesse diretório iremos salvar classes que irão representar as nossas entidades no banco de dados, são os famosos models, responsáveis pelo acesso ao banco.

O diretório “libraries”:

Nessa pasta podemos criar nossas classes personalizadas para auxiliar em tarefas comuns, é o principal meio de reaproveitamento de código no codeigniter. Por exemplo, podemos ter uma classe responsável por autenticação de usuários. Como todos os projetos que faremos irá utilizar autenticação, podemos criar uma classe responsável por isso e reaproveitá-la economizando alguns minutos no desenvolvimento.

O diretório “language”:

Quando utilizamos as classes nativas do codeigniter, as mensagens de erro são sempre em inglês. Podemos utilizar este diretório para salvar arquivos-linguagens, que permitem tanto modificar a mensagem que a classe nativa irá exibir, como também auxiliar em projetos multi-linguagem.

O diretório “views”:

Toda a parte visual da aplicação virá aqui. Existem programadores que gostam de colocar as imagens, css e javascripts aqui dentro e outros que preferem deixar apenas o html visual, com os css, imagens e javascripts fora do diretório system, do codeigniter. Sinceramente, isso não irá fazer muita diferença na sua aplicação.

Antes de começarmos a programar, vamos entender primeiro o fluxo de dados do codeigniter: Como podemos ver acima, em primeiro lugar o usuário faz a requisição da página. Essa requisição chama o controller da aplicação responsável por exibir aquela página. Esse controller chama as libraries, models e helpers que precisa para processar as informações que serão exibidas na tela, e finalmente invoca a view responsável por exibir o visual que o usuário irá visualizar. Criando um projeto inicial Vamos criar um controller para nossa aplicação chamado “Contato”.  Salve um arquivo chamado “contato.php” no diretório application/controllers com o seguinte código:

Agora vamos criar a view responsável por exibir na tela o formuário de contato desse controller. Crie um arquivo chamado “form-contato.php” dentro do diretório application/views com o seguinte código:

Seu nome:
Seu email:
Sua mensagem: Seu endereço de IP é: O código é o mesmo que dizer . Onde foi definida essa variável título? No controller que chamou essa view. Lá, a variável titulo, assim como a variável ip, são índices de um vetor, que foi passado como segundo parâmetro do método view() da classe load ($this->load->view(NOME-DA-VIEW, ARRAY-COM-VARIAVEIS)).Podemos perceber que na action do formulário ele aponta para: index.php/contato/enviar. Significa que ao submeter esse formulário, ele irá acessar uma URL do codeigniter que irá chamar o controller Contato, e executar o método enviar(), passando os campos como POST.

Para acessar nosso formulário basta você entrar na URL: seusite.com/index.php/contato ou então: seusite.com/index.php/contato/formulario. Dessa forma seguimos o padrão de URL que o codeigniter usa: index.php/nome-do-controller/nome-do-metodo/parametro-1/parametro-1/…/parametro-n Se você acessar apenas: index.php/nome-do-controller/ o codeigniter irá converter isso automaticamente para: index.php/nome-do-controller/index, ou seja, se nenhum método for passado pela url, o método padrão a ser acessado será o método index(), caso ele não tenha sido declarado, ocorrerá um erro. Espero que tenham gostado galerinha, o tuto foi bem simples, mas acho que dá pra ter uma idéia do que é o codeigniter e como trabalhar com ele. Estou pensando em dar um curso de php orientado a objetos ou de codeigniter. Vou lançar uma enquete. Votem e o resultado irá decidir. Fiquem ligados no blog e assinem a newsletter para ficarem em dia com as novidades.

Fonte: Blog Estilo Fácil

Read More No comments

Posted by parker at 6:41 AM 0 comments

Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

Labels: CodeIgniter, Framework, Introduo