Encontrei um site interessante que disponibiliza um XML com a cotação, o código, disponibilizado por Felipe Olivaes, pode ser encontrado na República Virtual, onde também são encontrados alguns outros serviços interessantes, como busca de CEP e alguns utilitários de manipulação de texto.

Infelizmente, o código não segue o padrão de um webservice, com uma descrição WSDL, o que inviabiliza o uso em alguns sistemas, então resolvi procurar uma outra solução. Depois de algumas buscas acabei encontrando a informação que precisava no primeiro lugar que deveria ter buscado, no site do Banco Central. O BACEN disponibiliza um webservice com informações completas sobre a cotação do dólar, além de possiblitar a consulta por séries anteriores. Você encontra o wsdl do webservice nesse link: https://www3.bcb.gov.br/sgspub/JSP/sgsgeral/FachadaWSSGS.wsdl

Para utilizar o webservice do BACEN, adicone uma referencia de projeto para a WSDL acima, o Visual Studio automaticamente irá obter as informações sobre os métodos disponibilizados no webservice, após isso precisamos apenas utilizá-lo.

Veja abaixo um exemplo de código.

  try
  {
    var webservice = new FachadaWSSGSClient();
    var valores = webservice.getUltimosValoresSerieVO(1, 1);
    var ultimo = valores.valores[0];
    MessageBox.Show("O dólar agora vale: " + ultimo.svalor);
  }
  catch (Exception exception)
  {
    MessageBox.Show(exception.Message);
  }

Observe que passamos 1 e 1 como parametros do método getUltimosValoresSerieVO(), esses parametros representam a quantidade de valores que você deseja obter, como nesse exemplo apenas o último me interessa, estou buscando apenas do valor 1 até o valor 1. O array valores nesse momento possui a última cotação disponível (na posição 0), sinta-se à vontade para utilizar o webservice para obter também outras informações. Apesar de possuir algumas limitações (como um limite de 20 valores ao obter a cotação), o este webservice do Banco Central é muito útil, e simples de utilizar, sem falar que vem da fonte mais confiável possível.

Nesse exemplo, irei utilizar o arquivo de configuração para conectar à uma base de dados MySQL, em caso de dúvidas sobre arquivos de configuração, leia o post anterior.

; /application/configs/application.ini
database.adapter = pdo_mysql
 database.params.host = 127.0.0.1
 database.params.username = usuario
 database.params.password = 123
 database.params.dbname = bd_teste

Após inserir as informações no arquivo .ini, o próximo passo é tornar essas informações disponíveis para toda a aplicação, para isso usaremos o componente Zend_Registry.

// /application/Bootstrap.php
protected function _initDb()
  {
  $config = new Zend_Config_Ini('configs/application.ini', APPLICATION_ENV);
  Zend_Registry::set('db', $config->database);
  }

No Bootstrap podemos executar comandos no momento da inicialização de cada componente do Zend Framework, as funções _init* são responsáveis por isso. Nesse exemplo, estamos obtendo as configurações que foram definidas no arquivo application.ini e tornando-as disponíveis no Zend_Registry, para que possamos utilizar na nossa aplicação.

Agora, como realizar as tarefas básicas de manipulação de banco de dados nos nossos controllers? Eis a resposta:

Primeiramente, precisamos obter as informações do registro. Sempre que precisar manipular banco de dados em uma action, você deve criar uma instancia de Zend_Db.

// /application/controllers/indexController.php
    $db = Zend_Db::factory(Zend_Registry::get('db')->adapter, Zend_Registry::get('db')->params);

Observe que utilizo o factory do Zend_Db, e passamos como parâmetro o tipo de banco de dados (pdo_mysql) que foi definido no arquivo .ini e os parametros de conexão.

Agora, supondo que temos uma tabela chamada produtos, com os seguintes campos: id, nome, fabricante e preco. iremos inserir um registro nessa tabela, veja o exemplo completo:

// /application/controllers/indexController.php
public function IndexController extends Zend_Application_Action{
  public function indexAction()
  {
    $db = Zend_Db::factory(Zend_Registry::get('db')->adapter, Zend_Registry::get('db')->params);
    $db->insert(
      'produtos', array(
        'nome' => 'Lumia 800',
        'fabricante' => 'Nokia',
        'preco' => '1799.00'
      )
    );
  }
}

