goncin@wordpress.com:~$ _

Linux, programação e toda sorte de nerdices

Arquivos Mensais: agosto 2010

Validando números de telefone com expressões regulares

A privatização do setor de telecomunicações, em meados da década de 90, universalizou o acesso dos brasileiros aos serviços de telefonia. De quebra, organizou a estrutura numérica dos terminais telefônicos: antes tínhamos códigos de área (códigos DDD) de três e quatro dígitos, e os números de telefone variavam entre de 5 a 7 dígitos. Atualmente, no país, todos os códigos de área têm dois dígitos e os números de telefone, oito. Essa estrutura uniforme torna possível validar números de telefone utilizando expressões regulares. Vejamos como.

Validando códigos de área (DDD)

Os código de área possíveis no Brasil vão de 10 a 99. Portanto, a expressão regular para validar códigos de área é

[1-9][0-9] (10)|([1-9][1-9])

UPDATE:  O Alexandre Taz, em seu comentário, alertou que o único DDD válido terminado em 0 é o 10, que será implementado em breve na Grande São Paulo, e observou também que prefixos iniciados com o número 6 também foram reservados para celulares. As expressões regulares foram alteradas para refletir essas alterações. Obrigado, Alexandre!

Trocando em miúdos: na primeira posição, aceitamos dígitos de 1 a 9 e, na segunda, dígitos de 0 a 9. Simples assim.

Se quisermos validar o código de área entre parênteses, como usualmente o código de área é representado, basta acrescentar:

\((10)|([1-9][1-9])\)

Uma vez que os sinais de abre e fecha parênteses porque esses sinais têm significado especial nas expressões regulares, é necessário antecedê-los com uma contrabarra para que sejam considerados literalmente.

Validando números de telefone (incluindo celulares)

Como dito anteriormente, os números de telefone (os de celular, inclusive) têm oito dígitos. O primeiro dígito do prefixo (os quatro primeiros números) pode variar de 2 a 9; números iniciados com 1 são reservados para telefônes de emergência, geralmente com 3 dígitos apenas (190 – polícia; 193 – bombeiros, etc.), e não serão validados. Os outro sete dígitos variam entre 0 e 9. Além disso, entre o quarto e o quinto dígito, vemos normalmente um hífen. De posse dessas informações, montamos seguinte expressão regular:

[2-9][0-9]{3}-[0-9]{4}

Explicando: o primeiro dígito (representado pelo primeiro grupo) pode variar de 2 a 9. A seguir, temos um grupo que pode variar entre 0 e 9 e se repete {3} vezes, seguido pelo hífen. O grupo final também pode variar entre 0 e 9 e se repete {4} vezes.

Validando números de celular

Pelas atuais normas da Anatel, os dígito inicial dos prefixos reservados para números de celular varia entre 7 6 e 9. Logo:

[6-9][0-9]{3}-[0-9]{4}

Foi necessário modificar apenas o primeiro grupo, relativamente à máscara anterior.

Colocando tudo junto

Para os casos em que o código de área será armazenado no mesmo campo que o número do telefone, a expressão regular é:

\((10)|([1-9][1-9])\) [2-9][0-9]{3}-[0-9]{4}

Trata-se simplesmente das máscaras já vistas, colocadas uma após a outra, e com um espaço entre elas para garantir a legibilidade.

Conclusão

Expressões regulares são ótimas para validar dados que obedecem a um padrão. Pesquise, busque, aprenda e melhore suas aplicações com elas. Praticamente todas as linguagens de programação oferecem suporte a elas. Consulte a documentação da sua linguagem para aprender como elas podem ser aplicadas 🙂 .

Anúncios

JetBrains PhpStorm: o novo garoto no quarteirão dos IDEs para PHP

Desde o ano passado (pelo menos), o pessoal da JetBrains vinha trabalhando num novo IDE para PHP. Cheguei a baixá-lo durante a fase de desenvolvimento, quando então o novo produto sequer tinha um nome definitivo ainda (era chamado simplesmente de “JetBrains Web IDE”), e se apresentava bastante promissor. A empresa parecia estar buscando o feedback dos desenvolvedores PHP para construir um produto específico para eles. Pois bem, o tempo se passou e finalmente foi lançada a primeira versão do IDE, agora batizado oficialmente como JetBrains PhpStorm.

