FACULDADE 7 DE SETEMBRO - FA7
CURSO GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
BRUNO QUEIROZ DUARTE
EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
FORTALEZA – 2011
BRUNO QUEIROZ DUARTE
EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia apresentada à Faculdade 7
de Setembro como requisito parcial para
obtenção do título de Bacharel em
Sistemas de Informação.
Orientador: Prof. Francisco Ivan de Oliveira, MSc.
FORTALEZA – 2011
DEDICATÓRIA
Dedico este trabalho aos meus queridos pais,
David e Jaqueline, à minha querida esposa,
Nayara, e à minha querida tia, Erineire; que
foram meu porto seguro nos momentos bons e
ruins ao longo dessa trajetória. A eles devo o
sucesso alcançado.
AGRADECIMENTOS
Por trás do “grande passo para a humanidade” houve certamente uma série de sucessos e fracassos, que não foram com ela compartilhados. Por trás deste meu “grande passo”, também houve uma série de sucessos e fracassos, e também superações, porém eu tive a sorte de ter tido sempre pessoas com quem compartilhar os sucessos e com quem chorar os fracassos. Este trabalho é apenas um coroamento da minha trajetória até aqui, trajetória essa que não iniciou na faculdade, mas quando ainda nem sabia “dar passos”. Diante deste “grande passo”, tenho no mínimo o dever de agradecer a todos que de alguma forma contribuíram para ele se concretizasse: A Deus, por ter permitido que eu chegasse até aqui, e por ter me dado a sorte e sabedoria necessária em todos os momentos da minha vida. Aos meus pais, por terem me ensinado o valor da família, por todos os valores que hoje tenho, por terem me educado para ser essa pessoa “do bem” que sou hoje, por serem boas referências para mim; e especificamente à minha mãe, que mesmo com pouco estudo me alfabetizou, pelas historinhas que me contava, e por coisas simples como me falar com entusiasmo que aquele animal correndo na TV era uma lebre ao invés de coelho, me incentivando, mesmo sem querer, a ser uma pessoa curiosa e amante do conhecimento. À minha tia, Erineide, por ter me acolhido em sua casa aqui em Fortaleza, e assim ter me possibilitado concluir esta etapa, por ter me amado como um filho, sempre ficando feliz por cada realização minha; e a seu filho, Marlon, por ter me recebido como um irmão e por ter sempre sido uma boa companhia para mim. À minha esposa, Nayara, por ser minha companheira, sempre tendo paciência comigo nas noites que passei em claro durante este trabalho, e por ter me dado forças para concluí-lo. Aos meus irmãos, David Filho e Daniele, por terem sido sempre uma ótima companhia para mim, por me proporcionarem bons momentos e por estarem do meu lado durante grande parte dessa caminhada. Aos meus professores, desde o jardim até aqui, por terem me guiado e me ajudado na construção do meu conhecimento, e principalmente àqueles que foram além da sala de aula, se preocupando com os problemas pessoais de cada um, e inclusive os meus. Aos meus amigos de Ibaretama: Cícero, Eveton, Getúlio, Ivanzinho, Renato, Tamilles, Umbertinho e Zezinho, por terem sido minha primeira e até agora única turma, e por terem me ensinado o quanto é bom ter uma vida social. A todos os autores, livros, e programas de TV (principalmente os da TV Cultura e TV escola) que foram por algum tempo uma agradável companhia e fonte de conhecimentos e lazer.
Ao PROUNI, por ter possibilitado àquele garoto simples e sem grandes pretensões, que achava que iria morrer sem ao menos ver um computador, a cursar um ensino superior na área de TI. A todos os meus colegas da faculdade, principalmente Beatriz, Gimael, Jeferson, Kete, Lucivaldo e Milliam, por terem estado juntos comigo por praticamente todos esses anos, e por terem compartilhado juntos comigo os bons e os difíceis momentos da faculdade. Ao meu professor orientador, Ivan de Oliveira, por ter me guiado na escolha desse tema, por ter sempre me encorajado durante o desenvolvimento deste trabalho, e por ter levantado minha auto-estima nas vezes em que achei que não conseguiria.
À FA7, por ter sido minha terceira casa durante muito tempo, e por sempre ter me dado a possibilidade de estudar com os melhores professores que há; Ao curso de SI e à coordenação do curso, por sempre estarem do lado dos alunos e por buscarem sempre a melhoria do nosso conhecimento. A muitas outras pessoas que não foram citadas aqui, mas que também tiveram uma parcela de importância neste trabalho, meus sinceros agradecimentos.
RESUMO
Este trabalho surgiu da necessidade de se ter um material completo acerca do
desenvolvimento de componentes para a versão 1.6 do CMS Joomla!, visto que a
documentação encontrada na Internet ainda é bastante vaga e dispersa, e os livros
que tratam desse assunto estão desatualizados, sendo que sua maioria aborda a
versão 1.5 do Joomla!. Este estudo tem o objetivo de ser uma fonte de pesquisa
para desenvolvedores de componentes para o Joomla! 1.6, discorrendo sobre
técnicas e padrões que devem ser seguidos para que se possa desenvolver um
componente com arquitetura robusta e extensível, além de apresentar as facilidades
providas pelo Joomla! 1.6 para o desenvolvimento de componentes.
Palavras-chave: Gestão de Conteúdo. CMS. Joomla!. Componentes. MVC.
Internacionalização.
ABSTRACT
This scientific monograph arose from the need to have a complete stuff about the
development of components to version 1.6 of Joomla!, since the documentation
found on the Internet is still quite vague and scattered, and books dealing with this
subject are outdated, and which mostly deals with version 1.5 of Joomla. This study
aims to be a resource for developers of components for the Joomla! 1.6, discussing
techniques and standards that must be followed so that we can develop a robust and
flexible architecture for the component, and present the facilities provided by the
Joomla! 1.6 for the development of components.
Keywords: Content Management. CMS. Joomla!. Components. MVC.
Internationalization.
LISTA DE ILUSTRAÇÕES
Figura 1 _ Estrutura geral de um CMS ...................................................................... 20
Figura 2 _ Estrutura do Sistema de Coleta ............................................................... 21
Figura 3 _ Arquitetura do Joomla! ............................................................................. 35
Figura 4 _ Funcionamento de um Plugin ................................................................... 39
Figura 5 _ Diagrama de Casos de Uso do componente Questões ........................... 43
Figura 6 _ Diagrama de Atividades (Cadastrar Questão) .......................................... 44
Figura 7 _ Diagrama de Atividades (Cadastrar Simulado) ........................................ 45
Figura 8 _ Diagrama de Atividades (Resolver Simulado) .......................................... 46
Figura 9 _ Tela do componente Questões (Listagem de Provas) ............................. 47
Figura 10 _ Tela do componente Questões (Cadastro de Questões) ....................... 49
Figura 11 _ Tela do componente Questões (Listagem de Simulados) ...................... 50
Figura 12 _ Tela do componente Questões (Cadastro de Simulado) ........................ 51
Figura 13 _ Tela do componente Questões (Resolução de Simulado) ..................... 52
Figura 14 _ Estrutura do MVC ................................................................................... 54
Figura 15 _ Estrutura de diretórios do componente Questões .................................. 59
Figura 16 _ Arquivo questoes.php (entry point do componente) ............................... 63
Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado) ............. 65
Figura 18 _ Arquivo view.html.php da visão Simulado .............................................. 67
Figura 19 _ Arquivo simulados.php (modelo de simulados) ...................................... 68
Figura 20 _ Arquivo simulados.php (método populateState) ..................................... 69
Figura 21 _ Arquivo tables/simulado.php .................................................................. 70
Figura 22 _ Estrutura de um pacote de Linguagem .................................................. 72
Figura 23 _ Arquivo ini (arquivo de tradução)............................................................ 73
LISTA DE ABREVIATURAS E SIGLAS
ACL Access Control List
CMS Content Management System
CoC Convention Over Configuration
DAM Digital Asset Management System
DMS Document Management System
ECMS Enterprise Content Management System
ERM Electronic Records Management
ERP Enterprise Resource Planning
GC Gerenciamento de Conteúdo
GPL General Public License
HTML HyperText Markup Language
LAN Local Area Network
OCR Optical Character Recognition
MOS Mambo Open Source
SEO Search Engine Optimization
WAN Wide Area Network
WCMS Web Content Management System
SUMÁRIO
DEDICATÓRIA ............................................................................................................ 2
AGRADECIMENTOS .................................................................................................. 3
RESUMO..................................................................................................................... 5
ABSTRACT ................................................................................................................. 6
LISTA DE ILUSTRAÇÕES .......................................................................................... 7
LISTA DE ABREVIATURAS E SIGLAS ...................................................................... 8
SUMÁRIO.................................................................................................................... 9
1. INTRODUÇÃO .................................................................................................... 11
1.1. OBJETIVO GERAL ...................................................................................... 12
1.2. OBJETIVOS ESPECÍFICOS ........................................................................ 13
2. SISTEMA DE GESTÃO DE CONTEÚDO ........................................................... 14
2.1. O QUE É CONTEÚDO ................................................................................. 14
2.2. GESTÃO DE CONTEÚDO ........................................................................... 15
2.3. BENEFÍCIOS DA GESTÃO DE CONTEÚDO .............................................. 15
2.4. SISTEMA DE GESTÃO DE CONTEÚDO .................................................... 16
2.4.1. Principais funcionalidades de um CMS ................................................. 16
2.4.2. Estrutura de um CMS ............................................................................ 19
2.4.3. Tipos de CMS ........................................................................................ 26
3. O CMS JOOMLA! ............................................................................................... 32
3.1. O QUE É JOOMLA!...................................................................................... 32
3.2. HISTÓRICO DO JOOMLA! .......................................................................... 32
3.3. CONHECENDO O JOOMLA! ....................................................................... 34
3.3.1. Requisitos de instalação ........................................................................ 34
3.3.2. Arquitetura ............................................................................................. 35
3.3.3. Extensões .............................................................................................. 36
3.3.4. Frontend e Backend .............................................................................. 40
4. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA! ...................... 42
4.1. O COMPONENTE “QUESTÕES”................................................................. 42
4.2. MODEL-VIEW-CONTROLLER .................................................................... 52
4.3. INTERNACIONALIZAÇÃO (I18N) ................................................................ 55
4.4. O JOOMLA! FRAMEWORK ......................................................................... 56
4.5. DESENVOLVENDO O COMPONENTE ....................................................... 57
4.5.1. Convenções de codificação ................................................................... 57
4.5.2. Codificação ............................................................................................ 63
4.5.3. Tornando o Questões internacionalizado .............................................. 71
5. CONSIDERAÇÕES FINAIS ................................................................................ 75
BIBLIOGRAFIA ......................................................................................................... 76
11
1. INTRODUÇÃO
Segundo Batista (2007), o conteúdo disponível na internet vem crescendo a cada
dia. Além disso, há também o aumento da necessidade de se ter conteúdo atual e
de natureza colaborativa, onde se possa comentá-lo e até mesmo modificá-lo. As
empresas cada vez mais estão buscando ter uma presença na web, pois isso é
fundamental para que sua marca sobreviva no mercado atual. Tal necessidade faz
parte do conceito de “Darwinismo Digital”, que segundo Romaní e Kuklinski (2007), é
o princípio que explica que no mercado de aplicações web sobrevivem apenas os
mais adaptados. Outro fator responsável pelo aumento da quantidade de conteúdo
na web e da necessidade do dinamismo de tal conteúdo são os próprios usuários da
web. Impulsionados pelos mais diversos objetivos esses usuários necessitam de
ferramentas que os auxiliem na publicação de conteúdo de forma rápida e
transparente, sem a necessidade de conhecimentos de protocolos ou de linguagens
de programação/marcação relacionados à web.
Tanto a necessidade das empresas quanto as necessidades pessoais dos
indivíduos de manter conteúdo de forma eletrônica podem ser satisfeitas com a
utilização de ferramentas chamadas Content Management Systems (CMS), em
português, Sistemas de Gerenciamento de Conteúdo, ou Sistemas de Gestão de
Conteúdo, que facilitam o gerenciamento dos diversos tipos de conteúdo existentes.
Segundo W³Techs (2011), Dentre os vários CMS, um dos mais populares é o
Joomla!, sendo utilizado por 10,5% dos sites que utilizam CMS. Além disso, segundo
Idealware (2011) o Joomla! é o CMS que possui o melhor equilíbrio entre
flexibilidade e facilidade de uso, o que o torna um dos CMS mais cotados para vários
tipos de websites. Parte dessa flexibilidade deve-se às extensões providas pelo
Joomla!, especialmente a do tipo Componente, que possibilitam estender as suas
funcionalidades básicas de maneira simples e rápida. Apesar da vasta
documentação encontrada na web referente à utilização do CMS Joomla!, há certa
dificuldade em se encontrar material referente ao desenvolvimento de extensões,
sendo o site oficial do Joomla! um dos poucos lugares onde se pode encontrar
documentação mais aprofundada. Apesar de aprofundada, a documentação oficial
12
do Joomla! contém algumas informações importantes para o desenvolvimento que
encontram-se dispersas por várias páginas às vezes difíceis de se encontrar. Além
disso, essa documentação não contempla certas peculiaridades que podem
aparecer durante o desenvolvimento e que às vezes são resolvidas somente através
dos fóruns de discussão do Joomla!
Diante dessa crescente necessidade da utilização de CMS em websites, e da
grande parcela de adoção do CMS Joomla! como tecnologia para esses websites,
fazem-se necessárias novas fontes de documentação sobre o desenvolvimento de
extensões, que venham a trazer uma perspectiva diferente para o desenvolvimento
de componentes; das encontradas na documentação oficial.
Este trabalho é dividido em quatro capítulos. O segundo capítulo aborda os
Sistemas de Gestão de Conteúdo, explicando inicialmente o que é conteúdo, depois
explica o que é gestão de conteúdo e seus benefícios, e depois, com esses
conceitos já construídos, explica o que é Sistema de Gestão de Conteúdo,
explanando sobre suas principais funcionalidades, sua estrutura e os principais tipos
de CMS. O terceiro capítulo apresenta uma visão do CMS Joomla!, apresentando
um breve resumo do seu histórico e depois aprofunda-se um pouco mais, explicando
seus requisitos, arquitetura e suas extensões. O quarto capítulo é o principal capítulo
deste trabalho, onde é explorado o desenvolvimento de componentes para a versão
1.6 do Joomla!.
1.1. OBJETIVO GERAL
Explorar o desenvolvimento de componentes para a versão 1.6 do Joomla!,
apresentando a arquitetura padrão que deve ser adotada no componente, padrões
de codificação e boas práticas que devem ser seguidas para melhoria de
extensibilidade, manutenibilidade e segurança do componente.
13
1.2. OBJETIVOS ESPECÍFICOS
Apresentar o que é CMS e para que ele serve, além de categorizá-los por tipo.
Apresentar o CMS Joomla! e explicar sua arquitetura, suas características principais
e conceitos importantes como, extensões, frontend e backend. Apresentar conceitos
de MCV e Internacionalização, que sirvam de base para o completo entendimento
do estudo. Apresentar o componente Questões, componente de coma finalidade de
cadastro de questões e resolução de simulados, que foi desenvolvido durante este
estudo. Apresentar o framewowk do Joomla!, as convenções de codificação que ele
utiliza e as facilidades que ele provê para o desenvolvimento de componentes.
Apresentar os artefatos de desenvolvimento (código) do componente Questões,
como exemplos explicativos da utilização da arquitetura, do framework, das
convenções de código e das boas práticas de programação para componentes com
Joomla!.
14
2. SISTEMA DE GESTÃO DE CONTEÚDO
2.1. O QUE É CONTEÚDO
Antes de nos aprofundarmos no conceito de Sistema de Gestão de Conteúdo, é
importante termos um conceito bem construído de conteúdo.
Segundo Batista (2007), Conteúdo é a identificação dada aos produtos e serviços de
informação, tais como: dados, textos, imagens, sons e software. Já Boiko (2005), faz
uma explanação sobre os conceitos de dado e informação, e através destes
fundamenta o conceito de conteúdo. Ele explica que dados são pequenos trechos de
“informação” computacional, como palavras, números, imagens e sons que, de
maneira isolada, não possuem muito significado relevante aos humanos, enquanto
que informação é um conjunto de dados organizados de maneira que possuam
alguma semântica. Já o conteúdo é a informação com determinado propósito, e em
uma forma utilizável por humanos. Ele afirma que informação que flui casualmente
não é conteúdo. Ela torna-se conteúdo apenas depois que alguém dá a ela uma
utilidade.
Alguns autores também incluem a funcionalidade como uma forma de conteúdo.
Boiko (2005) é um destes. Ele primeiro explica que: funcionalidade é uma série de
interações homem-computador, utilizando uma interface entre o usuário e a
máquina, a fim de realizar determinado processo; depois explica que a
implementação de funcionalidade nos sistemas está ficando cada vez mais granular,
com objetos que podem ser adicionados de diversas fontes e maneiras, fazendo
com que a funcionalidade possa ser gerenciável tal qual conteúdo, tornando a
distinção entre os dois cada vez mais difícil.
15
2.2. GESTÃO DE CONTEÚDO
Gestão de conteúdo é o processo de coletar, gerenciar e publicar conteúdo. (BOIKO,
2005)
� Coletar: criar conteúdo, ou adquirir este de uma fonte já existente.
� Gerenciar: persistência do conteúdo e dos dados relativos à administração
deste conteúdo.
� Publicar: extrair o conteúdo do repositório e disponibilizá-lo com uma
formatação específica.
Neves (2003), afirma que Gestão de Conteúdo significa controlar o conteúdo desde
a sua criação, até a sua disponibilização, arquivamento ou eliminação.
2.3. BENEFÍCIOS DA GESTÃO DE CONTEÚDO
A Gestão de Conteúdo fornece suporte às organizações no processo de captação,
organização e publicação de conteúdos, que podem ser originados de várias fontes
e destinados a diversos tipos de dispositivos de saída. (BATISTA, 2007)
Segundo Batista (2007), a Gestão de Conteúdo visa a dar respostas aos seguintes
problemas principais:
a) Gargalos que dificultam a produção de conteúdos para a web.
b) Falta de comprometimento dos usuários devido às dificuldades técnicas de
publicação e uso.
c) Falta de organização mais elaborada do conteúdo.
16
d) Riscos de diversos erros e informação de baixa qualidade.
e) Informações sobre estrutura misturadas ao conteúdo.
2.4. SISTEMA DE GESTÃO DE CONTEÚDO
Em uma abordagem de mais alto nível, um CMS é uma ferramenta ou conjunto de
ferramentas responsável pela coleta, gerenciamento e publicação de “pedaços” de
informação conhecidas como content components (componentes de conteúdo).
(BOIKO, 2005)
Alguns CMS bastante conhecidos atualmente são: Joomla!, Wordpress, Drupal,
Plone, MediaWiki, Alfresco, DotNetNuke, Blogger, osCommerce, dentre outros.
2.4.1. Principais funcionalidades de um CMS
De acordo com Fraser (2002), embora os CMS não sejam criados da mesma forma,
eles devem conter sempre as mesmas funcionalidades mínimas: manutenção e
publicação de conteúdo. Porém, a grande maioria dos CMS possui funcionalidades
que vão além das mínimas. Apesar da grande variedade, há um conjunto de
funcionalidades que são mais comuns entre os sistemas, merecendo portanto, uma
explanação sobre elas.
Serão apresentadas agora as funcionalidades mais comumente encontradas nos
CMS, segundo Fraser (2002).
Interface padrão para criação, edição e aprovação d e conteúdo
17
A padronização das interfaces torna desnecessário ter de aprender tudo do zero
toda vez que uma nova funcionalidade seja utilizada, pois o usuário já estará
acostumado com a estrutura da interface, e deverá aprender somente as diferenças
existentes nas novas interfaces em relação às já existentes.
Apesar de parecer óbvio essa funcionalidade, há alguns CMS que ainda não a
possuem. Isso se deve ao fato de esses CMS terem sido criados a partir da junção
de outras ferramentas, cada uma com sua interface padrão. Essas interfaces então
passaram a fazer parte do novo CMS.
Repositório comum
Colocar o conteúdo em apenas um lugar torna-o de fácil manutenção e pesquisa,
elem de ser uma forma mais segura de armazenamento.
Alguns CMS não proveem um repositório comum. Em vez disso eles proveem um
arquivo de controle que informa ao CMS em qual repositório o conteúdo está
guardado.
Controle de Versão, Monitoramento e Rollback
Manter informação de controle de versão do conteúdo é uma das funcionalidades
mais importantes no CMS.
Quando não há um controle de versão no CMS, normalmente o conteúdo pode ficar
desatualizado. Por exemplo, o autor A inclui um conteúdo. Então o editor B edita o
conteúdo e o aprova. Então o autor A altera a cópia original do conteúdo, que ainda
estava na sessão, e a salva novamente, sobrescrevendo o conteúdo previamente
aprovado e publicado pelo editor B. Como conseqüência disso, no final restará
apenas o conteúdo publicado pelo autor A, e as mudanças realizadas pelo editor B
serão perdidas.
Às vezes edições de conteúdo podem acrescentar erros, ou simplesmente o usuário
resolve desistir da mudança feita, com o controle de versão essa mudança pode ser
18
feita sem muito esforço, através do rollback. Rollback reverte um conteúdo para
estágios prévios deste.
Workflow (fluxo de trabalho)
Segundo Fraser (2002), um workflow (fluxo de trabalho) é um conjunto de tarefas
realizadas de maneira sequencial ou paralela, por mais de uma pessoa, com a
finalidade de alcançar um objetivo comum.
Todos os CMS possuem algum workflow. Uma característica importante em um
CMS é o quão simples e flexível é seu sistema de workflow. Muitos CMS permitem
ao usuário criar workflows personalizados, enquanto outros permitem ao usuário
realizar apenas as tarefas básicas já pré-definidas: criação, edição, aprovação e
publicação.
Geração dinâmica de páginas
Um CMS gera páginas dinamicamente através de layouts e componentes retirados
do repositório. A utilização de páginas dinâmicas permite que requisições iguais
possam gerar páginas diferentes para diferentes usuários.
Personalização
A personalização permite que o site apresente apenas o conteúdo específico para
determinado usuário, baseado nas preferências pessoais e na sua forma de
navegação. Podem haver vários níveis de personalização, desde uma simples
presença do nome do usuário em um site, até sites que não deixam aparecer
determinados conteúdos dependendo da configuração feita pelo usuário.
Gerenciamento de cache
No que concerne às funcionalidades de um CMS, cache é o processo de armazenar
páginas pré-configuradas em memória ou repositório, de maneira a facilitar a
pesquisa dessas páginas posteriormente.
Conversão de conteúdo
19
Alguns CMS possuem a funcionalidade de converter arquivos de um formato para o
formato requerido pelo repositório. Por exemplo, um CMS pode transformar
automaticamente dados de uma planilha do Microsoft Excel em uma tabela HTML.
Essa funcionalidade permite que o usuário crie seu conteúdo em sua ferramenta de
preferência, desde que o CMS consiga converter seu formato.
Integração com Sistemas de Busca
A maioria dos CMS utiliza sistemas de busca externos. A vantagem disso é que o
CMS ficará especializado somente na gestão de conteúdo, enquanto as buscas
serão realizadas por sistemas especializados em busca, ou seja, sistemas que
proveem a melhor solução para tal problema.
Alguns CMS possuem seu próprio sistema de buscas. Porém esses sistemas não
são tão avançados quando os providos por terceiros.
Monitoramento e análise
É o processo de analisar o comportamento do usuário no site. Isso significa que será
analisada a forma como os usuários utilizam determinada página, quais são as
páginas iniciais e finais que predominam em cada vez que um usuário acessa o
sistema.
2.4.2. Estrutura de um CMS
A Figura 1 ilustra a estrutura básica de um CMS.
Boiko (2005) divide a estrutura dos CMS em três subsiste
Sistema de Gestão e Sistema de Publicação
possibilitar a gestão do conteúdo.
logicamente separados, eles
adjacentes. Abaixo será apresentado cada um deles
Sistema de Coleta
O sistema de coleta é respons
conteúdo esteja pronto para
em um conjunto bem organizado de
serviços oferecidos no processo
agregação e serviços de coleta
Figura 1 _ Estrutura geral de um CMS
Fonte: Boiko (2005, p. 86).
Boiko (2005) divide a estrutura dos CMS em três subsistemas:
Sistema de Publicação , que trabalham em conjunto a fim de
possibilitar a gestão do conteúdo. Apesar de estes subsistemas estarem
logicamente separados, eles podem sobrepor sua funcionalidade à dos subsistemas
será apresentado cada um deles.
O sistema de coleta é responsável por todos os processos ocorridos antes que um
conteúdo esteja pronto para ser publicado. É ele quem torna a informa
bem organizado de content components. A
serviços oferecidos no processo de coleta, que são: autoria, aquisição, conversão,
de coleta.
20
Sistema de Coleta ,
que trabalham em conjunto a fim de
Apesar de estes subsistemas estarem
sua funcionalidade à dos subsistemas
por todos os processos ocorridos antes que um
É ele quem torna a informação simples
Figura 2 ilustra os
autoria, aquisição, conversão,
Figura
� Autoria: refere-se ao processo de criar conte
que deve ser esp
aquisição ao invés de autoria.
processos providos pelo CMS, pois ele é
dependendo somente da habilidade e capacidade do autor.
poder automatizar o processo de autoria, o CMS
para o autor. São elas:
o Ambiente de autoria, com uma aplicação completa e extensões qu
facilitam o trabalho do autor.
Figura 2 _ Estrutura do Sistema de Coleta
Fonte: Boiko (2005, p. 87).
se ao processo de criar conteúdo do zero. Um autor é alguém
que deve ser especificado para esta, caso contrário
aquisição ao invés de autoria. O processo de autoria é diferente dos demais
rovidos pelo CMS, pois ele é essencialmente manual
dependendo somente da habilidade e capacidade do autor.
poder automatizar o processo de autoria, o CMS provê
ão elas:
Ambiente de autoria, com uma aplicação completa e extensões qu
facilitam o trabalho do autor.
21
údo do zero. Um autor é alguém
, caso contrário o processo será
O processo de autoria é diferente dos demais
essencialmente manual,
dependendo somente da habilidade e capacidade do autor. Apesar de não
algumas facilidades
Ambiente de autoria, com uma aplicação completa e extensões que
22
o Pode-se predefinir o tipo de conteúdo que o autor poderá criar.
o Provê ajuda para criação de informação padrão. Por exemplo, incluir
automaticamente o nome do autor e data de criação em determinado
conteúdo.
o Provê templates, de forma que o autor possa inserir informações
mesclando-as com elementos já existentes, como em um template do
Microsoft Word, onde já se tenha o lugar para ser inserido o título,
dentre outros.
o Provê workflow, status e controle de versão para o conteúdo que está
sendo processado.
� Aquisição: é o processo de recolher informação que não foi originalmente
criada para determinado CMS. Isto significa que na Aquisição, a informação
não é criada, mas copiada de uma fonte externa para o CMS. Esse processo
pode ser tanto manual quanto automático. A informação adquirida pode vir
das seguintes fontes:
o Syndications: são fontes projetadas para o reuso. Elas são entregues
em formato XML ou outro formato que possibilite fácil integração, e já
possuem metadados adicionados à informação. O exemplo mais
comum de syndication são os web feeds.
o Found Sources: podem ser qualquer tipo de informação preexistente,
incluindo fontes não eletrônicas, como fotografias, filmes analógicos,
dentre outros, que possam ser digitalizados. Geralmente necessitam
de certo trabalho manual para transformá-los em conteúdo, pois são
desprovidos de metadados e não são segmentados.
� Conversão: deve acontecer quando o formato ou estrutura do conteúdo que
você criou ou adquiriu é diferente do formato ou estrutura requerida pelo
sistema. O processo de conversão consiste de três passos:
23
o Stripping: remoção de informação desnecessária, tal como cabeçalhos
e rodapés de páginas e conteúdo desnecessário.
o Mapeamento de Formato: modifica o formato binário da informação
para formato suportado pelo CMS.
o Mapeamento de Estrutura: torna explícita a estrutura da informação, ou
a modifica se necessário.
� Agregação: é o processo de juntar informações de fontes diversas em uma
única estrutura. É dividido em três passos:
o Processo Edi torial: responsável pelas funções de estilo,
consistência e uso.
o Processo de segmentação: consiste na transformação do conteúdo em
em pequenos componentes (content components).
o Processo Metatorial: adéqua o novo conteúdo ao sistema. Assegura
que os metadados referentes ao conteúdo agregado estão completos e
consistentes.
� Serviços de Coleta: sua principal função é ajudar a coletar conteúdo para o
repositório. Eles ajudam tanto no processo de autoria quanto no processo de
aquisição. Para isso, possui os dois serviços principais listados abaixo:
o Criação de conteúdo diretamente no repositório (principalmente
através de formulários web).
o Inclusão, no repositório, de componentes previamente criados. Um
exemplo comum é a utilização do Microsoft Word para edição de um
texto, que posteriormente será adicionado ao repositório.
24
Sistema de gestão
O Sistema de Gestão é o subsistema responsável pelo armazenamento e
administração do conteúdo. Ele provê detalhes sobre seu conteúdo, como quais
componentes estão sendo gerenciados no momento, e em que fase do ciclo de vida
cada componente está. Além de informar quais conteúdos estão sendo utilizados ou
não utilizados. Informa também quem tem acesso a determinado conteúdo.
O Sistema de Gestão possui as seguintes capacidades:
� Repositório: É o principal componente do Sistema de Gestão. Consiste no
conjunto das bases de dados, diretórios e arquivos de configuração, que
armazenam tanto o conteúdo coletado quanto dados de configuração do
CMS. Componentes e outros recursos do CMS são inseridos no repositório
através do sistema de coleta.
� Administração: O Sistema de Administração é responsável por administrar as
opções de configuração e a estrutura do CMS. Ele atua nos três subsistemas
do CMS.
o No Sistema de Coleta: administra configurações pessoais, como
direitos de acesso, e configurações do sistema, onde são configurados
as estrutura e o workflow do CMS.
o No Sistema de Gestão: ele é responsável pela administração de
usuários, permissões, backup, dentre outras tarefas que envolvem a
base de dados. Além disso também realiza tarefas específicas para
conteúdos, tais como criação de tipos de conteúdo, revisão de
metadados e criação de workflows.
o No Sistema de Publicação: possibilita a revisão de hardware e software
para que seja assegurado que o conteúdo poderá ser apresentado.
Permite saber se determinado conteúdo foi realmente publicado.
25
� Workflow: é responsável pela coordenação, agendamento (scheduling) e
tarefas pessoais.
� Conexões: o Sistema de Gestão pode necessitar estar conectado a fontes de
dados e infraestruturas externas, tais como Local Area Network (LAN), Wide
Area Network (WAN), base de dados de usuários em uma organização
(necessário para que os usuários e suas permissões sejam importados para o
CMS sem que haja necessidade de incluí-los manualmente), conexão com
sistema Enterprise Resource Planning (ERP) da organização, dentre outros.
Sistema de Publicação
O Sistema de Publicação é o subsistema responsável por obter o conteúdo
previamente salvo no repositório, a fim de publicá-lo, ou seja, apresentá-lo de
alguma forma ao usuário. Um Sistema de Publicação inclui:
� Templates: programas que constroem a estrutura de uma publicação, a forma
como o conteúdo deve ser apresentado.
� Serviços de Publicação: são serviços que contêm a lógica de negócio da
publicação. Ajudam na criação da publicação, escolhendo quais templates
devem ser utilizados e os executando. Podem também se utilizar de
conexões com serviços externos ao CMS, para obter dados que devam ser
utilizados em determinada publicação.
� Conexões: o Sistema de Publicação pode precisar manter conexões com
serviços externos ao CMS, para ter acesso a dados da organização que não
estejam persistidos no repositório do CMS. Neste caso o conteúdo é mantido
por sistemas externos e a função do CMS é somente a de publicação.
26
2.4.3. Tipos de CMS
Williams (2010) explica que há vários tipos de conteúdo digital, e que
consequentemente há também diversas categorias de ferramentas de Gestão de
Conteúdo, que podem ser classificadas de acordo com o tipo de conteúdo que
gerenciam. Ele divide essas ferramentas em: Sistema de Gestão de Ativos Digitais,
em inglês, Digital Asset Management System (DAM); Sistema de Gestão de
Documentos, em inglês, Document Management System (DMS); Gestão de
Registros Eletrônicos, em ingês, Electronic Records Management (ERM); Sistema
de Gestão de Conteúdo Web, em inglês, Web Content Management System
(WCMS); e Sistema de Gestão de Conteúdo Empresarial, em inglês, Enterprise
Content Management System (ECMS). Detalhar-se-á cada um desses tipos a seguir,
conforme descrição de Williams (2010).
Sistema de Gestão de Ativos Digitais
É similar ao DMS, porém é especializado em gestão de documentos de mídia
(vídeo, logos, fotografia, áudio etc.). Algumas das funções que ele desempenha são:
organizar, manipular, pesquisar, verificar a integridade, fazer entrega e distribuição,
proteger e fazer backup de Ativos Digitais. O DMS é utilizado principalmente pela
indústria de mídia e entretenimento. Alguns exemplos de DAM são: Fedora
Commons, FocusOPEN e Gallery.
Os DAM podem ser divididos em dois tipos básicos, segundo a forma como eles
armazenam o conteúdo:
� Catálogo de Mídia (Media Catalogue): delega ao Sistema Operacional a
função de gerenciar o ativo, ou seja, ele não controla realmente o conteúdo,
mas apenas mantém um índice de ativos, que será utilizado para a pesquisa
destes. Como o ativo está sob o controle do Sistema Operacional, o DAM não
consegue lhes oferecer nenhuma segurança.
� Repositório de Ativos (Asset Repository): diferentemente do Catálogo de
Mídia, o Repositório de Ativos é quem armazena e gerencia o conteúdo.
27
Desta forma, o ativo não pode ser visualizado de outra maneira que não
através do próprio DAM. Isso proporciona maior segurança aos ativos
gerenciados.
Sistema de Gestão de Documentos
DMS são ferramentas construídas com a finalidade de auxiliar as organizações no
gerenciamento da criação, armazenamento e obtenção de informação armazenada
na forma de documentos digitais (planilhas do Microsoft Excel, documentos do
Microsoft Word, PDFs, dentre outros). Ele utiliza um repositório centralizado para
armazenar os documentos, adicionando esquemas de classificação e protegendo-os
contra perdas.
As principais características do DMS são:
Foco no gerenciamento de documentos, cada documento armazenado é
independente (não está agregado a outro documento), capacidade de agrupar
documentos, foco no gerenciamento do ciclo de vida de um documento, acesso a
documentos pode ser restringido por pasta.
Devido ao tipo de conteúdo gerido pelo DMS, ele pode ser classificado como um
DAM, porém uma característica observada que pode distingui-los é que o DMS é
focado no ciclo de vida do documento, enquanto o DAM não o é.
Alguns exemplos de DMS são: Microsoft SharePoint, Xerox DocuShare, Google
Docs e DOCS Open.
Gestão de Registros Eletrônicos
O ERM é uma especialização do DMS com a finalidade de gerenciar registros de
uma empresa e de seus funcionários (contratos, faturas, registro de reclamações,
emails, dentre outros).
Sistema de Gestão de Conteúdo Web
28
Um WCMS é uma ferramenta utilizada tanto por pessoas com conhecimento técnico
quanto por pessoas sem conhecimento técnico para a criação de páginas web e de
websites. Para as pessoas com conhecimento técnico, o WCMS provê
principalmente criação descentralizada de conteúdo e separação entre layout e
conteúdo. Porém, os WCMS foram criados com o propósito de provê a pessoas sem
conhecimento técnico facilidade de criação e manutenção de páginas web.
Os WCMS podem ser divididos de acordo com as funcionalidades que eles proveem
e o quão estruturados podem ser os sites criados por eles.
Segundo Digital (2010), os WCMS podem ser divididos em:
� Portal: possuem muitas funcionalidades e podem gerenciar websites com
estrutura complexa. Alguns exemplos desse tipo de WCMS são Joomla! e
Drupal.
� Blog: é um tipo de WCMS em que artigos e posts são organizados
cronologicamente. São ideais para websites com estrutura simples. Alguns
softwares muito utilizados são WordPress e Movable Type.
� Wiki: permite a usuários criar e modificar facilmente o conteúdo, geralmente
utilizando uma linguagem de marcação própria, porém mais simples que
HTML. Geralmente possuem documentos de múltiplas páginas que podem
ser modificados de forma colaborativa. O software de wiki mais famoso é o
MediaWiki, que gerencia a Wikipedia.
� Fórum: software construído para manter discussões entre usuários. Um
exemplo de software de Fórum é o phpBB.
� Groupware: também chamado de software de colaboração, é um software
que permite que pessoas trabalhem de forma colaborativa. Auxiliando seus
usuários no cumprimento de tarefas comuns. Exemplos de groupware são:
agenda corporativa e chat.
29
Sistema de Gestão de Conteúdo Empresarial
Aproximadamente 80% das informações/documentos das empresas não se
encontram em bancos de dados. Normalmente essas informações estão na forma
não-estruturada: e-mails, arquivos digitais, vídeos, sons, documentos em papel ou
digitalizados, páginas web, conversas telefônicas, dentre outras. O ECMS surgiu
como um conjunto de ferramentas com o objetivo de gerir esse tipo de conteúdo e
possibilitar acesso a ele de forma rápida, online e segura. Os principais objetivos dos
ECMS são: redução de custos; organização das informações; facilidade de acesso e
compartilhamento das informações; manter a integridade destas; disponibilização do
conteúdo através da intranet e internet, facilidade no gerenciamento de conteúdo na
web e principalmente proporcionar agilidade nas tomadas de decisões. (T-
SYSTEMS, 2011)
Segundo AIIM (2011), ECMS é um conjunto de ferramentas para obter, gerenciar,
armazenar e distribuir conteúdo relacionado aos processos organizacionais. O
ECMS possibilita a gestão da informação organizacional, onde quer que ela exista
ou seja qual for sua forma.
De acordo com Williams (2010), Uma ferramenta para ser considerada um ECMS
deve possibilitar a gestão dos principais tipos de conteúdo, além de prover
escalabilidade em nível empresarial, suportando uma grande porcentagem dos
processos de uma empresa que possam ser automatizados.
Serão listados abaixo alguns dos principais serviços que um ECMS deve possuir a
fim de possibilitar uma abrangência completa dos processos de uma empresa.
� Reconhecimento de padrões: diz respeito a tecnologias que permitem que
dados inseridos por meio de digitalização de documentos sejam traduzidos
para caracteres através de Optical Character Recognition (OCR), ao invés de
ser gerada apenas uma imagem do que foi digitalizado.
� Categorização: provê uma estrutura formal para a informação, baseado nas
necessidades individuais do negócio. A categorização automatiza a
30
localização do conteúdo, para que no futuro essa informação seja recuperada
baseada em sua categorização.
� Indexação: consiste em criar metadados para documentos que foram
digitalizados, de forma que possam ser buscados posteriormente. A
indexação pode ser feita através de palavras-chave ou de full-text.
� Gestão de Documentos: ajuda a organização a gerenciar a criação, revisão,
aprovação e consumo de documentos eletrônicos.
� Gestão de Registros: os registros de valor de negócio de longo prazo
(contratos, faturas, registro de reclamações, dentre outros) são gerenciados
de acordo com seu tempo de retenção (tempo máximo que precisam ser
mantidos)
� Gestão de Email: email é a principal fonte de comunicação em uma
empresa, e por isso não devem ser apenas armazenados. Eles devem ser
classificados, armazenados e destruídos, ou seja, ter um ciclo de vida
completo, como qualquer outro tipo de documento.
� Gestão de Conteúdo Web: consiste na criação, revisão, aprovação e
publicação de conteúdo web.
� Gestão de Ativos Digitais: Similar à Gestão de Documentos, porém é
focado na gestão de documentos de mídia (vídeo, logo, fotografias, áudio,
dentre outros).
� Repositório: é onde estão armazenados os dados de todo conteúdo da
empresa gerenciado pelo ECMS.
� Armazenamento: não confundir com Repositório. Armazenamento é um
meio físico, onde o repositório reside. Exemplos são (discos ópticos, fitas
magnéticas e RAID). Proveem opções tanto para armazenamento online
quanto offline.
31
� Integração de Conteúdo: possibilita aos diferentes tipos de conteúdo a
serem tratados como se estivessem em um mesmo repositório.
� Backup: faz backup dos dados em diversos formatos e locais, a fim de
prevenir a perda de dados em caso de perda do repositório atual.
� Busca: é uma das principais funcionalidades de qualquer ECMS. Pois
permite a busca e recuperação do conteúdo previamente inserido.
� Syndication: distribuição do conteúdo para reuso e integração em outros
conteúdos.
� Localização: modificação da apresentação do conteúdo para se adequar à
cultura local de determinada empresa.
� Publicação: consiste na apresentação de um conteúdo através de
determinado meio, como impressão, email, website, portal, RRS feeds, etc.
� Segurança: restringe acesso ao conteúdo, tanto durante a criação e
gerenciamento, quanto durante a publicação.
� Colaboração: possibilita a criação e manutenção de equipes de trabalho,
mesmo em locais separados geograficamente. Além de possibilitar a tomada
de decisão e criação de conteúdo por essa equipe.
32
3. O CMS JOOMLA!
3.1. O QUE É JOOMLA!
Joomla! é um bem conceituado CMS que permite criar websites de forma fácil e
rápida. A relação bem equilibrada entre extensibilidade, quantidade de recursos e
facilidade de utilização fez com que ele se tornasse um dos WCMS mais populares
dentre os existentes. Ele além de ser uma ferramenta gratuita, é também open
source, liberado sob a licença General Public License (GPL), o que proporciona
liberdade para desenvolver extensões conforme a necessidade. Apesar de a
ferramenta primariamente instalada ser totalmente gratuita, algumas extensões
podem não o ser, desde que incluam o código fonte com elas. (JOOMLA!, 2010)
O Joomla! possui grande flexibilidade quanto ao tipo de website que ele produz,
podendo ser desde um website simples, como um blog até um complexo e bem
estruturado, como um portal.
Alguns exemplos de websites que podem ser criados e gerenciados pelo Joomla!
são: Portais e websites corporativos, intranets e extranets corporativas, revistas e
publicações online, E-commerce, Aplicações para o governo, websites para
pequenas empresas, websites para não profissionais, portais baseados em
comunidades, websites para escolas e sites pessoais.
3.2. HISTÓRICO DO JOOMLA!
O Joomla! nasceu quando o grupo de desenvolvedores do Mambo Open Source
(MOS) ficou insatisfeito com os interesses da Miro, empresa criadora do Mambo
CMS, que se tornara detentora dos direitos do MOS, podendo a qualquer momento
33
vendê-lo a outra empresa ou comercializá-lo de forma não gratuita. Como o MOS
era open source, seus desenvolvedores então resolveram dar continuidade ao
projeto, que já obtivera bastante sucesso, ficando inclusive mais famoso que seu
irmão de código fechado, Mambo CMS. Eles então criaram um grupo chamado
Open Source Matters, que foi o responsável pela criação do projeto Joomla! Em
primeiro de setembro de 2005, com o objetivo de dar continuidade à crescente
popularidade do MOS, tanto em relação aos usuários quanto em relação à
comunidade de desenvolvedores. O nome “Joomla!” tem origem africana e pode ser
traduzido como “todos juntos”, expressão que faz alusão ao fato dele ser totalmente
de código aberto, o que possibilita que ele seja desenvolvido e mantido por várias
pessoas independentemente de sua cultura ou posição geográfica.
Como o código do Joomla! fora herdado do MOS, sua versão 1.0 era idêntica a este,
e portanto as extensões do Joomla! 1.0 eram totalmente compatíveis com o MOS.
Algumas restrições que o Joomla! possuía levaram os codificadores a repensar sua
estrutura, e após dois anos de desenvolvimento, foi lançado em 2007 o Joomla! 1.5,
com uma estrutura totalmente diferente da versão 1.0. (KENNARD, 2007)
Em 10 de janeiro de 2011 foi anunciado o Joomla! 1.6. Esta versão não trouxe
tantas diferenças em sua estrutura em relação à estrutura da versão 1.5; quanto
trouxera a versão 1.5 em relação à 1.0, que era apenas o MOS com o nome
modificado. A versão 1.6 trouxe, no entanto, uma gama muito grande de melhorias
tanto para desenvolvedores de extensões, quanto para administradores e usuários.
(JOOMLA!, 2011)
Algumas das melhorias mais importantes adicionadas na versão 1.6 são: melhoria
da Access Control List (ACL), aumentando a flexibilidade e a personalização no
gerenciamento de usuários, grupos e controle de acesso; novas funções de Search
Engine Optimization (SEO); melhoria no gerenciador de mídias e melhorias no
gerenciador de instalação, com a inclusão de arquivos de atualização de extensões,
que facilitam a atualização de extensões de terceiros por parte dos administradores.
(JOOMLA!, 2011)
34
3.3. CONHECENDO O JOOMLA!
3.3.1. Requisitos de instalação
O Jommla! foi totalmente desenvolvido na linguagem de programação PHP, por isso
é necessário uma servidor web com PHP instalado para executá-lo.
Segundo Joomla! (2011), a configuração mínima para execução da versão 1.6 do
Joomla! é:
� Apache (servidor web) versão 2.x
� PHP (interpretador de código) versão 5.2
� MySQL (banco de dados) versão 5.0.4
Também pode ser utilizado o servidor da Microsoft
� Microsoft IIS: versão 7
� MySQL: versão 5.1
Observações:
� A partir da versão 5.5.15 o Joomla! é compatível com o PHP 5.3, porém ele
possui uma biblioteca, OpenID, que não é compatível com esta versão.
� Na versão 6 do Joomla!, a biblioteca OpenID foi removida, portando, esta
versão possui total compatibilidade com PHP 5.3.
� Joomla! ainda não é compatível com a versão 6.x do MySQL.
3.3.2. Arquitetura
A Figura 3 apresenta a arquitetura do Joomla!
Segundo Joomla! (2011
estrutura de três camadas: camada de Aplicação, camada de Extensão e camada de
Framework.
Arquitetura
apresenta a arquitetura do Joomla!
Figura 3 _ Arquitetura do Joomla!
Fonte: Joomla! (2011).
1), O Joomla! 1.6 pode ser descrito como
três camadas: camada de Aplicação, camada de Extensão e camada de
35
pode ser descrito como possuindo uma
três camadas: camada de Aplicação, camada de Extensão e camada de
36
Na camada de Extensão (ver item 3.3.3) estão os pacotes que estendem o
comportamento padrão do Joomla!. Algumas extensões já vêm por padrão na
instalação, enquanto outras podem ser adicionadas posteriormente.
A camada de Aplicação consiste de aplicações que possuem um comportamento em
comum. Elas possuem uma função essencial para o funcionamento do Joomla!. A
versão 1.6 possui três dessas aplicações: instalação, administração (responsável
pelo backend), e site (responsável pelo frontend). Na versão 1.5 havia também a
aplicação XML-RPC, que suportava administração remota do website, porém na
versão 1.6 ela tornou-se desnecessária.
A camada de Framework consiste em:
� Framework provido pelo Joomla!: conjunto de classes que proveem
funcionalidades básicas e facilitam o trabalho de desenvolvedores.
� Libraries: bibliotecas de terceiros que são requeridas pelo framework ou são
instaladas por extensões.
� Plugins: também é um tipo de extensão. Provê rotinas responsáveis por
responder a eventos ocorridos na aplicação. Possibilitando adicionar
funcionalidades que dependam da ocorrência de determinados eventos.
3.3.3. Extensões
Uma das principais razões para a popularidade do Joomla! é a enorme variedade de
Extensões disponíveis, o que possibilita uma gama muito grande de funcionalidades,
além de possibilitar ao administrador do website escolher qual extensão, dentre as
várias disponíveis, se adéqua melhor às suas necessidades. Isso torna o Joomla! o
preferido tanto para usuários quanto para desenvolvedores, em se tratando de CMS
para portais. (RAHMEL, 2007)
37
Uma Extensão é um termo genérico que consiste em um pacote que pode ser
adicionado ao seu website Joomla!, incluindo novas funcionalidades ou
simplesmente modificando funcionalidades já existentes na instalação padrão deste.
Algumas Extensões, no entanto, já vêm inclusas na sua instalação padrão. Diante
disso, pode-se dizer que uma Extensão, ao contrário do que se pode pensar, não é
somente um add-on (que pode ser adicionado ao website), mas um pacote que
estende o core do Joomla!, podendo portanto já vir como padrão na instalação ou
ser adicionado posteriormente. Consultando a Figura 3, vê-se que as Extensões,
exceto Plugins, estão em uma camada, Extension Layer, que se sobrepõe à
Application Layer. Isso significa que o termo “Extensão”, no Joomla!, designa
estrutura em vez de estado (o fato de ser previamente ou posteriormente instalado).
No Joomla! 1.6 as extensões são divididas em sete tipos: Componente, Linguagem,
Módulo, Plugin (na versão 1.0.x era chamado de Mambot), Template, Library e
Package. Algumas extensões são muito simples, enquanto outras são mais
complexas e exigem maior tempo e cuidado no desenvolvimento. Apresentar-se-ão
a seguir cada um desses tipos.
Linguagens
Linguagens (Languages) são o tipo de extensão mais básico do Joomla!. São tão
simples que podem ser implementadas por uma pessoa sem conhecimentos de
programação, devendo apenas possuir o conhecimento necessário para a tradução.
Há inclusive uma extensão (Translation manager extension) que ajuda na criação
dos arquivos necessários. As linguagens podem ser empacotadas de duas
maneiras, como pacotes do core (pacotes que já vêm inclusos na instalação do
Joomla!) ou pacotes de extensão. As Linguagens são uma ferramenta essencial
para a internacionalização do Joomla!. Elas possibilitam o número oficial atual de 64
traduções, que fazem do Joomla! O CMS com o maior número de traduções
atualmente. (JOOMLA!, 2011)
O Joomla! utiliza a codificação de caracteres UTF-8, isso permite que tanto seu
conteúdo quanto seus dados sejam traduzidos para qualquer língua, pois permite a
utilização de qualquer conjunto de caracteres.
38
Template
Um Template é basicamente o design do website, é um tipo de extensão que
modifica a maneira como as páginas e outras extensões do website são
apresentadas. Há dois tipos de Templates: de front-end, que modifica a interface do
usuário e de back-end, que modifica a interface de administrador do website.
Templates tornam possível modificar todo o layout da aplicação de forma rápida,
fácil e uniforme, sem ter problemas de ficarem estilos diferentes para lugares
diferentes do website.
Plugin
Plugins são extensões que se integram com a camada mais baixa do Joomla!, a
Framework Layer. Eles operam entre o usuário e a aplicação, e executam alguma
ação ao interceptarem eventos ocorridos. Isso significa que tanto o Joomla! core
quanto outras extensões podem lançar algum evento, que será “ouvido” por um ou
mais plugins, que dependendo do evento decidirá se deverá ou não executar uma
ação. No Joomla! 1.0 havia um equivalente ao Plugin,, eram os Mambots, que
funcionam da mesma forma que os Plugins. A diferença entre eles é somente
estrutural, sendo a estrutura do Joomla! 1.5 e 1.6 mais limpa que a 1.0.
A Figura 4 apresenta o funcionamento de um Plugin.
O Plugin pode interceptar os dados de
o usuário. No sentido oposto, ele intercepta os dados do usuário e pode transform
los antes de enviá-los para o repositório.
Módulo
Módulo é uma extensão leve e utilizada na formação da página. Pode ser utilizada
em vários componentes, e também pode haver muitos módulos em um único
componente. Os módulos são associados a componentes, dessa forma serão
renderizados apenas para os componentes a que forem associados. Muitos pacotes
de extensão utilizam mais de uma extensã
(poll), que utiliza um Módulo para apresentar a interface com o usuário, e um
Componente para permitir configuração e administração.
Figura 4 _ Funcionamento de um Plugin
Fonte: Rahmel (2007, p. 267).
pode interceptar os dados de output e modificá-los antes de
No sentido oposto, ele intercepta os dados do usuário e pode transform
los para o repositório.
Módulo é uma extensão leve e utilizada na formação da página. Pode ser utilizada
ários componentes, e também pode haver muitos módulos em um único
componente. Os módulos são associados a componentes, dessa forma serão
renderizados apenas para os componentes a que forem associados. Muitos pacotes
de extensão utilizam mais de uma extensão, um exemplo é o pacote de votação
), que utiliza um Módulo para apresentar a interface com o usuário, e um
Componente para permitir configuração e administração.
39
los antes de enviá-los para
No sentido oposto, ele intercepta os dados do usuário e pode transformá-
Módulo é uma extensão leve e utilizada na formação da página. Pode ser utilizada
ários componentes, e também pode haver muitos módulos em um único
componente. Os módulos são associados a componentes, dessa forma serão
renderizados apenas para os componentes a que forem associados. Muitos pacotes
o, um exemplo é o pacote de votação
), que utiliza um Módulo para apresentar a interface com o usuário, e um
40
Componente
Componentes podem algumas vezes ser confundidos com Módulos, porém não é
difícil distingui-los. Componentes possuem mais capacidade de interação que os
Módulos e são eles quem renderizam o corpo da página, enquanto Módulos são
“componentes” que existem dentro da página, ou seja, Componentes são mais
complexos e contém Módulos. Por serem mais complexos, consequentemente são
de mais difícil implementação.
Os componentes geralmente estão associados a um item de menu. Desta forma
quando um usuário clica em um menu no Joomla! ele será direcionado para um
componente, que na maioria das vezes exibirá uma página inicial para interação
com o usuário.
Bibliotecas (Library)
São pacotes de código que provêem um grupo de funções relacionadas. Elas já
existiam na versão anterior, mas na atual é possível instalar, atualizar e desinstalá-
los.
Pacote (Package)
Package é uma extensão que nada mais é do que a junção de mais de um tipo de
extensão no mesmo arquivo de instalação.
3.3.4. Frontend e Backend
Um website produzido com Joomla! é dividido em duas aplicações básicas:
� Frontend: parte principal do website. É utilizada por usuários sem direitos
administrativos. No frontend é possível gerenciar conteúdo, como incluir e
modificar artigos, dependendo do nível de acesso do usuário; mas não é
41
permitido realizar tarefas administrativas como gerenciar extensões e
usuários.
� Backend: parte administrativa do site, que é acessada por um endereço
especial. Permite o gerenciamento de usuários, extensões e de opções do
site. No backend é onde a estrutura do website é definida, enquanto no
frontend será permitido somente criar e manter conteúdo que preencha esta
estrutura. (SCARATE, 2007)
42
4. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA!
Este capítulo tem como objetivo apresentar um passo a passo para se desenvolver
um componente internacionalizável (ver seção 4.3) para o Joomla! utilizando o
modelo arquitetural Model View Controller (MVC).
Apresentar-se-ão técnicas e boas práticas que devem ser seguidas na construção
de um componente para o Joomla!. Além disso será explanado sobre a estrutura
que ele provê para facilitar esse desenvolvimento. Todos os detalhes de
implementação serão apresentados a partir do código do componente Questões,
que foi desenvolvido como forma de auxiliar neste trabalho.
4.1. O COMPONENTE “QUESTÕES”
O Questões foi desenvolvido como parte deste trabalho, como forma de
aprofundamento e complemento do conteúdo teórico adquirido através das fontes
textuais. Além disso, ele será utilizado como exemplo na apresentação da teoria do
desenvolvimento de componentes para o Joomla!.
O Questões é um componente que tem como funcionalidades o cadastro de
questões de múltipla escolha, cadastro de simulados, e resolução de simulados. Os
diagramas abaixo apresentam os principais fluxos do Componente, bem como o
detalhamento desses fluxos.
A Figura 5 apresenta os casos de uso do Questões, que são as funcionalidades que
o Componente provê: Cadastro de Questão (que deve ser precedida do cadastro de
uma prova), Cadastro de Simulado e Resolução de Simulados.
43
Figura 5 _ Diagrama de Casos de Uso do componente Q uestões
Fonte: Bruno Queiroz.
A Figura 6 detalha a funcionalidade mais complexa do componente, o cadastro de
questões.
44
Figura 6 _ Diagrama de Atividades (Cadastrar Questã o)
Fonte: Bruno Queiroz.
A Figura 1Figura 7 detalha a funcionalidade de cadastro de simulados.
45
Figura 7 _ Diagrama de Atividades (Cadastrar Simula do)
Fonte: Bruno Queiroz.
A Figura 8 detalha a funcionalidade de resolução de simulados.
46
Figura 8 _ Diagrama de Atividades (Resolver Simulad o)
Fonte: Bruno Queiroz.
Apresentar-se-ão abaixo as telas relativas às funcionalidades do Questões.
A Figura 9 apresenta a tela de listagem de
várias questões. Pode-
existente. Além disso é possível listar provas
Figura 9 _ Tela do componente Questões (Listagem de
apresenta a tela de listagem de provas, sendo que cada prova contém
-se cadastrar uma nova prova, editar
Além disso é possível listar provas de acordo com um filtro.
_ Tela do componente Questões (Listagem de Provas
Fonte: Bruno Queiroz.
47
provas, sendo que cada prova contém
ou excluir uma já
de acordo com um filtro.
Provas )
48
A Figura 10 representa a funcionalidade de cadastro de questões. Esta é a
funcionalidade mais complexa, onde se deve primeiro cadastrar uma prova, e
posteriormente incluir as questões nesta. Quando são cadastradas novas questões,
estas aparecem em uma listagem, sendo possível editá-las ou excluí-las. Neste
componente, concebeu-se uma forma bastante simples de cadastro de questões,
onde em um único formulário é possível cadastrar vários tipos de questões, como
questão de múltipla escolha, questão de múltipla escolha com assertivas ou
somente texto (para textos que são utilizados por várias questões). Além disso, não
há limites para a quantidade de itens ou de assertivas, podendo-se adicioná-los ou
excluí-los conforme a necessidade. O componente também possibilita que sejam
inseridos estilos para as frases incluídas, através de um editor de texto. Dessa forma
é possível inserir negrito, itálico, modificar tamanho e tipo de letra, dentre outros.
Figura 10 _ Tela do componente Questões (
A Figura 11 apresenta a funcionalidade de listagem de simulados, onde é possível
listar simulados conforme um filtro inserido, criar um novo simulado, excluir um
simulado existente ou ir para a tela de r
Tela do componente Questões ( Cadastro de Questões)
Fonte: Bruno Queiroz.
apresenta a funcionalidade de listagem de simulados, onde é possível
listar simulados conforme um filtro inserido, criar um novo simulado, excluir um
simulado existente ou ir para a tela de resolução de simulados.
49
Cadastro de Questões)
apresenta a funcionalidade de listagem de simulados, onde é possível
listar simulados conforme um filtro inserido, criar um novo simulado, excluir um
Figura 11 _ Tela do componente
A Figura 12 representa a funcionalidade de cadastro de simulado.
possível cadastrar um simulado, que conterá as questões que se adequarem aos
requisitos determinados
Tela do componente Questões (Listagem de Simulados
Fonte: Bruno Queiroz.
representa a funcionalidade de cadastro de simulado.
possível cadastrar um simulado, que conterá as questões que se adequarem aos
no formulário.
50
Questões (Listagem de Simulados )
representa a funcionalidade de cadastro de simulado. Nesta tela é
possível cadastrar um simulado, que conterá as questões que se adequarem aos
Figura 12 _ Tela do componente Questões (
A Figura 13 representa a funcionalidade de Resolução de simulados.
possível resolver as questões dos simulados cadastrados
questão é resolvida o sistema automaticamente
corretamente ou não. Ao fechar
abri-la novamente as questões que já foram resolvidas continuarão como resolvidas
e com suas respectivas respostas e indicação de erro ou a
Tela do componente Questões ( Cadastro de Simulado)
Fonte: Bruno Queiroz.
representa a funcionalidade de Resolução de simulados.
possível resolver as questões dos simulados cadastrados. No momento em que a
questão é resolvida o sistema automaticamente apresenta se a questão foi resolvida
Ao fechar-se a tela, as informações continuam salvas, e ao
la novamente as questões que já foram resolvidas continuarão como resolvidas
e com suas respectivas respostas e indicação de erro ou acerto.
51
Cadastro de Simulado)
representa a funcionalidade de Resolução de simulados. Nesta tela é
No momento em que a
apresenta se a questão foi resolvida
se a tela, as informações continuam salvas, e ao
la novamente as questões que já foram resolvidas continuarão como resolvidas
Figura 13 _ Tela do componente Questões (
4.2. MODEL-VIEW
O Model View Controller
estrutura da aplicação em três
Tela do componente Questões ( Resolução de Simulado)
Fonte: Bruno Queiroz.
VIEW-CONTROLLER
Controller (MVC) é um padrão de arquitetura de software que
estrutura da aplicação em três camadas, modelo (model), visão (
52
de Simulado)
de arquitetura de software que divide a
), visão (view) e controle
53
(controller). Cada uma dessas camadas possui responsabilidades distintas. Elas são
separadas de forma que a parte do sistema responsável pelo domínio e acesso a
banco de dados fique separada da parte do sistema responsável pela visualização.
Para possibilitar isso há também uma camada que controla a interação entre essas
duas camadas. O objetivo dessa separação é manter o código mais organizado,
facilitando a manutenção. Dessa forma é possível fazer modificações na camada de
visão, inclusive trocar totalmente o tipo de visualização, sem necessitar fazer
mudanças no Modelo. O contrário também acontece. Quando for preciso fazer
mudança na forma de pesquisar dados ou no acesso aos dados, por exemplo, se
mudar a fonte de dados, será preciso mudar apenas o Modelo, sendo que a camada
de Visão não precisará ser modificada.
Segundo Fowler (2011), a ideia principal do MVC é a separação da apresentação,
que consiste na separação dos objetos de domínio (a parte do software que modela
a percepção que se tem do mundo real) dos elementos que compõem a
apresentação do software. Ele explica também que os objetos de domínio devem
funcionar independentemente dos objetos da apresentação, sem ter conhecimento
destes, além disso devem suportar múltiplas camadas de visão.
A Figura 14 apresenta a estrutura do MVC
Tanto a Visão quanto o
acesso à Visão. A Visão e o Modelo podem lançar eventos que são interceptados
pelo Controle. Há no entanto variações dessa arquitetura, com pequenas
modificações.
Modelo
O Modelo é a camada que encapsula
aplicação. Ele provê rotinas para manipular os dado
estes, independentemente da forma como estão armazenados
Visão
Figura 14 _ Estrutura do MVC
Fonte: Bruno Queiroz.
isão quanto o Controle possuem acesso ao Modelo, e o
isão e o Modelo podem lançar eventos que são interceptados
ontrole. Há no entanto variações dessa arquitetura, com pequenas
o é a camada que encapsula o acesso aos dados e a lógica de negócio
aplicação. Ele provê rotinas para manipular os dados e é responsável pelo acesso a
endentemente da forma como estão armazenados. (ORACLE, 2011)
54
odelo, e o Controle possui
isão e o Modelo podem lançar eventos que são interceptados
ontrole. Há no entanto variações dessa arquitetura, com pequenas
e a lógica de negócio da
s e é responsável pelo acesso a
. (ORACLE, 2011)
55
Visão é a camada responsável por apresentar os dados do modelo de maneira que
possibilite interação com humanos, e servir de porta de entrada para dados inseridos
por humanos, como formulários, por exemplo. Pode haver diferentes Visões para um
mesmo Modelo e Controle. As Visões devem ser diferentes conforme a necessidade
do usuário de visualizar dados em diferentes formas. Por exemplo, uma aplicação
pode necessitar de uma Visão para a web e uma Visão para desktop. Nesse caso
deverá ter duas Visões para o software, e a camada de Controle será encarregada
de decidir qual das duas utilizar. (ORACLE, 2011)
Controle
O Controle, ou Controlador, é responsável por responder às ações do usuário. Ele
verifica qual método deve ser utilizado e o aciona no Modelo. Depois passa o
Modelo para a Visão para que ela apresente os dados, ou passa apenas os dados
para a Visão, isso dependendo da implementação do MVC. (ORACLE, 2011)
4.3. INTERNACIONALIZAÇÃO (I18N)
Segundo W3C (2011), a internacionalização (ou I18N, que é um acrônimo para o
termo “internationalization” onde são utilizadas sua primeira e última letra mais o
número 18, que é a quantidade de letras intermediárias) é a criação e o
desenvolvimento de um produto, aplicação ou conteúdo de um documento que
permita a localização (adaptação a determinada cultura ou idioma) fácil para
públicos-alvo que variam em cultura, região ou idioma. Não se deve confundir
localização com internacionalização. Enquanto a localização é o ato de modificar um
conteúdo para que ele se torne apresentável a pessoas de determinada cultura e
idioma, a internacionalização é apenas modificar o software para que ele seja de
fácil localização.
O Joomla! é totalmente internacionalizado e ainda provê suporte à fácil
internacionalização de componentes de terceiros.
56
4.4. O JOOMLA! FRAMEWORK
Um framework é uma estrutura reutilizável dentro de uma aplicação. No Joomla! o
framework consiste em uma camada completa, e é representado por sua Application
Programing Interface (API). Sua API consiste em um conjunto de classes que estão
separadas em diversos pacotes. Os pacotes existentes são os seguintes:
Access, application, base, cache, client, database, document, environment, error,
event, filesystem, filter, form, HTML, installer, language, mail, plugin, registry,
session, updater, user e utilities.
Há algumas classes que não se pode deixar de mencionar aqui. Elas são classes
notáveis, apesar de todas serem importantes. São elas:
JObject
JObject é a classe básica para quase todas as outras classes do Joomla!
Framework. Ela é abstrata, portanto provê somente interface em vez de
funcionalidade.
JApplication
É a superclasse das classes da camada de Aplicação. Ou seja, toda aplicação no
Joomla! deve estender essa classe. Atualmente há três aplicações no Joomla!:
Instalação (responsável pela instalação do Joomla!, e deve ser removida após sua
instalação por motivos de segurança), Administração (backend) e Site (frontend).
JModel, JView e JController
São classes abstratas que proveem as funcionalidades básicas para as classes de
cada uma das camadas do padrão MVC. É extremamente recomendado que os
componentes sejam desenvolvidos utilizando-se essa arquitetura, e portanto,
estendendo essas três classes.
57
4.5. DESENVOLVENDO O COMPONENTE
O código do Joomla! foi projetado para facilitar o reuso e a extensibilidade, levando o
desenvolvedor a utilizar uma arquitetura bem projetada de maneira automática. Seu
framework tira do desenvolvedor várias responsabilidades que não poderiam ser
deixadas de fora do componente, mas que deixariam o desenvolvimento mais
complicado e demorado, caso o desenvolvedor tivesse que se preocupar com elas.
Algumas dessas responsabilidades são, dentre outras, ACL (questões de segurança
e controle de acesso), internacionalização; o template da aplicação, com seus
menus, rodapé, cabeçalho, dentre outros; e SEO. (JOOMLA!, 2011)
Uma característica muito importante do framework do Joomla! é que ele utiliza-se do
paradigma de desenvolvimento chamado Convention over Configuration
(Programação por Convenção, ou CoC), igualmente a outros frameworks web
famosos, como o Ruby on Rails e o Grails. Segundo Neto (2011), o CoC é um
paradigma que visa a diminuir a quantidade de decisões que o desenvolvedor
precisa tomar, tendo como padrão algo que é comumente utilizado, uma convenção.
Isto torna desnecessária ou pouco necessária a utilização de arquivos de
configuração. No Joomla!, os nomes e localização dos arquivos, bem como nomes
das classes, são utilizados ao invés de configuração explicita.
O principal ponto que deve ser notado antes de se começar o desenvolvimento de
um componente para Joomla! é a convenção de nomenclatura. Como já foi dito
neste capítulo, o Joomla! utiliza CoC como forma de garantir um desenvolvimento
mais rápido e garantir padronização entre diversos componentes desenvolvidos por
diferentes pessoas. Serão apresentadas agora as convenções de nomenclatura e de
estrutura de arquivos utilizada pelo Joomla!
4.5.1. Convenções de codificação
58
Convenções de nomeação e estrutura de pastas
Antes de tudo é importante salientar que o framework do Joomla! é bastante
flexível, portanto não é obrigatório seguir as convenções adotadas por ele.
Porém seguir estes padrões é altamente recomendado, pois melhora a
legibilidade e a manutenibilidade do código. Será apresentada abaixo a estrutura
do componente Questões, seguida por um detalhamento das convenções
seguidas por este componente.
Figura 15 _
� A primeira convenção a ser seguida é o nome da pasta
componente. Esta p
components/com_{nomedocomponente}
contém todos os componentes do
componente Questões, deve ficar
_ Estrutura de diretórios do componente Questões
Fonte: Bruno Queiroz.
A primeira convenção a ser seguida é o nome da pasta
componente. Esta pasta deve ter a seguinte nomenclatura:
components/com_{nomedocomponente} , onde components
contém todos os componentes do font-end do Joomla!.
componente Questões, deve ficar components/com_questoes
59
Estrutura de diretórios do componente Questões
A primeira convenção a ser seguida é o nome da pasta que contém o
sta deve ter a seguinte nomenclatura:
components é a pasta que
. Então no caso do
components/com_questoes .
60
� Todo componente deve ter um ponto de entrada (entry point). Como o nome
diz, esse arquivo deve ser o ponto de entrada de toda requisição ao
componente. É nele onde serão tomadas algumas decisões preliminares,
como por exemplo, qual o controlador que será utilizado. O nome do entry
point deve seguir o seguinte padrão:
{componente}/{nomedocomponente}.php, que deverá ficar, no caso do
Questões, com_questoes/questoes.php.
� index.html: não faz parte de nenhuma convenção, mas é aconselhável
colocar esse arquivo em todos os diretórios do componente, a fim de prevenir
que usuários maliciosos tentem fazer uma listagem dos arquivos e pastas
contidos no diretório do Joomla!. Essa listagem é realizada automaticamente
pelo servidor web Apache, quando da falta de um arquivo index.html.
� controller.php: é o controlador padrão do componente. Deve conter uma
classe com o seguinte padrão de nomeação:
{NomeDoComponente}Controller, que no nosso caso ficará
QuestoesController. Esta classe deve estender a classe base
JController.
� A pasta tables contém classes que representam uma tabela de banco de
dados do componente. Cada arquivo que represente uma tabela deve ter seu
nome seguindo nomenclatura: {nomedatabela}.php, e o nome da classe
deve ser JTable{NomeDaTabela}. Além disso, deve estender de JTable .
� A pasta models contém as classes que representam o modelo do
componente. Essas classes são responsáveis por acessar o banco de dados
tanto para pesquisar dados quanto para realizar ações, como salvar, editar,
listar, etc. Os arquivos do modelo devem representar uma view, e seu nome
deve ser igual ao da view que representam. Sua classe deve ter a seguinte
nomenclatura: {NomeDoComponente}Model{NomeDoModel}, e devem
estender a classe JModel. No momento da requisição, o framework relaciona
ao controlador um modelo com o mesmo nome da visão atual, se o
desenvolvedor tentar criar outro model nesse momento, não será possível a
61
menos que especifique via código qual o modelo que deverá ser criado para
tal visão.
� A pasta controllers contém controladores adicionais para o componente,
caso o desenvolvedor queira ter mais controladores além do padrão. Eles
devem conter o padrão de nomeação: {nomedocontrole}.php e sua classe
deve conter o padrão
{NomeDoComponente}Controller{NomeDoControlador} e deve estender
JController. O fluxo será direcionado para o controlador cujo nome seja
igual ao valor da variável controller presente na requisição. Caso a variável
controller não exista ou não possua valor, o fluxo será direcionado para o
controlador padrão. Durante o desenvolvimento do Questões, observou-se
que criar um controlador para cada página é o ideal, pois melhora a
legibilidade do código, separando-o em várias partes; e possibilita a utilização
das ações padrão do Joomla! (save, update, delete, etc) para cada página do
componente.
� A pasta views deve conter as diferentes visões do componente. Onde cada
visão deve representar uma página, e deve conter uma pasta com seu nome.
o Dentro da pasta de uma visão, há o arquivo view.html.php, que é o
ponto de entrada para esta visão. Este arquivo deve declarar a classe
{NomeDoComponente}View{NomeDaVisao}, que no caso do
Questões, e para a visão que foi escolhida para exemplo, que é a visão
“simulado”, ficará QuestoesViewSimulado. Esta classe deve estender
a classe JView. O “.html” contido no nome do arquivo significa o
formato de visualização que deve ser apresentado. Este formato é
escolhido através da variável format. Por exemplo, caso seja preciso
apresentar a visão no formato pdf, deve-se passar na requisição o
parâmetro format=pdf , que será apresentada a visão cujo arquivo
principal chama-se view.pdf.php.
o O arquivo de visão é responsável por obter, através do modelo, os
dados que serão apresentados na tela, porém quem apresenta
62
realmente os dados é o template. O template deve ficar na pasta
/nomedavisao/tmpl, e normalmente seu nome será default.php .
Caso queira ter o template com nome diferente, deve-se setar a
variável layout com o nome do arquivo de template desejado.
Variáveis de requisição
O Joomla! também possui variáveis padrão que devem ser enviadas na requisição
como forma de acessar um componente e escolher a página ou controlador a ser
acessado, ação a ser realizada, e outras opções. A lista abaixo apresenta todas as
variáveis de requisição padrão do Joomla! que foram utilizadas durante o
desenvolvimento do componente ou que tomou-se conhecimento durante este
trabalho.
Option Nome do componente que deve ser executado.
View Nome da visão que deve ser executada.
Controller Nome do controlador que deverá executar determinada ação.
Task Nome da ação que será executada no controlador selecionado.
Layout Especifica qual o arquivo de template que será utilizado pela visão.
Format Especifica qual o formato da página que será carregada. Ex.:
format=pdf direciona para o arquivo view.pdf.php.
Tmpl Indica qual o template em que o componente deve ser adicionado.
Caso necessite que seu componente não utilize o template padrão
do Joomla!, de modo a não caregar menu, rodapé e o topo da
página, deve-se utilizar o parâmetro tmpl=component na requisição.
Isso geralmente é necessário quando se quer abrir uma tela modal
sem que esta apresente o template padrão.
4.5.2. Codificação
Agora que já se tem a teoria para a criação da estrutura do componente, serão
apresentadas técnicas para a codificação de um componente para
por arquivo, porém incluindo apenas
o completo entendimento
Arquivo questões.php
Figura 16 _
Codificação
Agora que já se tem a teoria para a criação da estrutura do componente, serão
apresentadas técnicas para a codificação de um componente para
incluindo apenas os arquivos e partes de código
ntendimento do processo de desenvolvimento.
_ Arquivo questoes.php (entry point do componente)
Fonte: Bruno Queiroz.
63
Agora que já se tem a teoria para a criação da estrutura do componente, serão
apresentadas técnicas para a codificação de um componente para Joomla!, divididas
os arquivos e partes de código relevantes para
Arquivo questoes.php (entry point do componente)
64
O arquivo com_questoes/questões.php é o ponto de entrada do componente, isso
significa que toda requisição ao Questões deve passar primeiro por este arquivo.
A linha 3 verifica se a constante _JEXEC teve seu valor inicializado. Ela é
inicializada pelo Joomla! no momento da requisição. Se a função
defined(‘_JEXEC’) retornar um valor falso, significa que alguém tentou acessar o
componente sem ser através do Joomla!, então a execução é encerrada. É
aconselhável ter esta instrução em todos os arquivos do componente. A instrução da
linha 5 faz um include do arquivo controlador padrão. A função
JPATH_COMPONENT, ainda na linha 5, é uma constante provida pelo Joomla! que
possui o caminho para o componente, desde que este utilize as convenções de
estrutura e nomeação do Joomla!. No caso do Questoes, o valor de
JPATH_COMPONENT é
diretorioDeInstalacaoDoJoomla/components/com_questo es. A constante DS
também é inicializada pelo Joomla! e contém o valor da barra separadora de
diretórios, que pode ser “/” ou “\”, dependendo do Sistema Operacional utilizado.
Essa constante livra o desenvolvedor de ter que fazer a verificação de qual o
Sistema Operacional em que o Joomla! está instalado. É aconselhável sempre
utilizar a constante DS ao invés do separador em hard code. Também é
aconselhável nunca utilizar uma string com a url para o diretório do Joomla!, ao
invés disso deve-se sempre utilizar a constante JPATH_COMPONENT.
A instrução da linha 8 verifica se há a variável controller na requisição. Se houver,
significa que será utilizado outro controlador ao invés do controlador padrão. A
variável controller é obtida através da função JRequest::getWord(‘controller’) .
Essa função obtém uma variável da requisição, que pode estar contida tanto em
$_POST quanto em $_GET, porém é uma boa prática de segurança sempre utilizar
JRequest::getWord ao invés dos arrays $_POST e $_GET providos pelo PHP,
pois essa função filtra o valor, aceitando somente caracteres de “A” a “Z”, de forma
que impossibilite a injeção de código ou injeção de SQL por parte de usuários mal
intencionados. Caso a variável controller possua algum valor, o controlador
inicializado será do arquivo components/controllers/nomeDoControlador , ao
invés do controlador padrão.
A instrução da linha 21
representa a tarefa (função) que será executada pelo controlador.
contenha valor, será executada
JController::display().
Arquivo simulado.php
Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado)
A instrução da linha 21 obtém o valor da variável task da requisição
representa a tarefa (função) que será executada pelo controlador.
á executada a task padrão do controlador, que é
JController::display().
Arquivo simulado.php (controlador para as telas de Simulado)
Fonte: Bruno Queiroz.
65
da requisição. Essa variável
representa a tarefa (função) que será executada pelo controlador. Caso não
do controlador, que é
Arquivo simulado.php (controlador para as telas de Simulado)
66
O arquivo simulado.php contém a classe controladora da página de listagem de
Simulado e da página de cadastro de Simulado. Como ele não é o controlador
padrão do componente, deve estar em
com_questoes/controllers/simulado.php, e sua classe deve ter a
nomenclatura {NomeDoComponente}Controller{NomeDoControlador}, conforme
descrito no item 4.5.1.
O controlador tem a função tanto de controlar a navegação entre páginas do
componente, quanto de delegar ao modelo tarefas solicitadas pela visão. Ele possui
funções, que o Joomla! trata como tasks. Portanto as funções save e cancel
contidas no arquivo são tasks, que realizam determinada tarefa. Por exemplo, para
executar a função save do controlador Simulado do componente Questoes, a URL
deve ser a seguinte:
index.php?option=com_questoes&controller=simulado&t ask=save.
Na função save, na linha 29, a instrução obtém o model para o controlador
Simulado. A função getModel(‘nomeDoModelo) automaticamente procura o modelo
cujo nome é {NomeDoComponente}Model{NomeDoModelo}. Mas só obtém o
modelo que estiver incluso na lista de modelos deste controlador. E por padrão o
único que já é inicializado como sendo um modelo deste controlador é o modelo de
nome {NomeDoComponente}Model{NomeDoControlador}, que no caso do
Quesões é QuestoesModelSimulado.
Na linha 34 a instrução JRequest::setVar(‘id_simulado’, $id_simulado) , cria
uma variável chamada id_simulado na requisição com valor igual ao valor da
variável $id_simulado. Na linha 35 a instrução inicializa a variável view na requisição
com o valor ‘simulados’. Isso faz com que o Joomla! redirecione para a visão
Simulados após o retorno dessa função.
Arquivo view.html.php
Figura
O arquivo view.html.php
dados do modelo e pass
JView::assignRef. É importante
template por meio de JView::assignRef
como por exemplo JView::assignRef(‘_variavel’, $variavel)
display deste arquivo é a função padrão
controlador. A visão não tem a função de formatar a saída dos dados. Quem faz isso
é o template utilizado pela
{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php
Figura 18 _ Arquivo view.html.php da visão Simulado
Fonte: Bruno Queiroz.
view.html.php representa determinada visão. Sua função é obter os
dados do modelo e passá-los para um template, por meio do método
É importante salientar que o nome da variável atribuída ao
JView::assignRef não pode conter under
JView::assignRef(‘_variavel’, $variavel)
deste arquivo é a função padrão, que será executada pela função
A visão não tem a função de formatar a saída dos dados. Quem faz isso
utilizado pela por ela, que por padrão será o arquivo
{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php
67
Arquivo view.html.php da visão Simulado
Sua função é obter os
, por meio do método
o nome da variável atribuída ao
underline em seu início,
JView::assignRef(‘_variavel’, $variavel) . A função
que será executada pela função display do
A visão não tem a função de formatar a saída dos dados. Quem faz isso
será o arquivo com nomenclatura
{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php , porém é
posssível setar um arquivo diferente como
requisição layout.
Arquivo de template
O arquivo de template contém
referências a arquivos de estilo ou
CSS e código de marcação HTML.
utilizando $this- >nomeDaVariavel
para o template, ele o acessa da seguinte forma:
objetivo da existência dos
utilizar templates diferentes conforme a necessidade, a fim de poder modificar a
forma como os mesmos dados s
Arquivo do modelo
Figura 19
Ao arquivo simulados.php
ela continua estendendo
JModel. A classe JModelList
posssível setar um arquivo diferente como template através da
contém a lógica da apresentação, é nele que
referências a arquivos de estilo ou JavaScript, códigos JavaScript
código de marcação HTML. Eles acessam os dados atribuídos pela visão
>nomeDaVariavel . Por exemplo, se a visão passa um simulado
, ele o acessa da seguinte forma: $this- >simulado
objetivo da existência dos templates, é possibilitar que uma mesma visão possa
diferentes conforme a necessidade, a fim de poder modificar a
forma como os mesmos dados são apresentados, sem precisar mudar de visão.
19 _ Arquivo simulados.php (modelo de simulados)
Fonte: Bruno Queiroz.
simulados.php contém uma classe que estende de
ela continua estendendo JModel indiretamente, pois JModelList
JModelList é também um modelo, mas provê funcionalidades
68
através da variável de
é nele que se encontram as
cript, códigos de estilo
Eles acessam os dados atribuídos pela visão
, se a visão passa um simulado
>simulado . O principal
é possibilitar que uma mesma visão possa
diferentes conforme a necessidade, a fim de poder modificar a
ão apresentados, sem precisar mudar de visão.
Arquivo simulados.php (modelo de simulados)
contém uma classe que estende de JModelList, porém
JModelList é subclasse de
é também um modelo, mas provê funcionalidades
extras, como facilitar a obtenção dos filtros de determinada pesquisa para obter os
dados no banco, listagem de múltiplos itens e facilitar na paginação
itens.
Figura 20
Esse método tem a função de popular variáveis com os valores dos filtros de uma
pesquisa. A instrução
variável da requisição e salva na sessão
entre uma requisição e outra
Há ainda o método getListQuesry()
para buscar a lista a ser exibida, e será utilizada pela paginação sempre que for
requisitada uma nova página desta.
populateState() serão
Arquivos de tabela
a obtenção dos filtros de determinada pesquisa para obter os
listagem de múltiplos itens e facilitar na paginação
20 _ Arquivo simulados.php (método populateState)
Fonte: Bruno Queiroz.
Esse método tem a função de popular variáveis com os valores dos filtros de uma
A instrução $this->getUserStateFromRequest()
variável da requisição e salva na sessão, a fim de que esses valores não se percam
e uma requisição e outra.
getListQuesry() , que retorna uma consulta que será utilizada
para buscar a lista a ser exibida, e será utilizada pela paginação sempre que for
requisitada uma nova página desta. Os filtros salvos durante o método
serão utilizados nesse método como filtros na
69
a obtenção dos filtros de determinada pesquisa para obter os
listagem de múltiplos itens e facilitar na paginação de uma lista de
Arquivo simulados.php (método populateState)
Esse método tem a função de popular variáveis com os valores dos filtros de uma
obtém o valor da
, a fim de que esses valores não se percam
que retorna uma consulta que será utilizada
para buscar a lista a ser exibida, e será utilizada pela paginação sempre que for
Os filtros salvos durante o método
como filtros na consulta.
São arquivos que represent
operações feitas no banco sobre
JTable{nomeDaTabela}
localizados no caminho {nomeDoComponente}/tables/{nomeDoArquivo}.php
Esses arquivos contêm
construtor recebe o nome da tabela e o nome da sua chave primária.
ver na linha 26, o nome da tabela começa com o prefi
convertido automaticamente pelo Joomla
banco de dados. Isso é necessário pois toda
do Joomla! possui um
instalações diferentes em um mesmo
Figura 21 _ Arquivo tables/simulado.php
Fonte: Bruno Queiroz.
arquivos que representam uma tabela no banco de dados, e
operações feitas no banco sobre esta tabela. Devem ter a seguinte nomenclatura:
JTable{nomeDaTabela} e devem estender a classe JTable.
{nomeDoComponente}/tables/{nomeDoArquivo}.php
variáveis que representam cada coluna da tabela
construtor recebe o nome da tabela e o nome da sua chave primária.
ver na linha 26, o nome da tabela começa com o prefixo “#__”. Esse prefixo é
convertido automaticamente pelo Joomla! para o prefixo utilizado pelas
Isso é necessário pois toda tabela de uma determinada
do Joomla! possui um mesmo prefixo, a fim de evitar incompatibilidad
em um mesmo banco. No caso do Questões, que utiliza o
70
a no banco de dados, e facilitam todas as
em ter a seguinte nomenclatura:
. Eles devem estar
{nomeDoComponente}/tables/{nomeDoArquivo}.php .
presentam cada coluna da tabela, e seu
construtor recebe o nome da tabela e o nome da sua chave primária. Como se pode
xo “#__”. Esse prefixo é
! para o prefixo utilizado pelas tabelas no
tabela de uma determinada instalação
prefixo, a fim de evitar incompatibilidade entre
. No caso do Questões, que utiliza o
71
prefixo sugerido pela instalação do Joomla!: o “jos_”; o nome da tabela será
convertido para “jos_quest_simulado”.
4.5.3. Tornando o Questões internacionalizado
O Questões utiliza uma extensão do tipo Linguagem para fins de
internacionalização. Apresentar-se-á a seguir a criação desta extensão.
O Joomla! utiliza a codificação de caracteres UTF-8, porém para evitar problemas
com sua utilização é necessário que o banco de dados ofereça suporte a esta
codificação. Portanto, é aconselhável utilizar o banco de dados MySQL a partir da
versão 4.1.2, pois as versões anteriores não oferecem suporte a esta codificação.
(KENNARD, 2007)
O Joomla! utiliza três pacotes de linguagem, um para frontend, um para backeend e
um para a instalação. Para criar um pacote de Linguagem para o frontend de um
componente é necessário uma estrutura como a seguinte:
Figura
Um pacote de Linguagem
diretório:
{nomedoc omponente}/language/{nomeDoPacote}
ponente}.ini . No caso
com_questoes/language/en
O nome do pacote da Linguagem deve seguir o padrão:
código da linguagem segundo a
especifica que o código de uma linguagem deve ser formado pela junção do nome
abreviado da linguagem (segundo a ISO 639
da região (segundo a ISO 3166
Os arquivos de extensão “.ini” são os que contêm a tradução. O nome dess
arquivos deve ter o padrão:
extensão].ini , onde [tipo de extensão]
A Figura 23 mostra como deve ser um arquivo ini.
Figura 22 _ Estrutura de um paco te de Linguagem
Fonte: Bruno Queiroz.
Um pacote de Linguagem de um componente deve ser instalado no seguinte
omponente}/language/{nomeDoPacote} /{nomeDoPacote}.{nomedocom
caso de uma tradução para inglês do Questões, ficaria
com_questoes/language/en -GB/en-GB.com_questoes.ini.
O nome do pacote da Linguagem deve seguir o padrão: [ln-LN]
segundo a Request for Comment 3066
especifica que o código de uma linguagem deve ser formado pela junção do nome
abreviado da linguagem (segundo a ISO 639-2), mais o caractere “
da região (segundo a ISO 3166-1); por exemplo: pt-BR, en-US, fr
são “.ini” são os que contêm a tradução. O nome dess
arquivos deve ter o padrão: [ln- LN].[tipo de extensão]_[nome da
[tipo de extensão] pode ser (“com”, “mod”, “plg”, “tpl”
mostra como deve ser um arquivo ini.
72
te de Linguagem
de um componente deve ser instalado no seguinte
/{nomeDoPacote}.{nomedocom
de uma tradução para inglês do Questões, ficaria
LN], onde [ln-LN] é o
3066 (RFC3066), que
especifica que o código de uma linguagem deve ser formado pela junção do nome
2), mais o caractere “-”, mais o código
fr-FR.
são “.ini” são os que contêm a tradução. O nome desses
LN].[tipo de extensão]_[nome da
“com”, “mod”, “plg”, “tpl”).
Figura
A chave representa a variável
quem será traduzida. Recomenda
e em inglês. O Valor representa a tradução da chave, ou seja, enquanto a chave é o
que será utilizado pelos desenvolvedores
será apresentado ao usuário final
forma de textos, labels ou mensagens.
Após ser inserida uma chave no arquivo de linguagens essa chave está pronta para
ser utilizada no Joomla!. Ela deve ser utilizada através da classe
exemplo, se precisarmos apresentar a
utilizar a instrução JText::_(‘ESCOLHA_UMA_OPCAO’)
Além do frontend, um componente também pode ter uma tradução para o (tanto no gerenciamento do componente quanto no gerenciamento de menus)a sua instalação. O arquivo de linguagem para o componente) seguirá o padrão administrator/la nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n
te}.ini, o arquivo de linguagem padrão administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen
te}.sys.ini . Já o arquivo de tradução da instalação
Figura 23 _ Arquivo ini (arquivo de tradução)
Fonte: Bruno Queiroz.
A chave representa a variável que é utilizada na aplicação e nas extensões, é ela
Recomenda-se que elas sejam escritas com letras
O Valor representa a tradução da chave, ou seja, enquanto a chave é o
que será utilizado pelos desenvolvedores, no código do Joomla!, o valor é o que
será apresentado ao usuário final. O valor aparecerá na visualização do sistema
ou mensagens.
Após ser inserida uma chave no arquivo de linguagens essa chave está pronta para
no Joomla!. Ela deve ser utilizada através da classe
exemplo, se precisarmos apresentar a label “Escolha uma Opção”
JText::_(‘ESCOLHA_UMA_OPCAO’) .
um componente também pode ter uma tradução para o (tanto no gerenciamento do componente quanto no gerenciamento de menus)
O arquivo de linguagem para o backend (gerenciamento do seguirá o padrão
nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n
o arquivo de linguagem do backend (gerenciamento de menus)
administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen
Já o arquivo de tradução da instalação deve ser inserido no pacote de
73
que é utilizada na aplicação e nas extensões, é ela
se que elas sejam escritas com letras maiúsculas
O Valor representa a tradução da chave, ou seja, enquanto a chave é o
, no código do Joomla!, o valor é o que
na visualização do sistema na
Após ser inserida uma chave no arquivo de linguagens essa chave está pronta para
no Joomla!. Ela deve ser utilizada através da classe JText. Por
“Escolha uma Opção” na tela, devemos
um componente também pode ter uma tradução para o backend (tanto no gerenciamento do componente quanto no gerenciamento de menus) e para
(gerenciamento do
nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n
(gerenciamento de menus) seguirá o
administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen
deve ser inserido no pacote de
74
instalação com o seguinte padrão: language/{nomeDoPacote}/{nomeDoPacote}.ini.
75
5. CONSIDERAÇÕES FINAIS
Como resultado principal deste estudo, demonstraram-se os principais aspectos
relacionados ao desenvolvimento de componentes para a versão 1.6 do Joomla!,
sendo apresentados seu framework, a arquitetura e as convenções de codificação
que ele propõe que sejam utilizados na construção de componentes; ao passo que
discorre-se sobre os benefícios de se utilizar tais padrões. Portanto tem-se agora
uma fonte consistente e centralizada, que apresenta ao desenvolvedor todos os
passos necessários para o desenvolvimento de um componente para o Joomla!, que
siga as boas práticas e os padrões de codificação propostos para este CMS. Além
disso, foi desenvolvido um componente que tem a função de cadastro, publicação e
resolução de questões de múltipla escolha; e poderá ser utilizado por websites que
utilizem o Joomla! 1.6, e que precisem ter essa funcionalidade, como sites de
concursos, vestibulares ou sites de escolas.
Um resultado secundário deste trabalho, mas que terá grande importância para
pesquisas futuras, é o estudo realizado acerca do tema CMS, que possibilitou ter
vários conceitos importantes sobre este tema reunidos em um único trabalho, e
servirá portanto como uma fonte de consulta abrangente mas sucinta sobre CMS.
O componente Questões poderá ter uma grande importância para os websites que
precisem implementar a funcionalidade de resolução de questões. No entanto esse
componente ainda não está completo o suficiente para servir aos requisitos da
maioria dos websites, portanto fica proposto como trabalho futuro a melhoria do
componente Questões, tanto nas funcionalidades já existentes quanto na
implementação de novas funcionalidades.
76
BIBLIOGRAFIA
AIIM. What is Enterprise Content Management (ECM)? . Disponível em: < http://www.aiim.org/What-is-ECM-Enterprise-Content-Management>. Acesso em: 15 mai. 2011.
BATISTA, André Luiz Franca. Proposta de um sistema para ranqueamento de sistemas gerenciadores de conteúdo baseado em análi ses comparativas. 2007. 47f. Monografia (graduação em Ciência da Computação) - Departamento de Ciência da Computação, Universidade Federal de Lavras, Lavras, 2007.
BOIKO, Bob. Content Management Bible. 2. ed., Indianapolis: Wiley Publishing, Inc, 2005.
DIGITAL Purview. Types of CMS. Disponível em: < http://www.digitalpurview.com/types-of-cms/ >. Acesso em: nov. 2010.
FOWLER Martin. GUI Architectures. Disponível em: < http://www.martinfowler.com/eaaDev/uiArchs.html>. Acesso em: 16 mai. 2011.
FRASER, Stepen R. G. Real World ASP.NET: Building a Content Management System. [s.l]: Apress, 2002.
77
IDEALWARE. Comparing open source Content Management Systems: Wordpress, Joomla, Drupal and Plone. Disponível em: < http://www.idealware.org/sites/idealware.org/files/idealware_os_cms_2010_1.pdf>. Acesso em: 14 mai. 2011.
JOOMLA!. Site Oficial da Comunidade Joomla!. Disponível em: < http://www.joomla.org/ >. Acesso em: 28 Nov. 2010.
KENNARD James. Mastering Joomla! 1.5 Extension and Framework Development: The Professional's Guide to Programming Joomla!. Olton: Packt Publishing Ltd., 2007.
NETO Jurmir Canal. Conhecendo mais do Framework Grails . Disponível em: < http://imasters.com.br/artigo/17545/desenvolvimento/conhecendo-mais-do-framework-grails>. Acesso em: 16 mai. 2011.
NEVES Ricardo. As ferramentas de gestão de conteúdo – parte 1. Webinsider, [s.l], mai 2003. Seção Sem Categoria. Disponível em: <http://webinsider.uol.com.br/2003/05/26/as-ferramentas-de-gestao-de-conteudo-parte-1/>. Acesso em: 16 nov. 2010.
ORACLE. Java BluePrints Model-View-Controller. Disponível em: < http://www.oracle.com/technetwork/java/mvc-detailed-136062.html>. Acesso em: 16 mai. 2011.
78
RAHMEL, Dan. Beginning Joomla!: From Novice to Professional. New York: Apress, 2007.
ROMANÍ, Cristóbal Cobo; KUKLINSKI, Hugo Pardo. Planeta Web 2.0. Inteligencia colectiva o medios fast food. México: Grup de Recerca d'Interaccions Digitals,Universitat de Vic. Flacso México. Barcelona / México DF, 2007.
SCARATE, André Luís. Implantação de Gerenciadores de Conteúdo para administrar sites da Assessoria de Comunicação Soci al da Universidade Estadual De Maringá. 2007. 88f. Trabalho de Conclusão de Curso (Especialização em Desenvolvimento de Sistemas para Web) – Universidade Estadual de Maringá, Maringá, 2007.
T-SYSTEMS. ECM - Enterprise Content Management: Do arquivamento eletrônico para a solução de gerenciamento de conhecimento. Disponível em: http://www.t-systems.com.br/tsi/pt/229150/Homepage/Solutions-Industries/Solutions/Horizontal-Applications-&-Transformational-Outsourcing-/ECM---Enterprise-Content. Acesso em: 15 mai. 2011.
WILLIAMS Steve. Enterprise Content Management. Disponível em: <http://www.contentmanager.eu.com>. Acesso em: 28 nov. 2010.
W3C. Internacionalização: Localização vs. Internacionalização. Disponível em: <http://www.w3.org/International/questions/qa-i18n>. Acesso em: 19 mai. 2011.
79
W³TECHS. Usage of content management systems for websites. Disponível em: <http://w3techs.com/technologies/overview/content_management/all>. Acesso em: 18 mai. 2011.