Imagem de várias pessoas no Drupalcity Berlin 2011.

{link:http://www.flickr.com/people/29363647@N04/}Drupalcity Berlin 2011{/link}

Sim, é verdade. É difícil encontrar um bom artigo que explique claramente e numa perspetiva de alto nível como o Drupal funciona. Que nos dê the whole picture e assim tenhamos as bases que nos permitam evoluir a partir daí. A maior parte dos artigos falam sobre coisas mais atómicas, como por exemplo, configurar ou adicionar um módulo, criar e configurar tipos de conteúdo, views e blocos. Não sei se concorda, mas faltaria algo, que falasse sobre os pontos principais e relevantes, mas também, que demonstrasse na prática, como uma simples página é gerada. O seu processo. Por isto tudo, criamos este artigo, para que você, que está a dar os primeiros passos (e porque não, para os mais avançados, também) possa ter uma perspetiva global da questão.

 

O Drupal tem uma evolução orgânica. Cresce e evolui sem um roadmap central e impulsionado pelo feedback positivo e negativo da sua base de utilizadores. Eles queixam-se de alguma coisa que funciona de certa forma, e se não deveria, então terá que ser mudado. A partir daí alguém, ou próprio, se disponibiliza a efetivar a mudança.

E até ao momento, pode-se dizer que tem funcionado bem. Claro que existem pontos menos bons nesta perspetiva liberal do desenvolvimento, como por exemplo existirem três linhas de implementações paralelas que fazem exatamente a mesma coisa. Mas, pode-se dizer que o balanço é positivo.

É baseado em PHP, que tem vantagens e desvantagens conhecidas, e não acredita em formas de organização de código que são mais ou menos reconhecidas e aceites como o Model-View-Controller (MVC) ou a Orientação a Objetos (OO). Os módulos podem conter código na forma de HTML e CSS, e isto, para os que já utilizaram frameworks como Rails, Django, entre outros, pode parecer mau, pois é misturar coisas que não se deviam misturar. E se estiver a ver os módulos ou os templates de outra pessoa, eventualmente, poderá acontecer-lhe ter que andar para cima e para baixo na stack. Essa é a beleza ou a dor de trabalhar em PHP/Drupal.

Mas não é por isso, que o Drupal não seja uma aposta vantajosa. Isto porque, tem outras características que funcionam como vantagens inegáveis: é modular, event-driven e skinnable.

  • Modular porque todo o código está estanque e organizado, sendo responsável por certas funcionalidades. Assim, é mais fácil de o manter e evoluir. Claro que, se tirarmos todos os módulos, então é tudo um conjunto de APIs que não fazem nada por si, a não ser um simples 404. Experimente retirar todos os módulos, e o Drupal por si só, recebe o pedido, não sabe o que é, nem tem forma de o saber e mostra um 404. E por isso é que a grande parte da documentação se focaliza na criação de módulos. Eles são, de facto, parte fundamental.
  • Event-driven esta pode funcionar como uma característica substituta, para programadores habituados à lógica OO, pois magicamente funções PHP são chamadas a interagir com eventos à medida que são invocados. E estão à escuta de coisas que podem acontecer. O conceito por detrás de eventos e listeners é o chamado sistema de hooks.
  • Skinnable tudo o que um módulo gera e que pode ser visto pelos utilizadores passa pela camada de theming, camada essa que, recebe os dados num qualquer formato e apresenta-os com o aspeto que se quiser. Por isso, é que é muito importante ter esta separação bem vincada entre o que é lógica e o que é apresentação, e vai-se aperceber disso necessidade, quando quiser lançar uma versão para dispositivos móveis. Aí vai-se lembrar de todos os lugares onde o HTML ficou hard-coded e separado da theme layer.

O Drupal faz muito mais do que parece fazer “out-of-the-box”, porque ao principio tudo parece obscuro e no fim apercebermo-nos que aquilo que fizemos manualmente ele já faria por nós.

Ironicamente, o método de aprendizagem inicial “faz-me apenas um website” não ajuda muito neste caso, já que a curva de aprendizagem é elevada, e podemos logo de imediato não tirar o máximo partido da ferramenta. Aliás, neste caso, até pode ser das piores formas de aprender.

E porquê? Porque as dúvidas são inúmeras. E é assim, porque o Drupal à primeira vista parece extremamente confuso, e com uma stack profunda. Mas, no fundo, no fundo, trata-se de simples PHP procedimental, que se rege por uma arquitetura de event listeners e não, um simples workflow de scripts.

Por exemplo, logo à partida existe alguma chamada de atenção ou alerta para a necessidade de utilizar uma função t() quando estamos a mostrar uma mensagem? Para que serve? E a sua função é muito importante, pois irá permitir que não temos de voltar atrás e rever todas as mensagens quando lançar-mos uma versão noutro idioma.

E claro, que tudo depende do nível de conhecimento que temos, pois se são bons conhecimentos de PHP, um dos excelentes exercícios é ler o o código começando no index.php, e depois passar para o includes/bootstrap.inc, e depois alguns dos outros scripts que estão nesse diretório. São todos ficheiros de inclusão chave, como o menu.inc que é importante perceber como o sistema no global funciona, já que trata de imensos mappings de urls implicitos para o content.common.inc e que tem das funções mais misteriosas que formam a base do API.module.inc, gerindo as invocações de hooks. Outros são o form.inc que trata da disponibilização e submissão de formulários e o theme.inc que trata da camada de apresentação.

Existem também algumas funcionalidades chave no diretório /modules e em particular em /modules/node/node.module pois formam a base do sistema de nós e que em geral é o que é utilizado para encapsular o conteúdo do website. E embora, tecnicamente, módulos como o Node e o User parecem ser apenas módulos, eles no fundo, são uma das partes mais importantes do core na arquitetura do Drupal.

Irá reparar que o código é em geral bem comentado e utiliza o markup Doxygen dentro dos comentários.

O processo

Mas o que acontece quando alguém pede uma página? Alguém faz um pedido ao servidor web, e agora? É isso que vamos ver agora.

  1. Estamos com sessão iniciada? Então recebemos uma cookie
  2. O servidor web recebe o pedido e vai ao .htaccess. Aí percebe que tudo deverá ser enviado através do index.php
  3. O index.php do Drupal funciona como um frontside controller. Todas as páginas são encaminhadas por si, e o url/path atuais são pedidos do utilizador que são passados pelo index.php como parâmetro
  4. O path router system do Drupal (MenuAPI) é utilizado para fazer o match entre o path do pedido efetuado e um determinado módulo. Esse módulo é responsável por construir o conteúdo basilar da página. Isto pode envolver o disparar de vários hooks que estejam registados para ajudar na construção de tudo.
  5. Assim que esse conteúdo basilar seja construído, o index.php chama a função theme(‘page’, $content), que envia todo o conteúdo para o sistema de theming/skinning. Aí tudo é consolidado em body, sidebars, headers, widgets, etc.
  6. A página renderizada é reenviada para o servidor web (e.g. apache, nginx, etc.) que a envia para o browser do utilizador.

E, se calhar, como eu, o momento do seu brutal “aha” é perceber que tudo acontece através do index.php e que a partir daí é apenas uma cascata de módulos, passando pelos de core, e dos que estão em /sites.

E também, interessante nisto tudo, é o sistema de hooks do Drupal, que permite despoletar eventos e responder a outros, utilizando uma simples convenção de nomes para funções. Por exemplo, o módulo “blog” pode intercetar informação do utilizador, simplesmente implementando uma função de nome blog_user() (em Drupal jargon isto é chamado hook_user()) sendo os hooks, múltiplas funções que podem mudar o workflow das coisas e adicionar ou remover informações/dados.

Mas como é que o Drupal sabe se essa função existe ou não? Simples: utilizando a função PHP function_exists() e testando um padrão de nomes para funções, inclusivé essa _user. E por cada módulo verifica se existe ou não. Para acelerar o processo é guardada uma hashtable interna com todas as funções carregadas, o que permite verificar de forma rápida se existe um determinado hook, ao invés de iterar por todos os módulos instalados.

Estou no evento login. Será que a função _login existe? Se assim for, então chamo-a. Será que a função _login existe? Então também a chamo. Não é algo muito elegante e elaborado, mas funciona bastante bem.

Outro exemplo de hook é o hook_cron(). Como o próprio nome cron indica, trata-se de tarefas de manutenção que acontecem a todas as horas, podendo ser invocadas por qualquer módulo, criando uma função para não variar _cron.

Tudo o resto, são pequenos grande pormenores.

As partes interessantes…

  • API layer tudo que existe dentro do directório includes é a API, e é o core que faz o Drupal ser o que é. Todos os módulos acentam em cima deste serviços e no topo de tudo, vive o tema.
  • Menu API é da sua responsabilidade gerir variadas tarefas chave, o que outras frameworks chamam de routing, quando um url é invocado. Tenta saber qual é a função que deverá construir a página e magicamente constrói uma navegação conveniente de menus e breadcrumbs trails.
  • Database Abstraction permite-nos fazer queries a qualquer uma das base de dados disponíveis e para o qual alguém tenha escrito um driver. No Drupal 7 é ainda mais fácil, já que está a ser utilizado o PDO, que é uma libraria standard PHP.
  • Session Handling o Drupal guarda e gere toda a informação de todos os utilizadores com sessão iniciada ao longo de varios web hits.
  • Output Filtering gere o processo de filtrar dados, incorretos, incompletos ou duplicados de JavaScript, bem como outros.
  • Caching é a capacidade de gerar output estático de uma página, para que o Drupal não tenha que a gerar novamente a cada request efetuado.
  • Batch Processing são operações multistage onde é necessário fazer o reload de páginas através de milhares de nós.
  • Module system permite-nos carregar módulos de uma pastá e utilizar um sistema de hooks para anunciar eventos para eles.
  • Update system permite que saibamos quais as partes do código que estão dessincronizadas com as versões mais recentes albergadas nos repositórios centrais.
  • Unicode utilities podemos utilizar um sem numero de funções que asseguram a localização das mensagens e que se responsabilizam de tratar devidamente textos de outros idiomas.
  • Outras APIs: File storage, Locale & Language, Themeing (Rendering), Forms & Processing, Image Manipulation, Email handling e XMLRPC.

Drupalisms

E como existe technical jargon em todas as áreas que dá imenso jeito sabermos o que significa para não ficarmos à margem dos acontecimentos, ficam aqui um conjunto de Drupalisms e respetivos significados.

  • Hooks o sistema de hooks não é nada mais, nada menos, do que event listeners que, são fundidos e depois verificada a sua existência com a simples função function_exists do PHP. Se existe, então é invocada.
  • Info Arrays o Drupal utiliza nested arrays gigantes para passar informação de um lado para o outro, e nós, podemos injetar os valores que quisermos nesse array, tendo apenas que olhar previamente para os docs da API para saber que diferentes estruturas de arrays existem.
  • Callbacks quando estamos a definir um array podemos nomear uma função PHP com um nome especifico, o que fará que, com o processamento do array, essa função irá ser chamada.
  • Renderables são arrays criados pelo Node e Form API, e que, no Drupal 7, a estrutura integral da página está num renderable. É um XML na forma de array. Aqui um pormenor importante é que se não tiver um cardinal à frente é porque é um nested element, mas se tiver um cardinal então, é uma propriedade de um elemento pai.
  • Alter Hooks esta é a melhor parte disto tudo. O benefício de utilizar arrays para tudo. Isto porque, ainda antes de chegar o que quer que seja ao browser e ser renderizado para o utilizador final, o Drupal pergunta se alguém quer alterar o que quer que seja. Ou seja, com estes alter hooks podemos customizar as entranhas de outros módulos sem termos que mexer no seu código.

O D7 trouxe o code registry

O Drupal 7 trouxe algo de inovador, de nome code registry, que é um inventário de todas as classes e interfaces de todos os módulos que estão ligados e disponíveis. É guardado o caminho para o ficheiro que detém a classe ou a interface onde está definido, e é carregado esse mesmo ficheiro sempre que necessário, através de um mecanismo de autoloading do PHP.

Assim, o Drupal só vai carregar algo se necessitar, diminuindo desta forma a quantidade de código carregado por cada request e reduzindo o footprint de memória utilizada. Existe apenas uma exceção, pois o único ficheiro que é sempre carregado incondicionalmente pelo Drupal é, o module_name.module, e qualquer código que precise de estar sempre disponível sem utilizar o registry deverá ser colocado neste ficheiro.

Este registro é construído sempre que módulos são ligados ou desligados de forma a incorporar novo código ou a remover código de módulos desativados. Por isso, se estiver a desenvolver novo código que queira ser incluido, terá que garantir que o registro é reconstruido com regularidade, e assim novos recursos sejam incorporados. Para isso, limpe toda a cache ou invoque a função registry_rebuild(), pondo-a por exemplo, no template.php.

E pedir para reconstruir um registo existente, para serem incorporadas novas mudanças não é assim tão exigente, já que o registry não irá fazer o reparse dos ficheiros que tenham o mesmo path e timestamp de modificação do último build.

Repare, no entanto, que os ficheiros que não contêm classes e interfaces que precisem de ser utilizadas em qualquer momento pelo ficheiro de módulo não precisam de estar listadas na propriedade files dentro do ficheiro .info. Ao invés, esse código deverá continuar a ser carregado sempre que for preciso, utilizando a propriedade file do hook_menu().

E se o módulo introduzir mais hooks por si próprio até é recomendável utilizar o hook_hook_info() para permitir que implementações de outros módulos sejam carregadas automaticamente.

Troubleshooting? Como o fazer?

E o troubleshooting? De preferência sem colocar funções var_dump em tudo o que é sítio.

Claro que tudo depende do problema que enfrentamos mas o módulo Devel pode ajudar, já que nos dá ferramentas interessantes e que nos dão informação complementar. Desde funções para admins, como um relatório de todas as queries de base de dados que foram feitas no fundo da página, e que inclui quantas vezes essa querys foram executadas, uma função de nome dprint_r($array) que mostra a informação de um array de forma muito mais bonita e até um mecanismo de criação de conteúdo dummy.

Mas, na grande maioria dos casos, o grande passo a tomar é identificar o módulo ou módulos responsáveis por construir uma determinada página.

Olhe para funções como o hook_menu() que mapeia os paths/urls por módulo e depois identifique os callbacks que estão a ser feitos.Veja o drupal_get_form() que serve para a construção de formulários, ou o theme(‘qualquer coisa’) que serve para construir HTML. Veja também como estão a ser utilizadas funções como o drupal_alter() ou o module_invoke_all que invocam eventos para outros módulos.

O debugger é também um bom exercício

Outra das formas de perceber como tudo se passar no interior do Drupal é utilizar um debugger, e uma das excelentes combinações que poderá utilizar é o Netbeans com o xDebug que lhe irá permitir percorrer todo o processo e ver “in loco” as diferentes fases de construção de uma página.

O Netbeans, traz também a possibilidade de fazer drill-drown nas funções e perceber o que recebem, o que retornam e que lógica as sustenta.

Poderá instalar uma versão de teste e definir um objetivo a atingir. Assim, é sempre mais fácil.

E agora?

Leia bastante sobre o tema, e para começar veja os handbooks, e especialmente se é themer o theme developers guide. Se, por outro lado, for um programador nato e preferir olhar para o desenvolvimento de módulos, a API é o local para onde deve ir. Aqui estão documentadas todas as funções disponibilizadas.

O sítio da IBM é também um bom lugar onde aprender, especialmente esta área dedicada à criação de websites colaborativos utilizando software open-source.

Outra alternativa, são os livros, e dois dos melhores livros são o “Pro Drupal Development” e “Using Drupal”.

O primeiro inclui vários flowcharts e resumos de cada uma das APIs do drupal (form, themming, etc.) e parece-me que o seu objetivo é que seja instrutivo para que consigamos fazer os nossos próprios módulos e temas. Claro, que traz muito valor para o mediano programador PHP que quer entender como funciona o Drupal.

O segundo, “Using Drupal”, recomendo a qualquer um que queira aprender Drupal da melhor maneira possível. É para o webdeveloper que quer saber como construir coisas interessantes como galerias, blogs e redes sociais. Apresenta vários use-cases que mostra como configurar módulos já existentes para atingir cada um dos objetivos, e no processo acaba por familiarizar-nos com módulos de referência como o “Content Construction Kit” (CCK) e as “Views”. Todos os ins-and-outs para fazer um website.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

E como uma imagem vale mais do que mil palavras, para finalizar fica aqui este vídeo que tenta explicar em 57 segundos o que é o Drupal (Rarepattern).

Texto escrito de acordo com o novo acordo ortográfico.

Tags: , , ,

Deixar um Comentário

Smartphones Android - As Nossas Escolhas

Análise ao LG G Flex – o ecrã curvo, será o futuro?

lg g flex ecrã curvo

Análise ao HTC One M8 – A sequela está de volta!

smartphone htc one m8

Análise ao OnePlus One – o smartphone redefinido

smartphone android oneplus one

Análise ao Samsung Galaxy S5 – O que precisa de saber

samsung galaxy S5 em branco

Samsung Galaxy S5 vs iPhone 5S

iphone 5S e Samsung Galaxy S5

LG G2: A LG Regressa À Boa Forma

smartphone lg g2

BQ Aquaris 5 Dual SIM – O phablet da espanhola BQ

imagem do bq aquaris 5

Samsung Galaxy Note 3 – O phablet do momento

phablet samsung galaxy note 3

Sony Xperia Mini: Quando O Tamanho Não É Tudo

Sony Xperia Mini EM Branco

Sony Xperia L: Quando A Beleza Não é Tudo

smartphone sony xperia L

Samsung Galaxy Express: Mais Um Líder De Mercado Ou Um Flop?

smartphone galaxy xpress

HTC One: Uma Autêntica Maravilha Tecnológica

smartphone HTC One