Antes que me questionem: o JetBrains PhpStorm não é open source 😦 , mas tem um esquema de licenciamento bastante generoso, e sai na faixa para estudantes e desenvolvedores de projetos open source (!). E, mesmo que não se enquadre nas duas situações anteriores, adquirir uma licença dele sai mais barato que outras IDEs comerciais, como o Zend Studio, por exemplo. Seja como for, qualquer um tem 45 dias para testá-lo na condição de trial.

A pergunta, portanto, é outra: o que ele oferece em troca do preço da licença? É o que eu vou tentar desvendar de agora em diante.

Baixei a versão para Linux (uso o Ubuntu 10.04 LTS) e descompactei numa pasta sob a minha /home. Para iniciá-lo, há o script webide.sh sob  <pasta do JetBrains PhpStorm>/bin.

O JetBrains PhpStorm, assim como o Netbeans e o Eclipse, também roda sobre a plataforma Java, mas, ao contrário de seus “colegas”, pareceu-me muito mais leve para carregar. Afora o carregamento, confesso que primeira impressão não foi das melhores. O PhpStorm não assumiu o look and feel padrão do GNOME, e sua aparência padrão é horrível, para dizer o mínimo. Mas é bem fácil modificar isso: basta ir em File > Settings (aliás, um local um tanto quanto não-usual para as configurações; precisei consultar a Ajuda do produto para localizá-las), e, na guia IDE Settings > Appearance, alterar o Look and Feel para GTK+.

Resolvido o problema da aparência, criei um projeto, utilizando fontes já existentes. Eis o que obtive:

JetBrains PhpStorm com projeto carregado

JetBrains PhpStorm com projeto carregado

Isso feito, fui procurar como configurar o servidor remoto para o upload (deployment) da aplicação. Esperava eu encontrar essas configurações clicando com o botão secundário do mouse sobre o nome do projeto na árvore à esquerda, mas nada. Descobri que as configurações do projeto ficam também em File > Settings, e concluí em definitivo que, para se trabalhar com o PhpStorm, é necessário mudar o conceito de “onde ficam as coisas”. Deixando esses entraves conceituais à parte, pode-se configurar o deployment em File > Settings > Project Settings > Deployment > Options. E, aqui, uma ótima surpresa: além dos métodos FTP e SFTP, que são praxe, o PhpStorm permite também a criação de destinos em pastas montadas ou locais (!), para o caso de se ter acesso ao servidor Web pela rede local, o que é o meu caso. Esse tipo de configuração eu só havia visto antes no Adobe Dreamweaver.
Opções de destinos de "deployment" no PhpStorm

Opções de destinos de "deployment" no PhpStorm

Após o destino configurado, é possível enviar o arquivo para o servidor remoto clicando sobre o arquivo desejado na árvore do projeto e selecionando Upload to <nome do projeto>. Faltou, porém, uma opção de download a partir do servidor remoto, e a função Synchronize parece não ter sido ainda implementada: ao ser acionada, informa que o processo foi concluído com sucesso, mas nada acontece efetivamente.

A função de Code Completion é muito boa, retornando as sugestões quase que instantaneamente.

"Code completion": nem dá tempo de pensar

"Code completion": nem dá tempo de pensar

A impressão geral e inicial passada pelo JetBrains PhpStorm é a de um produto que está no caminho certo, mas que, apesar de estampar 1.0.2 como número de versão, demonstra ter ainda muito o que melhorar e evoluir. Nos próximos dias, continuarei explorando-o. Pelo que já vi de suas capacidades de depuração, a configuração parece ser a mais fácil dentre todos os IDEs que já analisei. Espero voltar em breve com um post específico sobre este tópico :).

Enquanto isso, se você desenvolve em PHP e puder fazê-lo, baixe também o JetBrains PhpStorm e dê um pouco de atenção a ele. Tudo leva a crer que valerá bastante a pena.

jQuery: evitando conflitos com outros “frameworks” Javascript

Post publicado originalmente em http://devfranca.ning.com/group/jquery/forum/topics/jquery-evitando-conflitos-com-1 em 7 de outubro de 2009

Que o jQuery é ótimo, todo mundo já sabe (ou pelo menos deveria saber). Um dos seus mais poderosos recursos é o atalho $, que, entre tantos outros usos, substitui com vantagem o famigerado document.getElementById().

Nada obstante, os problemas com o $ começam quando se usa o jQuery com outros frameworks, que também usam o cifrão para alguma coisa. Experimentei esse problema ao combinar jQuery com Scriptaculous.