A função insert() recebe como parâmetro uma string com o nome da tabela e um array associativo com os dados a inserir, o código acima é equivalente à seguinte expressão SQL:

INSERT INTO produtos ("nome", "fabricante", "preco") VALUES ("Lumia 800", "Nokia", "1799.00")

Com as funções de update, delete e select, podemos utilizar um importante recurso chamado de binding, que consiste basicamente em utilizar o caractere curinga ? como parâmetro, isso permite que o próprio ZF se encarregue de tratar as entradas  da forma apropriada.

$id_editar = 1;
$db->
  update("produtos", array("preco" => "1699.00"), array(
  "id = ?" => $id_editar
  );

O código abaixo seria equivalente à seguinte expressão SQL:

UPDATE produtos SET (preco = "1699.00") WHERE (id = "1")

Método delete:

$id_excluir = 1;
$db->
  delete("produtos", array("id = ?" => $id_excluir);

Com a expressão select, a sintaxe não muda, exceto pelo fato de que teremos de atribuir o resultado para uma variável, e passar esses dados para a camada view da nossa aplicação.
Você pode escolhar que formato deseja obter os dados (array associativo, objeto, string, etc), veja os exemplos a seguir:

$query_select = $db->select()->
  from("produtos")->
  where("preco > ?", "999.00");
//Nesse momento a variável $query_select = "SELECT * FROM produtos WHERE preco > "999.00"
//O próximo passo é atribuir o resultado a uma variável
$resultados = $db->fetchAll($$query_select);
//Agora passamos o array $resultados para a camada view:
$this->view->resultados = $resultados;

Para mais informações e exemplos de querys mais complexas, visite o manual oficial do Zend Framework, ou deixe sua dúvida nos comentários abaixo, nos vemos no próximo artigo.

Na ocasião a Nokia estava lançando os celulares da Série N (Nseries), mas o interessante mesmo é ver como a Nokia tratou nesse vídeo a evolução das tecnologias, mostrando como elas tem mudado a forma de interação na sociedade.

Apesar desse vídeo ser de apenas 4 anos atrás, não deixa de ser nostaugico, afinal a tecnologia evoluiu pra caramba de 2008 pra cá... Espero que você goste

/p

O Less Framework basicamente é um framework (¬¬ jura ?) CSS que torna mais simples o desenvolvimento de layouts para diversos tamanhos de tela, com ele você pode tornar a visualização das páginas do seu site otimizada tanto para telas grandes, com resoluções acima de 1280 x 1024 quanto para telas de dispositivos móveis (como meu pobre celular com resolução de 240x320 pixels).

Com seu sistema em forma de grade dividido em 13 colunas o Less Framework torna extremamente simples a reutilização da composição original do website para reorganizar os elementos quando a tela em que for visualizada não comportar as 13 colunas, em situações em que não é necessária uma interface completamente diferente para dispositivos móveis, o Less Framework é uma excelente alternativa.

Para browsers antigos, como o IE6, o Less não reconhece corretamente o tamanho da tela e exibe o padrão de 768 pixels, ou 9 colunas, mas para browsers recentes, incluindo o navegador do Android, Opera Mobile, Opera Mini, e Internet Explorer 9 Mobile as media querys do CSS3 funcionam e fazem a mágica acontecer.

Com o Less Framework matamos uma ninhada de coelhos com uma cajadada só, e utilizamos na web o conceito WORA (Write Once, Run Anwhere), famoso entre quem desenvolve software.

Para quem quiser conhecer mais, visite o site do Less Framework, sugiro que você veja primeiro a base da versão 3, e quando compreender passe para a versão 4 que é a mais recente.

Recomendo estudá-lo, é um investimento de tempo bastante valioso, e o retorno compensatório: ter seus projetos web otimizados para telas de PCs, smartphones, ipods, tablets, e qualquer outro dispositivo que vir a surgir... Bom para quem desenvolve, e melhor ainda para quem utiliza.

Em qualquer site em que se veja alguma notícia relacionada ao Linux ou ao Windows basta olhar nos comentários  e ver aquelas crianças fanáticas por um dos sistemas defendendo com unhas e dentes o seu predileto. "Linux é complicado, se fosse fácil todo mundo usava", "Windows é a pior coisa que existe", "Lixux", "Rwindows", e por aí vai...

Já encheu o saco ver sempre a mesma coisa, a eterna guerra entre usuários, se você é um desses bizarros usuários Linux que costuma falar mal de quem usa Windows, esse post é dedicado especialmente a você.

Antes de dizer qualquer coisa, leia esse post até o final.

Primeira observação:

Se você usa Linux isso de forma alguma torna você melhor do que quem usa Windows.

Muita gente quando começa a usar Linux e vê que consegue fazer tudo o que fazia no Windows acha que agora é um ser superior, é um pokemon evoluído e agora pode falar mal do Windows, que na verdade nunca prestou pra nada... Isso só tem um nome: babaquice.

Segunda observação:

Linux não é o melhor sistema operacional que existe (pelo menos não para todos)

O melhor sistema operacional é aquele em que o usuário consegue executar sem problemas as suas tarefas. E quando falo "sem problemas" me refiro a não ter dificuldades para executar essas tarefas, e não ter qualquer impedimento que o atrapalhe.

Se você tem maior domínio do Linux, provavelmente pra VOCÊ o melhor SO que existe é o Linux, se alguém domina o Windows e desempenha melhor as suas tarefas nele, então esse será o melhor sistema operacional para ele, e ponto final.

Terceira observação:

Você sabe qual o marketshare do Linux? Tem noção de qual a porcentagem de computadores no mundo que rodam Linux (computadores pessoais)?

Eu respondo: Algo em torno de menos de 2%.

Você já se perguntou: se Linux realmente é o bicho da goiaba, é gratuito e "não pega vírus", porque as pessoas insistem em usar Windows, mesmo que muitas vezes seja pirateado? A resposta é simples: porque Linux hoje é SO para programador ou pessoas ligadas em tecnologia.

Não adianta vir com aquele velho blá blá blá sobre todas as vantagens do Linux (eu as conheço muito bem), o fato é que o usuário comum não tá ligando pra filosofia do software livre e da "comunidade". O usuário comum (esse que a "comunidade" Linux faz questão de esculachar) só quer algo simples e que funcione.

Um exemplo é o OS X, que também é baseado em Unix, é um grande sucesso entre qualquer usuário leigo, e é completamente diferente do Windows. Imaginam o motivo do sucesso entre os usuários? Porque é simples. Porque o usuário consegue fazer tudo o que tenta. Ninguém compra um Macbook e depois pede pra instalar o Windows porque não se ajustou ao sistema operacional.

Quarta (e última) observação

Falar mal dos usuários Windows é bom para a "comunidade" Linux?

Sempre me pergunto se a "comunidade" deseja, que mesmo após 30 anos, o Linux continue com sua participação praticamente irrelevante na área de computadores pessoais. Me pergunto se é do desejo da "comunidade" continuar tendo um magnífico S.O. (leia-se: kernel), mas continuar com seus menos de 2% de participação entre usuários domésticos.

O comportamento dessa "comunidade" mostra que sim. Mostra que as centenas de  milhões de usuários Windows não são interessantes para a "comunidade" Linux. Ter essa fatia de usuários não é importante, a "comunidade" mostra, através do comportamento dos seus usuários, que  o Linux deve continuar sempre sendo algo exclusivo de programador e entusiastas que se identificam com a filosofia de software livre.

Eu, que não faço parte dessa "comunidade" mas gosto e simpatizo com o Linux torço para que um dia alguma distro esteja disputando de igual para igual com o Windows, não digo em aspectos técnicos, mas que um dia uma distro Linux consiga fazer o que o Firefox fez com o IE... Mas enquanto a "comunidade" continuar a desprezar esses usuários em potencial isso nunca irá acontecer. Um usuário Windows desprezado, poderia ser mais um disseminador da cultura Linux... Poderia...

Mas vamos à resposta para a pergunta que fiz no título do post: Devo usar um framework para desenvolver meus projetos PHP? - SIM!

Quando digo que você deve usar um framework para desenvolver os seus projetos eu não me refiro necessariamente a você usar frameworks já desenvolvidos, como Yii, CakePHP, Zend Framework, CodeIgniter, etc. Quando digo que SIM, estou me referindo a você utilizar uma biblioteca bem definida de funcionalidades, classes, e soluções para aqueles problemas macabros que sempre temos no nosso dia a dia. Ou seja, você pode criar o seu próprio framework e utilizá-lo como base para todos os seus projetos.

Criar nosso próprio framework não é uma tarefa fácil,  principalmente no começo, e possivelmente será uma tarefa sem fim. Sempre terá algo a ser aprimorado, novas funcionalidades a serem implementadas, bugs a serem corrigidos, novas tecnologias a serem adaptadas, etc.. É como um filho, que iremos criar e ver ele crescendo e dando bons resultados.

Mas sempre há uma outra alternativa (a resposta para o título do post continua sendo: SIM)

Apesar de ser uma tarefa bastante complexa divertida, criar um framework e utilizá-lo em todos os projetos é complicado e leva bastante tempo, além de que, em muitas situações utilizar o nosso próprio framework não será possível.

Nesses casos podemos também utilizar frameworks já consolidados e poupar um enorme tempo, a comunidade de desenvolvedores PHP mantém alguns excelentes frameworks, algumas empresas mantém outros, mas de qualquer forma utilizá-los pode nos ajudar a poupar um tempo valioso, e economizar dinheiro e neurônios.

Me arriscaria a resumir a ideia de utilizar frameworks "prontos" em uma frase: Pra que querer reinventar a roda?

Os mesmos problemas que você passa horas para resolver já foram em algum momento resolvidos por um outro programador em outra parte do mundo (e provavelmente ele resolveu o problema melhor que você). É triste adimitir, mas é verdade. Os frameworks de desenvolvimento php disponíveis possuem inúmeros componentes, muitos deles solucionando de maneira mais eficiente os problemas que costumamos ter ao desenvolver nossas aplicações, então, porque não utilizar esses componentes prontos?

Outra grande vantagem desses frameworks é a utilização de boas práticas de programação para desenvolvê-los, sempre há uma grande preocupação para desenvolver código limpo, conciso e eficiente, até porque quem for utilizar quer ver algo bem feito, e que inspire criar algo também bem feito.

Há uma grande variedade de frameworks disponíveis na internet, alguns utilizam o padrão MVC, alguns utilizam templates, outros utilizam scaffolding... A variedade de frameworks com diferentes funcionalidades, padrões e formatos me faz pensar que para cada desenvolvedor tem um framework ideal, e caso não haja, faça um favor para você mesmo e desenvolva o seu.

Se você (assim como eu) tem vários browsers instalados no PC é uma brincadeira interessante testar como cada um se comporta. Isso não quer dizer que você deveria usar o que tem a melhor performance, afinal existem outros aspectos a se considerar ao usar um browser, mas é interessante ver a evolução dos engines JavaScript e da capacidade de processamento gráfico.

Performance gráfica: Let it Snow

Nesse teste desenvolvido pela equipe do Internet Explorer 10, a taxa de frames por segundo (fps) a velocidade do processamento JavaScript são avaliados.

Na minha máquina o Internet Explorer 9 e Firefox 9 tiveram um desempenho nitidamente superior.

JavaScript: SunSpider

O RunSpider é um teste JavaScript, e testa a capacidade de processamento dos browsers. Nesse teste (na minha máquina) os melhores resultados foram obtidos pelo Internet Explorer 9, seguido do Google Chrome 16 e do Firefox 9

HTML5 Parser - The HTML5 test

A capacidade de processar os novos elementos do HTML5 não deveria entrar em uma lista de testes de performance, mas já que estamos fazendo teste, não custa nada fazer esse também. Na internet existem dezenas de testes de compatibilidade com HTML5, nesse teste o destaque vai parao Chrome 16, seguido de Firefox 9 e Opera 11.60.

Performance Gráfica 2 - Particle Acceletarion

Outro teste do pessoal da Microsoft, e como era de se esperar o Internet Explorer 9 também se mostra bastante superior, mas o Firefox 9 e o Google Chrome 16 não ficaram muito para trás.

E aí, qual o seu navegador predileto? Ele se saiu bem nesses testes? Fique à vontade para deixar seus comentários...

Se você ainda não utilizou frameworks de desenvolvimento deve estar pensando: "ok, mas o hello world em php se resume a <?php echo 'Hello World!'; ?>", pois bem, usaremos esse exemplo de uma simples saída de string mas usando a estrutura MVC (Model View Controller) implementada em Zend Framework para gerar esse mesmo resultado, e a medida em que você for seguindo no seu projeto você verá as inúmeras vantagens de utilizar essa arquitetura.

Observe que até o momento o nosso projeto não possui sequer um arquivo no nosso diretório público (public_html, httpdocs, www, etc), nós precisaremos apenas de um arquivo .php no diretório público, e a única coisa que ele fará é disparar o inicializador do projeto (Bootstrap). Então, vamos ao que interessa...

// httpdocs/index.php
defined('APPLICATION_PATH') || define('APPLICATION_PATH', '/home/zend/application/projeto/');
defined('APPLICATION_ENV') || define('APPLICATION_ENV', 'testing');
set_include_path(implode(PATH_SEPARATOR, array(APPLICATION_PATH, "/home/zend/library/")));
 
require_once 'Zend/Application.php';
 
$application = new Zend_Application(APPLICATION_ENV, APPLICATION_PATH . '/configs/application.ini');
$application->bootstrap()->run();

6 linhas de código. É o que normalmente você precisa ter no seu arquivo index.php, aproveitamos para criar duas constantes (APPLICATON_PATH e APPLICATION_ENV), que serão usadas posteriormente pela nossa aplicação.

A constante APPLICATION_PATH contém o caminho absoluto para o seu projeto, conforme a estrutura de arquivos definida no post anterior, no meu caso, o projeto se chama "projeto" e está localizada em "/home/zend/application/projeto/", não esqueça de alterar esse caminho para o caminho exato no seu servidor.

Agora algo interessante, a constante APPLICATION_ENV, onde nós configuramos o ambiente da nossa aplicação (de teste, produção, ou desenvolvimento). Apenas alterando esse valor da constante no nosso arquivo index.php poderemos modificar completamente o comportamento da nossa aplicação, ocultando as mensagens de erro do php, conectando a uma base de dados diferente, etc, isso é muito útil quando se quer ter uma aplicação rodando em ambiente de produção e em ambiente de testes, sem que uma interfira na outra, e sem que se precise alterar inúmeras configurações para rodar no seu servidor de testes.

Configuramos também o include path do php, tudo para facilitar o nosso trabalho. Quando o php precisar incluir algum arquivo irá buscar também no APPLICATION_PATH e no diretório "/home/zend/library/", lembrando que esse último contém os arquivos do próprio framework.

Nas últimas 3 linhas a mágica começa a acontecer. Fazemos a inclusão do arquivo "Zend/Application.php", este se encarregará de chamar os outros arquivos necessários.  No próximo passo instanciamos a classe Zend_Application passando como parametro o ambiente atual (APPLICATION_ENV) e o caminho para o arquivo de configuração da nossa aplicação, que criaremos a seguir.

Antes de criarmos o arquivo de configuração da nossa aplicação, vamos apenas cuidar de mais um importantíssimo detalhe na pasta pública, o ".htaccess". Queremos que todas as nossas requisições sejam enviadas para o arquivo index.php, exceto (é lógico) as requisições de imagem, arquivos CSS e JavaScript.

Crie um arquivo .htaccess na pasta pública  com o seguinte conteúdo:

; /httpdocs/.htaccess
RewriteEngine on
 
RewriteRule !\.(js|ico|txt|gif|jpg|png|css)$ index.php

Até o momento isso é tudo que precisaremos no diretório público.

Voltando à parte divertida, agora criaremos o arquivo de configuração da nossa aplicação com o seguinte conteúdo:

; /home/zend/application/projeto/configs/application.ini
[production]
;isso é um comentário
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/library/"
 
; Bootstrap
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
; Controller
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
[staging : production]
 
[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

Não se desespere (ainda), o arquivo application.ini define as configurações da nossa aplicação, nela iremos salvar as configurações de acesso ao banco de dados, o layout utilizado pela aplicação, configurações do php, etc.

Observe que a sintaxe do arquivo, apesar de não familiar a muitos, é bastante simples. Começamos com [production]. Essa tag define que essa será a sessão que define as configurações da aplicação em modo de produção, nessa sessão nós desativamos a saída de erros do PHP, e definimos algumas outras opções, das quais vale a pena destacar a chamada para o arquivo de inicalização do projeto, o Bootstrap.php.

Deixaremos a sessão staging em branco, por enquanto, e apenas iremos tornar os erros visíveis na última sessão, a "testing".

Nas duas úttimas sessões do arquivo .ini nós temos a seguinte sintaxe: [env : production] , isso apenas quer dizer que a sessão irá herdar da sessão production, isso evita ter que repetir algumas partes do código para cada sessão.

Voltaremos ao arquivo .ini posteriormente, agora iremos a mais uma etapa: o Bootstrap.

Talvez você não seja habituado ao termo (ou talvez sim), mas o bootstrap irá nos fornecer métodos para configurar a aplicação em sua inicialização, ou seja, permite que eu defina certos comportamentos e realize algumas operações enquanto carrego a aplicação, em resumo iremos "dar o boot" no nosso sistema, vamos à ele:

//home/zend/application/projeto/Boostrap.php
require_once 'Zend/Loader/Autoloader.php';
 
Zend_Loader_Autoloader::getInstance();
 
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap {
    //That´s all
}

Pronto, esse é o nosso Boostrap (por enquanto).

No momento, para facilitar ao máximo, iremos deixar de lado o que podemos fazer no Boostrap, mas, observe que nesse arquivo nós incluimos mais um arquivo do ZF, o Autoloader.php, e fazemos isso para não ter que incluir mais arquivos manualmente, a instancia dessa classe se encarrega de incluir os arquivos que precisamos, à medida em que precisamos.

Ok, tudo configurado, agora estamos prontos para iniciar (iniciar? o_O OMG!)

O que fizemos até o momento foi cuidar das configurações da aplicação, agora iremos realmente fazer o que queremos: o Hello World.

Lembre-se que utilizaremos o padrao MVC, se já está familiarizado com ele sabe que teremos que implementar a lógica separadamente da saída para o usuário.

Como não entraremos em detalhes sobre banco de dados, até o momento, iremos dispensar a parte de Model, e utilizar apenas o View e o Controller.

Pois bem, os controladores da nossa aplicação deverão seguir a um padrão de nomenclatura estabelecido pelo ZF, esse padrão determina a composição do nome do arquivo e a composição da classe.

Os nossos controladores serão criados na pasta "/home/zend/application/projeto/controllers/" e o seu nome será composto por "NomeControlador" (camel cased) + Controller.php. Exemplo: para o controlador teste, o nome do arquivo seria: TesteController.php, para o controller "alterar aparencia" o nome do arquivo seria AlterarAparenciaController.php, e assim sucessivamente.

O controller será chamado quando o usuário acessar o seu nome (minúsculo) no navegador. Por exemplo: para acessar o controller teste o usuário utilizaria o endereço: http://projeto.local/teste, para acessar o controlador AlterarAparenciaController.php o usuário utilizaria o endereço: http://projeto.local/alterar_aparencia, etc.

O contolador chamado por default quando o usuário acessa a raiz do site é o IndexController.php, e será esse o arquivo que iremos criar:

// home/zend/application/projeto/controllers/IndexController.php
class IndexController extends Zend_Controller_Action {
     function indexAction(){
        Zend_Layout::getMvcInstance()->disableLayout();
        $this->view->hello = "Hello World!";
    }
}

Todos os nossos controladores deverão herdar da classe Zend_Controller_Action. Cada ação deverá iniciar com letras minúsculas, e seguidas de Action. O endereço para o acesso à uma ação será: http://projeto.local/controlador/action, exemplo: o controlador teste tem a ação andar, o usuário acessaria http://projeto.local/teste/andar e o controlador TesteController.php iria executar a ação andarAction(). No nosso caso, por se tratar do controlador index e da ação index, o usuári o pode acessar http://projeto.local/index/index/ ou simplesmente http://projeto.local/

Desativamos o layout (utilizaremos layouts depois), e logo depois enviamos para a camada View do modelo MVC a string "Hello World" .

Portanto, a última etapa será mostrar o resultado, para isso criaremos a nossa primeira view.

As views deverão ser criadas na pasta "/home/zend/application/projeto/views/scripts ", cada controlador "ganha" uma pasta com seu nome (minúsculo, e sem o "Controller"), e cada ação ganha um arquivo com o seu nome (minúsculo e sem o action). Exemplo: para o controlador teste com a ação andar iriamos criar a pasta  "/home/zend/application/projeto/views/scripts/teste " e dentro dessa pasta criaríamos o arquivo "andar.phtml" (observe a extensão: .phtml).

Para o nosso código, nós iremos criar a pasta   "/home/zend/application/projeto/views/scripts/index" e dentro dessa pasta criaremos o arquivo "index.phtml". Por último, iremos exibir o que foi enviado pelo controlador.

<?php
 // home/zend/application/projeto/views/scripts/index/index.phtml
 echo $this->hello; 
?>

Pronto, depois de percorrer esse longo caminho, ao acessar http://projeto.local/ teremos como resultado o nosso esperado "Hello World"
O próximo passo será conectar e manipular uma base de dados, usar layouts e conhecer um pouco mais do Boostrap do ZF. Espero que você volte em breve para acompanhar os próximos posts.
Não esqueça de deixar suas críticas, sugestões, dúvidas, etc. Até a próxima!

Caso ainda tenha muitas dúvidas sobre o framework em si, deixe um recado ao final do post que providencio um outro texto sobre as noções básicas de ZF. E por falar em noções básicas, vamos ao B+A=BA da configuração do Zend Framework...

A primeira dúvida que os iniciantes em ZF podem ter é ao fazer o download do framework, pois encontrarão várias edições, são elas:

Zend Framework + Zend Server Community Edition(CE) 

Versão completa do Zend Framework integrada ao Zend Server, que já possui um ambiente totalmente configurado e otimizado.

Zend Framework Full Package

Essa edição vem com algumas outras ferramentas inclusas, como  o framework JavaScript Dojo, jQuery, além de traduções, códigos de exemplo e documentação.

Zend Framework Minimal Package 

Esse é o pacote recomendado para você que está iniciando, possui apenas os arquivos do próprio ZF e pode evitar confusão com excesso de arquivos que você não vai usar nesse primeiro momento.

O conteúdo central do Zend Framework,  fica localizado na pasta library, que é a pasta que deveremos upar enviar para o servidor. Antes de enviá-la, aqui vai um detalhe: Não envie essa pasta para dentro da sua pasta pública (public_html, ou httpdocs). Por que? Primeiro porque não há necessidade, e em segundo lugar porque o Zend Framework trabalha de uma forma que instrua o programador a utilizar boas práticas, e não é uma boa prática fazer isso, quando você estiver mais a frente no seu projeto você verá que isso não é apenas uma questão de comodidade, e sim uma dica muito valiosa de segurança.

Vamos começar com a estrutura de arquivos recomendada pelo próprio manual oficial do ZF:

  A estrutura ao lado deverá ser criada fora da pasta pública do servidor, criaremos a pasta "zend" e iremos fazer copiar os arquivos da pasta "library" que foi baixada do site oficial.

Os outros deverão ser criados e podem variar de acordo com o seu gosto, vamos à uma breve descrição dos principais diretórios que o manual oficial sugere:

"application/" - será o diretório que irá conter todos os arquivos de todos os seus projetos

"application/projeto"  - esse diretório contém um esqueleto tradicional de uma aplicação no ZF, e você deve trocá-lo pelo nome do seu projeto. Os outros projetos conterão o mesmo esqueleto, e serão colocados na pasta "application", cada uma com o nome que você escolher.

"application/projeto/configs"  - iremos utilizá-la para guardar os arquivos de configuração desse projeto. O Zend Framework trabalha com arquivos de configuração em diversos formatos, como XML, ini e arrays.

"application/projeto/controllers" - se você já costuma desenvolver segundo o padrão MVC, já deve ter notado que essa será a pasta utilizada para armazenar os controladores, ou seja, os arquivos que conterão a lógica para a execução da aplicação.

"application/projeto/layouts" - armazenaremos aqui os arquivos que definem o layout da nossa aplicação. Não estamos falando de CSS/HTML, e sim do arquivo que conterá o modelo padrão de exibição, o layout onde todo o conteúdo de saída do nosso porjeto será executado.

"application/projeto/models" - onde ficarão os arquivos relacionados à camada "model" do modelo MVC, os esqueletos de classe, e arquivos com a lógica de abstração da base de dados serão armazenados nessa pasta.

"application/projetos/views" - aqui iremos configurar os "views" da nossa aplicação, ou seja, a saída para o usuário, os arquivos .phtml serão criados nesse diretório.

"library" - lembre-se que nesse diretório iremos armazenar o núcleo do ZF, ou seja, o conteúdo do framework, que você baixou do site oficial. Não estranhe se dentro da pasta "library" tiver apenas a pasta "Zend", e não diretamente o conteúdo do framework, isso ocorre porque dentro da pasta library também podemos inserir outras bibliotecas.

O primeiro passo para você não se perder ao utilizar Zend Framework é ter uma estrutura de diretórios bem definida, nesse ponto o manual oficial mandou bem ao fazer essa sugestão. Entender bem essa estrutura é fundamental antes de criarmos o nosso primeiro arquivo .php, o que faremos no próximo post.