Mas nem tudo está perdido. Há algumas saídas:

  1. Utilizar o método noConflict() do jQuery, atribuindo o resultado a uma variável, que então substituirá o cifrão. Isso deixa o cifrão livre para uso por outros frameworks. Esse método, pelo menos para mim, não deu certo (o jQuery continuou funcionando, mas o Scriptaculous não):
    jq = jQuery.noConflict();
    jq("#elemento").hide(); // Ao invés de $("#elemento").hide();
    
  2. Utilizar o próprio objeto jQuery no lugar do cifrão. Esse método “eu agarântio”, mas precisei fazer um “Encontrar/Substituir” todos os "$" por "jQuery" também no código fonte dos plugins (que, invariavelmente, usam o cifrão):
    jQuery("#elemento").hide(); // Ao invés de $("#elemento").hide();
    

Fica a dica! 🙂

Por que usar um “framework”

Todo desenvolvedor, não importa qual a linguagem em que trabalhe, certamente há de ter feito a si mesmo, pelo menos uma vez, a seguinte pergunta: devo ou não utilizar um framework? Ouso dizer que a resposta é SIM. E passo a detalhar as razões da minha assertiva.

Imagine, nos tempos pré-históricos, como nossos remotos ancestrais se viravam para sobreviver. Tinham que inventar suas próprias ferramentas, arranjar o que vestir. Até fazer fogo era algo extremamente trabalhoso. Felizmente, não vivemos mais naquela época. Mas alguns desenvolvedores ainda insistem em viver na Pré-História da programação, quando precisavam fazer quase tudo a partir do zero e “na unha”. Para defender sua postura em não adotar um framework, costumam lançar a questão “E se esse troço der pau, quem vai consertar?”.

Esse tipo de desenvolvedor é aquele que se apega de tal modo a seu “jeito de fazer as coisas”, ao ponto que todo código não escrito por ele mesmo lhe parece esotérico ou produto de seres alienígenas. Aqui vale um alerta: se você olha para o código-fonte de um framework e não entende nada do que está escrito ali, volte para casa zero e comece a estudar sua linguagem novamente!

O programador troglodita crê piamente que o valor do seu trabalho está no (mau) código que escreve, e não na solução que oferece para o problema do cliente. É aquele que foge o quanto pode das linguagens interpretadas, porque o aplicativo precisa do código-fonte para ser executado e “todo mundo pode ver e se apossar do que eu fiz”. É aquele cara que, nos idos do glorioso Clipper (uma linguagem semicompilada), morria de medo do Valkyrie, um utilitário capaz de traduzir o bytecode executável de volta a código-fonte.

Os melhores frameworks disponíveis na atualidade baseiam-se em padrões de desenvolvimento, giram em torno de uma grande e ativa comunidade e suas versões são testadas com rigor antes de serem disponibilizadas ao grande público. Tudo isso se traduz em qualidade de software, o que, certamente, as soluções do nosso companheiro troglodita não tem.

Adotar um framework significa, num primeiro momento, renúncia. Você abrirá mão do seu jeito de fazer as coisas para endossar o dele. Na maior parte das vezes, isso significa parar de contemplar o próprio umbigo e olhar ao redor, onde mais gente faz mais coisas de forma semelhante, e, portanto, tem problemas similares. Todos começam a falar a mesma língua, e fica mais fácil pedir ajuda e ajudar.

Muitos tomam o tempo que se gasta no aprendizado de um framework como perdido. Eu não veria desta forma. Antes, eu consideraria essas longas horas como auto-instrução e aperfeiçoamento profissional. O resultado, por certo, não aparecerá logo de início (para desespero dos apressados), mas terá reflexos num futuro melhor.

Obviamente, de nada adianta tentar aprender a trabalhar com um framework a toque de caixa para aplicá-lo naquele projeto que era para ontem. Aconselho que essa atividade de aprendizado se dê em paralelo ao desenvolvimento rotineiro, e, a menos que se tenha tempo disponível para erros e tentativas, não utilizar o framework em um projeto sério enquanto não entender seu funcionamento e se sentir minimamente confortável com ele.

Em suma, creio que a grande diferença entre utilizar ou não um framework é a mesma entre ter uma caixa de ferramentas de alta qualidade prontas para o uso, e já partir para o trabalho, ou perder tempo (re) inventando a roda, frequentemente de modo improvisado.

E você? Já escolheu seu framework preferido?

Faenza, o aguardado tema de ícones para GNOME, finalmente disponível

Quem utiliza o script Ubuntu Perfeito para personalizar a sua instalação do Ubuntu, certamente já conhece os temas GTK+ Equinox, instalados por aquele. O Equinox vem associado ao tema de ícones Faenza, que até então não existia.

Pois bem. Acabou de sair do forno o conjunto Faenza, na sua incipiente versão 0.5. Apesar de não estar totalmente concluído, o que já temos é suficiente para afirmar que a espera valeu a pena.

Faenza 0.5 (Uau!)

Faenza 0.5 (Uau!)

Download via GNOME-Look.org.

Se você gostou deste post, pode gostar também de: Meliae SVG, novo e vibrante conjunto de ícones para o GNOME

Ensaio sobre a orkutização do Twitter

Há algum tempo, tenho notado, na minha timeline, variadas reações acerca da orkutização do Twitter, fenômeno que a cada dia torna-se mais evidente. Or.ku.ti’za.ção (s.f.), com o perdão do neologismo, foi o termo encontrado para definir a progressiva degradação da relevância e utilidade prática – numa palavra: banalização – de uma ferramenta social, fato que por primeiro manifestou-se numa certa rede criada por um engenheiro de software de nacionalidade turca e funcionário do Grande Oráculo.

O Twitter, quando de seu surgimento, parecia algo hermético e esotérico, associado a gente hiperdescolada e early adopters de tecnologia. Era difícil vislumbrar a serventia de uma coisa que lhe perguntava What are you doing? e não lhe deixava responder com mais de 140 caracteres. À medida que o serviço foi agregando usuários, muitos dos quais ali desembarcavam guiados pela mais cândida curiosidade, o Twitter finalmente encontrou sua vocação: ser uma fonte de informações em tempo (quase) real, que, devido à forma com que estruturava seus usuários (seguidores e seguidos), transformou-se numa máquina de virais – para o bem ou para o mal. E toda essa repercussão, por óbvio, retroalimenta o fluxo de novos usuários.

Em algum ponto de sua curta história, o Twitter tornou-se a sensação do momento. Todos desejam estar nele, muitos querem utilizá-lo para angariar fama, outros estão ali apenas para não serem diferentes. Exatamente como, era uma vez, aconteceu com o orkut. Ou alguém já se esqueceu de que, um dia, foi necessário convite para entrar na rede social do Google?

Com o ingresso dos novos usuários, movidos por hype, sensacionalismo e modismo, não se podia esperar outra reação que não um misto de revolta e decepção dos veteranos. Afinal, usurparam a esses últimos sua casamata. Tiraram-lhes a exclusividade que julgavam ter sobre aquilo que até então era coisa para iniciados. E eis que o derradeiro obstáculo a impedir a definitiva invasão das hordas enfurecidas, a barreira linguística, está prestes a ruir, já que lá vem o Twitter em português. E, mesmo antes disso, o #TTBr constituiu-se, invariavelmente, no supra-sumo da futilidade.

Guardadas as proporções e respeitada a diferença de contexto, é o mesmo temor que acometeu os pioneiros do orkut quando este serviço abriu-se a qualquer interessado. E sequer é preciso ter poderes metafísicos para prever que, mais cedo ou mais tarde, a orkutização assolará também o Facebook – ao qual, aliás, nem me dei ao trabalho de aderir. Em tempo: ainda mantenho um perfil no orkut por pura indolência, mas quase não entro mais lá porque a poeira acumulada ataca minha rinite alérgica 😛 .

O que os indignados usuários do Twitter (ou coloque o nome sua rede social popular ou em ascensão aqui) custam a perceber é que, com frequência, replicam eles mesmos as ações que tanto criticam. Reclamam da baixa qualidade de sua timeline, mas só tuítam coisas de pouca ou nenhuma importância.

Com base em minha própria experiência, e sem querer lecionar qualquer lição de moral, acabei por me impor alguns princípios, que talvez sejam úteis a quem  interessar possa:

  • Não cultivo o hábito de seguir automática e cegamente de volta cada novo seguidor que porventura conquiste. Muitos desses neoseguidores me abandonam após alguns dias, quando veem que não lhes premi o botão Follow. Muito prazer, foi uma honra tê-los me seguindo, mas precisam mostrar conteúdo para que eu considere a possibilidade de vir a segui-los.
  • Consequência imediata do item anterior: seleciono a dedo os perfis aos quais sigo, e não tenho a menor vergonha de dar um unfollow se não corresponder às minhas expectativas. É claro que esse meu comportamento jamais me tornará um sujeito popular – o que nunca fui mesmo.
  • Evito, na medida do possível e da boa memória, tuitar coisas de cunho estritamente pessoal, que não façam sentido para mais ninguém. Como não poderia deixar de ser, o conceito de “sentido” aqui é o mais elástico quanto possível. Por vezes faço piadas (muitas vezes sem graça 😐 ) com os tuítes alheios – mas isso não é, de forma alguma, o principal objetivo pelo qual estou no Twitter. O microblog permitiu-me construir uma rede de relacionamentos que – assim espero – venham, um dia, render frutos, especialmente no campo profissional. E não desejo jogar isso para o alto a troco de nada.
  • Por fim, o ditado “não faça aos outros o que não quer que façam a você” aplica-se perfeitamente ao universo das redes sociais. O Twitter é, para mim, uma ferramenta e, nessa qualidade, deve ser-me útil. Busco ali coisas que me agreguem conhecimento ou, ao menos, um pouco de diversão. Tendo essa ideia em mente, procuro partilhar eu também dessas mesmas coisas.

E você, que anda incomodado com a orkutização? Continuará sendo tão-somente reativo ou adotará uma postura proativa? 8)

O Yii Framework e os “models” (modelos)

Dando seguimento à série de artigos sobre o Yii Framework, desejo compartilhar algumas reflexões acerca dos modelos (models) do padrão de desenvolvimento MVC e de como o Yii Framework implementa o conceito.

Para deixar as coisas mais claras, tomei a liberdade de traduzir a definição de modelo constante deste artigo da Wikipédia de língua inglesa (quase sempre mais completa que a versão lusófona):

O modelo é utilizado para gerenciar informações e notificar os observadores quando a informação é alterada. O modelo é a representação dos dados específica de um negócio, sobre os quais a aplicação trabalha. A lógica de negócio dá significado aos dados brutos (como, por exemplo, determinar se hoje é o dia do aniversário do usuário, ou os totais, impostos e valores de frete para itens de um carrinho de compras). Quando o estado do modelo se altera, este notifica suas visões [views] associadas, de forma que elas possam ser atualizadas.

Várias aplicações usam um mecanismo de armazenamento persistente, como um banco de dados, para guardar os dados. O padrão MVC não menciona especificamente a camada de acesso aos dados, porque se supõe que ela esteja sob o modelo ou encapsulada por este. Modelos não são objetos de acesso a dados; contudo, em aplicações muito simples, com pouca lógica de negócio, não há nenhuma distinção efetiva a se fazer. O Active Record é um padrão de desenvolvimento bem aceito e que une o código da lógica de negócios e o de acesso aos dados – um modelo que sabe como persistir a si mesmo.

Do que foi abordado acima, aprofundemos dois tópicos.

1. O modelo nem sempre está relacionado a um objeto de banco de dados

Isso pode soar estranho, mas basta pensar um pouco para dar razão à assertiva. O ciclo de vida de uma aplicação MVC é, basicamente, coletar dados por intermédio de um formulário (visão, view), filtrá-los segundo as regras de negócio (o que é feito no controlador – controller) e armazená-los para posterior consulta, usando os modelos (models) para tanto.

Há ocasiões, no entanto, em que os dados coletados não precisam ou não devem ser armazenados – eles são necessários apenas em uma etapa intermediária do processamento. Talvez o exemplo mais típico dessa situação sejam os formulários de login, nos quais coletamos um nome de usuário e uma senha, que servem à autenticação/autorização. Depois disso, o nome do usuário (ou seu código, dependendo da lógica implementada) é, no máximo, armazenado num cookie ou num objeto de sessão. Armazenar a senha seria um total contrassenso, por questões de segurança.

O que nos impede, então, de representar os dados de um formulário de login como um modelo? É exatamente isso que o Yii Framework faz. Em todo projeto iniciado com o auxílio da ferramenta de linha de comando yiic, é gerado um modelo chamado LoginForm (na pasta protected/models), cujo conteúdo é o seguinte:

class LoginForm extends CFormModel
{
	public $username;
	public $password;
	public $rememberMe;

	private $_identity;

	/**
	 * Declares the validation rules.
	 * The rules state that username and password are required,
	 * and password needs to be authenticated.
	 */
	public function rules()
	{
		return array(
			// username and password are required
			array('username, password', 'required'),
			// rememberMe needs to be a boolean
			array('rememberMe', 'boolean'),
			// password needs to be authenticated
			array('password', 'authenticate', 'skipOnError'=>true),
		);
	}

	/**
	 * Declares attribute labels.
	 */
	public function attributeLabels()
	{
		return array(
			'rememberMe'=>'Remember me next time',
		);
	}

	/**
	 * Authenticates the password.
	 * This is the 'authenticate' validator as declared in rules().
	 */
	public function authenticate($attribute,$params)
	{
		$this->_identity=new UserIdentity($this->username,$this->password);
		if(!$this->_identity->authenticate())
			$this->addError('password','Incorrect username or password.');
	}

	/**
	 * Logs in the user using the given username and password in the model.
	 * @return boolean whether login is successful
	 */
	public function login()
	{
		if($this->_identity===null)
		{
			$this->_identity=new UserIdentity($this->username,$this->password);
			$this->_identity->authenticate();
		}
		if($this->_identity->errorCode===UserIdentity::ERROR_NONE)
		{
			$duration=$this->rememberMe ? 3600*24*30 : 0; // 30 days
			Yii::app()->user->login($this->_identity,$duration);
			return true;
		}
		else
			return false;
	}
}

A classe CFormModel, na hierarquia do Yii Framework, descende de CModel. Estão ali alguns métodos que costumamos ver nos posts anteriores, como o rules(), que estabelece as regras de validação para os dados, e o attributeLabels(), no qual podemos definir os nomes dos campos na linguagem natural do usuário.

Os dados de login são colhidos e processados, mas nunca armazenados em banco de dados – mesmo porque nem a classe CFormModel, nem sua ancestral, CModel, implementam um método save(). Pelo “jeitão de ser” do Yii Framework, CFormModel deve ser usado toda vez que os dados do formulário não serão armazenados (ao menos diretamente) num banco de dados. Para o trabalho com banco de dados, utilizamos o CActiveRecord.

2. O Active Record reúne em si regras de negócio e código de acesso a dados

O quão chocante lhe parece esta afirmação? Trata-se, é verdade, de uma quebra do paradigma MVC, que preconiza que as regras de negócio devem residir unicamente no controlador (controller). Ponderemos, porém: validação de dados é, em última análise, regra de negócio NOTA MENTAL: escrever um post sobre validação de dados no Yii Framework. E, se esses dados foram ou serão armazenados em banco de dados, a validação precisa obedecer, necessariamente, a definição da estrutura do BD, bem como as características e limitações do SGBD correspondente.

Logo, faz todo o sentido deixar que o próprio modelo verifique se a informação a ser armazenada num campo definido como VARCHAR(100) não ultrapassa esse comprimento. Podemos chamar isso, grosso modo, de forma. O controlador poderia ter-se encarregado de checar essa mesma informação quanto ao aspecto do conteúdo: é um endereço existente? É um nome de pessoa válido? É um município dentro da área de representação da empresa?

Por isso, e para poupar o precioso tempo do desenvolvedor, é que o Yii Framework mantém as regras de validação de dados, quanto à sua forma, no modelo (clique aqui para ver o exemplo de um código de modelo gerado a partir de um objeto de banco de dados), refletindo, sempre que possível, as regras já definidas no BD (tais quais campos requeridos, comprimento máximo, tipo de valor – numérico, alfanumérico, etc.). Tudo isso é implementado estendendo-se a classe CActiveRecord que, por seu turno, também estende CModel.

Concluindo…

O Yii Framework nos leva a repensar o conceito de modelo, desprendendo-o da correlação, julgada muitas vezes  necessária, com um objeto de banco de dados. Com isso, as possibilidades de uso dos modelos ampliam-se, como é o caso do formulário de login anteriormente citado.

O framework também implementa de forma elegante o padrão de desenvolvimento Active Record, encarregando os modelos gerados a partir de estruturas de bancos de dados da validação formal das informações, poupando o desenvolvedor de escrever código para isso 8) .

Para saber mais

  • The Definitive Guide to Yii (em português)
%d blogueiros gostam disto: