FACULDADE 7 DE SETEMBRO - FA7    CURSO GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO              BRUNO QUEIROZ DUARTEEXPLORANDO O D...
BRUNO QUEIROZ DUARTEEXPLORANDO O DESENVOLVIMENTO DE COMPONENTES              PARA O JOOMLA 1.6                      Monogr...
DEDICATÓRIA  Dedico este trabalho aos meus queridos pais,  David e Jaqueline, à minha querida esposa,  Nayara, e à minha q...
AGRADECIMENTOSPor trás do “grande passo para a humanidade” houve certamente uma série desucessos e fracassos, que não fora...
Ao PROUNI, por ter possibilitado àquele garoto simples e sem grandes pretensões,que achava que iria morrer sem ao menos ve...
RESUMOEste trabalho surgiu da necessidade de se ter um material completo acerca dodesenvolvimento de componentes para a ve...
ABSTRACTThis scientific monograph arose from the need to have a complete stuff about thedevelopment of components to versi...
LISTA DE ILUSTRAÇÕESFigura 1 _ Estrutura geral de um CMS ....................................................................
LISTA DE ABREVIATURAS E SIGLASACL    Access Control ListCMS    Content Management SystemCoC    Convention Over Configurati...
SUMÁRIODEDICATÓRIA ..........................................................................................................
3.2.     HISTÓRICO DO JOOMLA! .......................................................................... 32  3.3.     CONH...
111. INTRODUÇÃOSegundo Batista (2007), o conteúdo disponível na internet vem crescendo a cadadia. Além disso, há também o ...
12do Joomla! contém algumas informações importantes para o desenvolvimento queencontram-se dispersas por várias páginas às...
13   1.2.      OBJETIVOS ESPECÍFICOSApresentar o que é CMS e para que ele serve, além de categorizá-los por tipo.Apresenta...
142. SISTEMA DE GESTÃO DE CONTEÚDO   2.1.      O QUE É CONTEÚDOAntes de nos aprofundarmos no conceito de Sistema de Gestão...
15   2.2.       GESTÃO DE CONTEÚDOGestão de conteúdo é o processo de coletar, gerenciar e publicar conteúdo. (BOIKO,2005) ...
16   d) Riscos de diversos erros e informação de baixa qualidade.   e) Informações sobre estrutura misturadas ao conteúdo....
17A padronização das interfaces torna desnecessário ter de aprender tudo do zerotoda vez que uma nova funcionalidade seja ...
18feita sem muito esforço, através do rollback. Rollback reverte um conteúdo paraestágios prévios deste.Workflow (fluxo de...
19Alguns CMS possuem a funcionalidade de converter arquivos de um formato para oformato requerido pelo repositório. Por ex...
20                         Figura 1 _ Estrutura geral de um CMS                               Fonte: Boiko (2005, p. 86).B...
21                 Figura 2 _ Estrutura do Sistema de Coleta                          Fonte: Boiko (2005, p. 87).Autoria: ...
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. ...
23   o Stripping: remoção de informação desnecessária, tal como cabeçalhos      e rodapés de páginas e conteúdo desnecessá...
24Sistema de gestãoO Sistema de Gestão é o subsistema responsável pelo armazenamento eadministração do conteúdo. Ele provê...
25      Workflow: é responsável pela coordenação, agendamento (scheduling) e      tarefas pessoais.      Conexões: o Siste...
26      2.4.3.        Tipos de CMSWilliams (2010) explica que há vários tipos de conteúdo digital, e queconsequentemente h...
27      Desta forma, o ativo não pode ser visualizado de outra maneira que não      através do próprio DAM. Isso proporcio...
28Um WCMS é uma ferramenta utilizada tanto por pessoas com conhecimento técnicoquanto por pessoas sem conhecimento técnico...
29Sistema de Gestão de Conteúdo EmpresarialAproximadamente 80% das informações/documentos das empresas não seencontram em ...
30localização do conteúdo, para que no futuro essa informação seja recuperadabaseada em sua categorização.Indexação: consi...
31Integração de Conteúdo: possibilita aos diferentes tipos de conteúdo aserem tratados como se estivessem em um mesmo repo...
323. O CMS JOOMLA!   3.1.      O QUE É JOOMLA!Joomla! é um bem conceituado CMS que permite criar websites de forma fácil e...
33vendê-lo a outra empresa ou comercializá-lo de forma não gratuita. Como o MOSera open source, seus desenvolvedores então...
34   3.3.      CONHECENDO O JOOMLA!      3.3.1.       Requisitos de instalaçãoO Jommla! foi totalmente desenvolvido na lin...
35      3.3.2.       ArquiteturaA Figura 3 apresenta a arquitetura do Joomla!                          Figura 3 _ Arquitet...
36Na camada de Extensão (ver item 3.3.3) estão os pacotes que estendem ocomportamento padrão do Joomla!. Algumas extensões...
37Uma Extensão é um termo genérico que consiste em um pacote que pode seradicionado   ao   seu   website   Joomla!,   incl...
38TemplateUm Template é basicamente o design do website, é um tipo de extensão quemodifica a maneira como as páginas e out...
39                         Figura 4 _ Funcionamento de um Plugin                               Fonte: Rahmel (2007, p. 267...
40ComponenteComponentes podem algumas vezes ser confundidos com Módulos, porém não édifícil distingui-los. Componentes pos...
41permitido realizar tarefas administrativas como gerenciar extensões eusuários.Backend: parte administrativa do site, que...
424. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA!Este capítulo tem como objetivo apresentar um passo a passo para se dese...
43            Figura 5 _ Diagrama de Casos de Uso do componente Questões                               Fonte: Bruno Queiro...
44                 Figura 6 _ Diagrama de Atividades (Cadastrar Questão)                                 Fonte: Bruno Quei...
45                 Figura 7 _ Diagrama de Atividades (Cadastrar Simulado)                                  Fonte: Bruno Qu...
46                 Figura 8 _ Diagrama de Atividades (Resolver Simulado)                                 Fonte: Bruno Quei...
47A Figura 9 apresenta a tela de listagem de provas, sendo que cada prova contémvárias questões. Pode-                    ...
48A Figura 10 representa a funcionalidade de cadastro de questões. Esta é afuncionalidade mais complexa, onde se deve prim...
49            Figura 10 _ Tela do componente Questões (Cadastro de Questões)                                              ...
50            Figura 11 _ Tela do componente Questões (Listagem de Simulados                                              ...
51            Figura 12 _ Tela do componente Questões (Cadastro de Simulado)                                              ...
52           Figura 13 _ Tela do componente Questões (                                                   (Resolução de Sim...
53(controller). Cada uma dessas camadas possui responsabilidades distintas. Elas sãoseparadas de forma que a parte do sist...
54                            Figura 14 _ Estrutura do MVC                                Fonte: Bruno Queiroz.Tanto a Vis...
55Visão é a camada responsável por apresentar os dados do modelo de maneira quepossibilite interação com humanos, e servir...
56   4.4.       O JOOMLA! FRAMEWORKUm framework é uma estrutura reutilizável dentro de uma aplicação. No Joomla! oframewor...
57   4.5.      DESENVOLVENDO O COMPONENTEO código do Joomla! foi projetado para facilitar o reuso e a extensibilidade, lev...
58Convenções de nomeação e estrutura de pastasAntes de tudo é importante salientar que o framework do Joomla! é bastantefl...
59       Figura 15 _ Estrutura de diretórios do componente Questões                          Fonte: Bruno Queiroz.A primei...
60Todo componente deve ter um ponto de entrada (entry point). Como o nomediz, esse arquivo deve ser o ponto de entrada de ...
61menos que especifique via código qual o modelo que deverá ser criado paratal visão.A pasta controllers contém controlado...
62             realmente os dados é o template. O template deve ficar na pasta             /nomedavisao/tmpl, e normalment...
63      4.5.2.        CodificaçãoAgora que já se tem a teoria para a criação da estrutura do componente, serãoapresentadas...
64O arquivo com_questoes/questões.php é o ponto de entrada do componente, issosignifica que toda requisição ao Questões de...
65A instrução da linha 21 obtém o valor da variável task da requisição Essa variável                                      ...
66O arquivo simulado.php contém a classe controladora da página de listagem deSimulado e da página de cadastro de Simulado...
67                  Figura 18 _ Arquivo view.html.php da visão Simulado                                 Fonte: Bruno Queir...
68posssível setar um arquivo diferente como template através da variável derequisição layout.Arquivo de templateO arquivo ...
69extras, como facilitar a obtenção dos filtros de determinada pesquisa para obter osdados no banco, listagem de múltiplos...
70                       Figura 21 _ Arquivo tables/simulado.php                                Fonte: Bruno Queiroz.São a...
71prefixo sugerido pela instalação do Joomla!: o “jos_”; o nome da tabela seráconvertido para “jos_quest_simulado”.      4...
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6
Próximos SlideShares
Carregando em…5
×

Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6

2.290 visualizações

Publicada em

Trabalho acerca de desenvolvimento de componentes para Joomla

2 comentários
1 gostou
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.290
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
86
Comentários
2
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Monografia - EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6

  1. 1. FACULDADE 7 DE SETEMBRO - FA7 CURSO GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO BRUNO QUEIROZ DUARTEEXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6 FORTALEZA – 2011
  2. 2. BRUNO QUEIROZ DUARTEEXPLORANDO 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
  3. 3. 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.
  4. 4. AGRADECIMENTOSPor trás do “grande passo para a humanidade” houve certamente uma série desucessos 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émsuperações, porém eu tive a sorte de ter tido sempre pessoas com quemcompartilhar os sucessos e com quem chorar os fracassos. Este trabalho é apenasum coroamento da minha trajetória até aqui, trajetória essa que não iniciou nafaculdade, 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írampara ele se concretizasse:A Deus, por ter permitido que eu chegasse até aqui, e por ter me dado a sorte esabedoria 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 quehoje tenho, por terem me educado para ser essa pessoa “do bem” que sou hoje, porserem boas referências para mim; e especificamente à minha mãe, que mesmo compouco estudo me alfabetizou, pelas historinhas que me contava, e por coisassimples como me falar com entusiasmo que aquele animal correndo na TV era umalebre ao invés de coelho, me incentivando, mesmo sem querer, a ser uma pessoacuriosa e amante do conhecimento.À minha tia, Erineide, por ter me acolhido em sua casa aqui em Fortaleza, e assimter me possibilitado concluir esta etapa, por ter me amado como um filho, sempreficando feliz por cada realização minha; e a seu filho, Marlon, por ter me recebidocomo um irmão e por ter sempre sido uma boa companhia para mim.À minha esposa, Nayara, por ser minha companheira, sempre tendo paciênciacomigo nas noites que passei em claro durante este trabalho, e por ter me dadoforças para concluí-lo.Aos meus irmãos, David Filho e Daniele, por terem sido sempre uma ótimacompanhia para mim, por me proporcionarem bons momentos e por estarem do meulado durante grande parte dessa caminhada.Aos meus professores, desde o jardim até aqui, por terem me guiado e me ajudadona construção do meu conhecimento, e principalmente àqueles que foram além dasala de aula, se preocupando com os problemas pessoais de cada um, e inclusiveos 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 únicaturma, 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 TVescola) que foram por algum tempo uma agradável companhia e fonte deconhecimentos e lazer.
  5. 5. 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 ensinosuperior 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 todosesses anos, e por terem compartilhado juntos comigo os bons e os difíceismomentos da faculdade.Ao meu professor orientador, Ivan de Oliveira, por ter me guiado na escolha dessetema, por ter sempre me encorajado durante o desenvolvimento deste trabalho, epor 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 medado a possibilidade de estudar com os melhores professores que há; Ao curso deSI e à coordenação do curso, por sempre estarem do lado dos alunos e porbuscarem sempre a melhoria do nosso conhecimento.A muitas outras pessoas que não foram citadas aqui, mas que também tiveram umaparcela de importância neste trabalho, meus sinceros agradecimentos.
  6. 6. RESUMOEste trabalho surgiu da necessidade de se ter um material completo acerca dodesenvolvimento de componentes para a versão 1.6 do CMS Joomla!, visto que adocumentação encontrada na Internet ainda é bastante vaga e dispersa, e os livrosque tratam desse assunto estão desatualizados, sendo que sua maioria aborda aversão 1.5 do Joomla!. Este estudo tem o objetivo de ser uma fonte de pesquisapara desenvolvedores de componentes para o Joomla! 1.6, discorrendo sobretécnicas e padrões que devem ser seguidos para que se possa desenvolver umcomponente com arquitetura robusta e extensível, além de apresentar as facilidadesprovidas pelo Joomla! 1.6 para o desenvolvimento de componentes.Palavras-chave: Gestão de Conteúdo. CMS. Joomla!. Componentes. MVC.Internacionalização.
  7. 7. ABSTRACTThis scientific monograph arose from the need to have a complete stuff about thedevelopment of components to version 1.6 of Joomla!, since the documentationfound on the Internet is still quite vague and scattered, and books dealing with thissubject are outdated, and which mostly deals with version 1.5 of Joomla. This studyaims to be a resource for developers of components for the Joomla! 1.6, discussingtechniques and standards that must be followed so that we can develop a robust andflexible architecture for the component, and present the facilities provided by theJoomla! 1.6 for the development of components.Keywords: Content Management. CMS. Joomla!. Components. MVC.Internationalization.
  8. 8. LISTA DE ILUSTRAÇÕESFigura 1 _ Estrutura geral de um CMS ...................................................................... 20Figura 2 _ Estrutura do Sistema de Coleta ............................................................... 21Figura 3 _ Arquitetura do Joomla! ............................................................................. 35Figura 4 _ Funcionamento de um Plugin ................................................................... 39Figura 5 _ Diagrama de Casos de Uso do componente Questões ........................... 43Figura 6 _ Diagrama de Atividades (Cadastrar Questão).......................................... 44Figura 7 _ Diagrama de Atividades (Cadastrar Simulado) ........................................ 45Figura 8 _ Diagrama de Atividades (Resolver Simulado) .......................................... 46Figura 9 _ Tela do componente Questões (Listagem de Provas) ............................. 47Figura 10 _ Tela do componente Questões (Cadastro de Questões) ....................... 49Figura 11 _ Tela do componente Questões (Listagem de Simulados) ...................... 50Figura 12 _ Tela do componente Questões (Cadastro de Simulado)........................ 51Figura 13 _ Tela do componente Questões (Resolução de Simulado) ..................... 52Figura 14 _ Estrutura do MVC ................................................................................... 54Figura 15 _ Estrutura de diretórios do componente Questões .................................. 59Figura 16 _ Arquivo questoes.php (entry point do componente) ............................... 63Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado) ............. 65Figura 18 _ Arquivo view.html.php da visão Simulado .............................................. 67Figura 19 _ Arquivo simulados.php (modelo de simulados) ...................................... 68Figura 20 _ Arquivo simulados.php (método populateState) ..................................... 69Figura 21 _ Arquivo tables/simulado.php .................................................................. 70Figura 22 _ Estrutura de um pacote de Linguagem .................................................. 72Figura 23 _ Arquivo ini (arquivo de tradução)............................................................ 73
  9. 9. LISTA DE ABREVIATURAS E SIGLASACL Access Control ListCMS Content Management SystemCoC Convention Over ConfigurationDAM Digital Asset Management SystemDMS Document Management SystemECMS Enterprise Content Management SystemERM Electronic Records ManagementERP Enterprise Resource PlanningGC Gerenciamento de ConteúdoGPL General Public LicenseHTML HyperText Markup LanguageLAN Local Area NetworkOCR Optical Character RecognitionMOS Mambo Open SourceSEO Search Engine OptimizationWAN Wide Area NetworkWCMS Web Content Management System
  10. 10. SUMÁRIODEDICATÓRIA ............................................................................................................ 2AGRADECIMENTOS .................................................................................................. 3RESUMO..................................................................................................................... 5ABSTRACT ................................................................................................................. 6LISTA DE ILUSTRAÇÕES .......................................................................................... 7LISTA DE ABREVIATURAS E SIGLAS ...................................................................... 8SUMÁRIO.................................................................................................................... 91. INTRODUÇÃO .................................................................................................... 11 1.1. OBJETIVO GERAL ...................................................................................... 12 1.2. OBJETIVOS ESPECÍFICOS ........................................................................ 132. 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 ........................................................................................ 263. O CMS JOOMLA! ............................................................................................... 32 3.1. O QUE É JOOMLA!...................................................................................... 32
  11. 11. 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 .............................................................................. 404. 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 .............................................. 715. CONSIDERAÇÕES FINAIS ................................................................................ 75BIBLIOGRAFIA ......................................................................................................... 76
  12. 12. 111. INTRODUÇÃOSegundo Batista (2007), o conteúdo disponível na internet vem crescendo a cadadia. Além disso, há também o aumento da necessidade de se ter conteúdo atual ede natureza colaborativa, onde se possa comentá-lo e até mesmo modificá-lo. Asempresas 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 fazparte 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 osmais adaptados. Outro fator responsável pelo aumento da quantidade de conteúdona web e da necessidade do dinamismo de tal conteúdo são os próprios usuários daweb. Impulsionados pelos mais diversos objetivos esses usuários necessitam deferramentas que os auxiliem na publicação de conteúdo de forma rápida etransparente, sem a necessidade de conhecimentos de protocolos ou de linguagensde programação/marcação relacionados à web.Tanto a necessidade das empresas quanto as necessidades pessoais dosindivíduos de manter conteúdo de forma eletrônica podem ser satisfeitas com autilização de ferramentas chamadas Content Management Systems (CMS), emportuguês, Sistemas de Gerenciamento de Conteúdo, ou Sistemas de Gestão deConteú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 é oJoomla!, sendo utilizado por 10,5% dos sites que utilizam CMS. Além disso, segundoIdealware (2011) o Joomla! é o CMS que possui o melhor equilíbrio entreflexibilidade e facilidade de uso, o que o torna um dos CMS mais cotados para váriostipos de websites. Parte dessa flexibilidade deve-se às extensões providas peloJoomla!, especialmente a do tipo Componente, que possibilitam estender as suasfuncionalidades básicas de maneira simples e rápida. Apesar da vastadocumentação encontrada na web referente à utilização do CMS Joomla!, há certadificuldade em se encontrar material referente ao desenvolvimento de extensões,sendo o site oficial do Joomla! um dos poucos lugares onde se pode encontrardocumentação mais aprofundada. Apesar de aprofundada, a documentação oficial
  13. 13. 12do Joomla! contém algumas informações importantes para o desenvolvimento queencontram-se dispersas por várias páginas às vezes difíceis de se encontrar. Alémdisso, essa documentação não contempla certas peculiaridades que podemaparecer durante o desenvolvimento e que às vezes são resolvidas somente atravésdos fóruns de discussão do Joomla!Diante dessa crescente necessidade da utilização de CMS em websites, e dagrande parcela de adoção do CMS Joomla! como tecnologia para esses websites,fazem-se necessárias novas fontes de documentação sobre o desenvolvimento deextensões, que venham a trazer uma perspectiva diferente para o desenvolvimentode componentes; das encontradas na documentação oficial.Este trabalho é dividido em quatro capítulos. O segundo capítulo aborda osSistemas de Gestão de Conteúdo, explicando inicialmente o que é conteúdo, depoisexplica o que é gestão de conteúdo e seus benefícios, e depois, com essesconceitos já construídos, explica o que é Sistema de Gestão de Conteúdo,explanando sobre suas principais funcionalidades, sua estrutura e os principais tiposde CMS. O terceiro capítulo apresenta uma visão do CMS Joomla!, apresentandoum breve resumo do seu histórico e depois aprofunda-se um pouco mais, explicandoseus requisitos, arquitetura e suas extensões. O quarto capítulo é o principal capítulodeste trabalho, onde é explorado o desenvolvimento de componentes para a versão1.6 do Joomla!. 1.1. OBJETIVO GERALExplorar o desenvolvimento de componentes para a versão 1.6 do Joomla!,apresentando a arquitetura padrão que deve ser adotada no componente, padrõesde codificação e boas práticas que devem ser seguidas para melhoria deextensibilidade, manutenibilidade e segurança do componente.
  14. 14. 13 1.2. OBJETIVOS ESPECÍFICOSApresentar 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 principaise conceitos importantes como, extensões, frontend e backend. Apresentar conceitosde MCV e Internacionalização, que sirvam de base para o completo entendimentodo estudo. Apresentar o componente Questões, componente de coma finalidade decadastro de questões e resolução de simulados, que foi desenvolvido durante esteestudo. Apresentar o framewowk do Joomla!, as convenções de codificação que eleutiliza 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, dasconvenções de código e das boas práticas de programação para componentes comJoomla!.
  15. 15. 142. SISTEMA DE GESTÃO DE CONTEÚDO 2.1. O QUE É CONTEÚDOAntes 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 deinformação, tais como: dados, textos, imagens, sons e software. Já Boiko (2005), fazuma explanação sobre os conceitos de dado e informação, e através destesfundamenta 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, demaneira isolada, não possuem muito significado relevante aos humanos, enquantoque informação é um conjunto de dados organizados de maneira que possuamalguma semântica. Já o conteúdo é a informação com determinado propósito, e emuma forma utilizável por humanos. Ele afirma que informação que flui casualmentenão é conteúdo. Ela torna-se conteúdo apenas depois que alguém dá a ela umautilidade.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 deinterações homem-computador, utilizando uma interface entre o usuário e amáquina, a fim de realizar determinado processo; depois explica que aimplementação de funcionalidade nos sistemas está ficando cada vez mais granular,com objetos que podem ser adicionados de diversas fontes e maneiras, fazendocom que a funcionalidade possa ser gerenciável tal qual conteúdo, tornando adistinção entre os dois cada vez mais difícil.
  16. 16. 15 2.2. GESTÃO DE CONTEÚDOGestã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 desdea sua criação, até a sua disponibilização, arquivamento ou eliminação. 2.3. BENEFÍCIOS DA GESTÃO DE CONTEÚDOA 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 fontese 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 seguintesproblemas 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.
  17. 17. 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ÚDOEm uma abordagem de mais alto nível, um CMS é uma ferramenta ou conjunto deferramentas responsável pela coleta, gerenciamento e publicação de “pedaços” deinformaçã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 CMSDe 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 epublicação de conteúdo. Porém, a grande maioria dos CMS possui funcionalidadesque vão além das mínimas. Apesar da grande variedade, há um conjunto defuncionalidades que são mais comuns entre os sistemas, merecendo portanto, umaexplanação sobre elas.Serão apresentadas agora as funcionalidades mais comumente encontradas nosCMS, segundo Fraser (2002).Interface padrão para criação, edição e aprovação de conteúdo
  18. 18. 17A padronização das interfaces torna desnecessário ter de aprender tudo do zerotoda 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çasexistentes nas novas interfaces em relação às já existentes.Apesar de parecer óbvio essa funcionalidade, há alguns CMS que ainda não apossuem. Isso se deve ao fato de esses CMS terem sido criados a partir da junçãode outras ferramentas, cada uma com sua interface padrão. Essas interfaces entãopassaram a fazer parte do novo CMS.Repositório comumColocar 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 umarquivo de controle que informa ao CMS em qual repositório o conteúdo estáguardado.Controle de Versão, Monitoramento e RollbackManter informação de controle de versão do conteúdo é uma das funcionalidadesmais importantes no CMS.Quando não há um controle de versão no CMS, normalmente o conteúdo pode ficardesatualizado. Por exemplo, o autor A inclui um conteúdo. Então o editor B edita oconteúdo e o aprova. Então o autor A altera a cópia original do conteúdo, que aindaestava na sessão, e a salva novamente, sobrescrevendo o conteúdo previamenteaprovado 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 Bserão perdidas.Às vezes edições de conteúdo podem acrescentar erros, ou simplesmente o usuárioresolve desistir da mudança feita, com o controle de versão essa mudança pode ser
  19. 19. 18feita sem muito esforço, através do rollback. Rollback reverte um conteúdo paraestágios prévios deste.Workflow (fluxo de trabalho)Segundo Fraser (2002), um workflow (fluxo de trabalho) é um conjunto de tarefasrealizadas de maneira sequencial ou paralela, por mais de uma pessoa, com afinalidade de alcançar um objetivo comum.Todos os CMS possuem algum workflow. Uma característica importante em umCMS é o quão simples e flexível é seu sistema de workflow. Muitos CMS permitemao usuário criar workflows personalizados, enquanto outros permitem ao usuáriorealizar apenas as tarefas básicas já pré-definidas: criação, edição, aprovação epublicação.Geração dinâmica de páginasUm CMS gera páginas dinamicamente através de layouts e componentes retiradosdo repositório. A utilização de páginas dinâmicas permite que requisições iguaispossam gerar páginas diferentes para diferentes usuários.PersonalizaçãoA personalização permite que o site apresente apenas o conteúdo específico paradeterminado usuário, baseado nas preferências pessoais e na sua forma denavegação. Podem haver vários níveis de personalização, desde uma simplespresença do nome do usuário em um site, até sites que não deixam aparecerdeterminados conteúdos dependendo da configuração feita pelo usuário.Gerenciamento de cacheNo que concerne às funcionalidades de um CMS, cache é o processo de armazenarpáginas pré-configuradas em memória ou repositório, de maneira a facilitar apesquisa dessas páginas posteriormente.Conversão de conteúdo
  20. 20. 19Alguns CMS possuem a funcionalidade de converter arquivos de um formato para oformato requerido pelo repositório. Por exemplo, um CMS pode transformarautomaticamente 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 depreferência, desde que o CMS consiga converter seu formato.Integração com Sistemas de BuscaA maioria dos CMS utiliza sistemas de busca externos. A vantagem disso é que oCMS ficará especializado somente na gestão de conteúdo, enquanto as buscasserão realizadas por sistemas especializados em busca, ou seja, sistemas queproveem a melhor solução para tal problema.Alguns CMS possuem seu próprio sistema de buscas. Porém esses sistemas nãosã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 aspáginas iniciais e finais que predominam em cada vez que um usuário acessa osistema. 2.4.2. Estrutura de um CMSA Figura 1 ilustra a estrutura básica de um CMS.
  21. 21. 20 Figura 1 _ Estrutura geral de um CMS Fonte: Boiko (2005, p. 86).Boiko (2005) divide a estrutura dos CMS em três subsiste subsistemas: Sistema de Coleta,Sistema de Gestão e Sistema de Publicação que trabalham em conjunto a fim de Publicação,possibilitar a gestão do conteúdo. Apesar de estes subsistemas estaremlogicamente separados, eles podem sobrepor sua funcionalidade à dos subsistemasadjacentes. Abaixo será apresentado cada um deles deles.Sistema de ColetaO sistema de coleta é respons responsável por todos os processos ocorridos antes que umconteúdo esteja pronto para ser publicado. É ele quem torna a informa informação simplesem um conjunto bem organizado de content components. A Figura 2 ilustra osserviços oferecidos no processo de coleta, que são: autoria, aquisição, conversão,agregação e serviços de coleta coleta.
  22. 22. 21 Figura 2 _ Estrutura do Sistema de Coleta Fonte: Boiko (2005, p. 87).Autoria: refere-se ao processo de criar conteúdo do zero. Um autor é alguém se conteúdoque deve ser esp especificado para esta, caso contrário o processo será ,aquisição ao invés de autoria. O processo de autoria é diferente dos demaisprocessos providos pelo CMS, pois ele é essencialmente manual rovidos manual,dependendo somente da habilidade e capacidade do autor. Apesar de nãopoder automatizar o processo de autoria, o CMS provê algumas facilidadespara o autor. São elas: ão o Ambiente de autoria, com uma aplicação completa e extensões qu que facilitam o trabalho do autor.
  23. 23. 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 originalmentecriada para determinado CMS. Isto significa que na Aquisição, a informaçãonão é criada, mas copiada de uma fonte externa para o CMS. Esse processopode ser tanto manual quanto automático. A informação adquirida pode virdas 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 quevocê criou ou adquiriu é diferente do formato ou estrutura requerida pelosistema. O processo de conversão consiste de três passos:
  24. 24. 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 orepositório. Eles ajudam tanto no processo de autoria quanto no processo deaquisiçã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.
  25. 25. 24Sistema de gestãoO Sistema de Gestão é o subsistema responsável pelo armazenamento eadministração do conteúdo. Ele provê detalhes sobre seu conteúdo, como quaiscomponentes estão sendo gerenciados no momento, e em que fase do ciclo de vidacada componente está. Além de informar quais conteúdos estão sendo utilizados ounã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.
  26. 26. 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çãoO Sistema de Publicação é o subsistema responsável por obter o conteúdopreviamente salvo no repositório, a fim de publicá-lo, ou seja, apresentá-lo dealguma 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.
  27. 27. 26 2.4.3. Tipos de CMSWilliams (2010) explica que há vários tipos de conteúdo digital, e queconsequentemente há também diversas categorias de ferramentas de Gestão deConteúdo, que podem ser classificadas de acordo com o tipo de conteúdo quegerenciam. Ele divide essas ferramentas em: Sistema de Gestão de Ativos Digitais,em inglês, Digital Asset Management System (DAM); Sistema de Gestão deDocumentos, em inglês, Document Management System (DMS); Gestão deRegistros Eletrônicos, em ingês, Electronic Records Management (ERM); Sistemade 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, EnterpriseContent 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 pelaindústria de mídia e entretenimento. Alguns exemplos de DAM são: FedoraCommons, FocusOPEN e Gallery.Os DAM podem ser divididos em dois tipos básicos, segundo a forma como elesarmazenam 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.
  28. 28. 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 DocumentosDMS são ferramentas construídas com a finalidade de auxiliar as organizações nogerenciamento da criação, armazenamento e obtenção de informação armazenadana forma de documentos digitais (planilhas do Microsoft Excel, documentos doMicrosoft Word, PDFs, dentre outros). Ele utiliza um repositório centralizado paraarmazenar os documentos, adicionando esquemas de classificação e protegendo-oscontra 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 agrupardocumentos, foco no gerenciamento do ciclo de vida de um documento, acesso adocumentos pode ser restringido por pasta.Devido ao tipo de conteúdo gerido pelo DMS, ele pode ser classificado como umDAM, 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, GoogleDocs e DOCS Open.Gestão de Registros EletrônicosO ERM é uma especialização do DMS com a finalidade de gerenciar registros deuma empresa e de seus funcionários (contratos, faturas, registro de reclamações,emails, dentre outros).Sistema de Gestão de Conteúdo Web
  29. 29. 28Um WCMS é uma ferramenta utilizada tanto por pessoas com conhecimento técnicoquanto por pessoas sem conhecimento técnico para a criação de páginas web e dewebsites. Para as pessoas com conhecimento técnico, o WCMS provêprincipalmente criação descentralizada de conteúdo e separação entre layout econteúdo. Porém, os WCMS foram criados com o propósito de provê a pessoas semconhecimento 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 proveeme 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.
  30. 30. 29Sistema de Gestão de Conteúdo EmpresarialAproximadamente 80% das informações/documentos das empresas não seencontram em bancos de dados. Normalmente essas informações estão na formanão-estruturada: e-mails, arquivos digitais, vídeos, sons, documentos em papel oudigitalizados, páginas web, conversas telefônicas, dentre outras. O ECMS surgiucomo um conjunto de ferramentas com o objetivo de gerir esse tipo de conteúdo epossibilitar acesso a ele de forma rápida, online e segura. Os principais objetivos dosECMS são: redução de custos; organização das informações; facilidade de acesso ecompartilhamento das informações; manter a integridade destas; disponibilização doconteúdo através da intranet e internet, facilidade no gerenciamento de conteúdo naweb 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. OECMS possibilita a gestão da informação organizacional, onde quer que ela existaou seja qual for sua forma.De acordo com Williams (2010), Uma ferramenta para ser considerada um ECMSdeve possibilitar a gestão dos principais tipos de conteúdo, além de proverescalabilidade em nível empresarial, suportando uma grande porcentagem dosprocessos de uma empresa que possam ser automatizados.Serão listados abaixo alguns dos principais serviços que um ECMS deve possuir afim 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
  31. 31. 30localização do conteúdo, para que no futuro essa informação seja recuperadabaseada em sua categorização.Indexação: consiste em criar metadados para documentos que foramdigitalizados, de forma que possam ser buscados posteriormente. Aindexaçã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 gerenciadosde acordo com seu tempo de retenção (tempo máximo que precisam sermantidos)Gestão de Email: email é a principal fonte de comunicação em umaempresa, e por isso não devem ser apenas armazenados. Eles devem serclassificados, armazenados e destruídos, ou seja, ter um ciclo de vidacompleto, como qualquer outro tipo de documento.Gestão de Conteúdo Web: consiste na criação, revisão, aprovação epublicaçã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 daempresa gerenciado pelo ECMS.Armazenamento: não confundir com Repositório. Armazenamento é ummeio físico, onde o repositório reside. Exemplos são (discos ópticos, fitasmagnéticas e RAID). Proveem opções tanto para armazenamento onlinequanto offline.
  32. 32. 31Integração de Conteúdo: possibilita aos diferentes tipos de conteúdo aserem tratados como se estivessem em um mesmo repositório.Backup: faz backup dos dados em diversos formatos e locais, a fim deprevenir a perda de dados em caso de perda do repositório atual.Busca: é uma das principais funcionalidades de qualquer ECMS. Poispermite a busca e recuperação do conteúdo previamente inserido.Syndication: distribuição do conteúdo para reuso e integração em outrosconteú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 dedeterminado meio, como impressão, email, website, portal, RRS feeds, etc.Segurança: restringe acesso ao conteúdo, tanto durante a criação egerenciamento, 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 tomadade decisão e criação de conteúdo por essa equipe.
  33. 33. 323. O CMS JOOMLA! 3.1. O QUE É JOOMLA!Joomla! é um bem conceituado CMS que permite criar websites de forma fácil erápida. A relação bem equilibrada entre extensibilidade, quantidade de recursos efacilidade de utilização fez com que ele se tornasse um dos WCMS mais popularesdentre os existentes. Ele além de ser uma ferramenta gratuita, é também opensource, liberado sob a licença General Public License (GPL), o que proporcionaliberdade para desenvolver extensões conforme a necessidade. Apesar de aferramenta primariamente instalada ser totalmente gratuita, algumas extensõespodem 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 bemestruturado, 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 epublicações online, E-commerce, Aplicações para o governo, websites parapequenas empresas, websites para não profissionais, portais baseados emcomunidades, 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 MamboCMS, que se tornara detentora dos direitos do MOS, podendo a qualquer momento
  34. 34. 33vendê-lo a outra empresa ou comercializá-lo de forma não gratuita. Como o MOSera open source, seus desenvolvedores então resolveram dar continuidade aoprojeto, que já obtivera bastante sucesso, ficando inclusive mais famoso que seuirmão de código fechado, Mambo CMS. Eles então criaram um grupo chamadoOpen Source Matters, que foi o responsável pela criação do projeto Joomla! Emprimeiro de setembro de 2005, com o objetivo de dar continuidade à crescentepopularidade do MOS, tanto em relação aos usuários quanto em relação àcomunidade de desenvolvedores. O nome “Joomla!” tem origem africana e pode sertraduzido como “todos juntos”, expressão que faz alusão ao fato dele ser totalmentede código aberto, o que possibilita que ele seja desenvolvido e mantido por váriaspessoas 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 suaestrutura, 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 trouxetantas diferenças em sua estrutura em relação à estrutura da versão 1.5; quantotrouxera a versão 1.5 em relação à 1.0, que era apenas o MOS com o nomemodificado. A versão 1.6 trouxe, no entanto, uma gama muito grande de melhoriastanto 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: melhoriada Access Control List (ACL), aumentando a flexibilidade e a personalização nogerenciamento de usuários, grupos e controle de acesso; novas funções de SearchEngine Optimization (SEO); melhoria no gerenciador de mídias e melhorias nogerenciador 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)
  35. 35. 34 3.3. CONHECENDO O JOOMLA! 3.3.1. Requisitos de instalaçãoO 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 doJoomla! é: Apache (servidor web) versão 2.x PHP (interpretador de código) versão 5.2 MySQL (banco de dados) versão 5.0.4Também pode ser utilizado o servidor da Microsoft Microsoft IIS: versão 7 MySQL: versão 5.1Observaçõ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.
  36. 36. 35 3.3.2. ArquiteturaA Figura 3 apresenta a arquitetura do Joomla! Figura 3 _ Arquitetura do Joomla! Fonte: Joomla! (2011).Segundo Joomla! (2011 O Joomla! 1.6 pode ser descrito como possuindo uma 1),estrutura de três camadas: camada de Aplicação, camada de Extensão e camada deFramework.
  37. 37. 36Na camada de Extensão (ver item 3.3.3) estão os pacotes que estendem ocomportamento padrão do Joomla!. Algumas extensões já vêm por padrão nainstalação, enquanto outras podem ser adicionadas posteriormente.A camada de Aplicação consiste de aplicações que possuem um comportamento emcomum. Elas possuem uma função essencial para o funcionamento do Joomla!. Aversão 1.6 possui três dessas aplicações: instalação, administração (responsávelpelo backend), e site (responsável pelo frontend). Na versão 1.5 havia também aaplicação XML-RPC, que suportava administração remota do website, porém naversã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õesUma das principais razões para a popularidade do Joomla! é a enorme variedade deExtensõ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 asvárias disponíveis, se adéqua melhor às suas necessidades. Isso torna o Joomla! opreferido tanto para usuários quanto para desenvolvedores, em se tratando de CMSpara portais. (RAHMEL, 2007)
  38. 38. 37Uma Extensão é um termo genérico que consiste em um pacote que pode seradicionado ao seu website Joomla!, incluindo novas funcionalidades ousimplesmente 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. Diantedisso, 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 queestende o core do Joomla!, podendo portanto já vir como padrão na instalação ouser 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!, designaestrutura 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 ePackage. Algumas extensões são muito simples, enquanto outras são maiscomplexas e exigem maior tempo e cuidado no desenvolvimento. Apresentar-se-ãoa seguir cada um desses tipos.LinguagensLinguagens (Languages) são o tipo de extensão mais básico do Joomla!. São tãosimples que podem ser implementadas por uma pessoa sem conhecimentos deprogramação, devendo apenas possuir o conhecimento necessário para a tradução.Há inclusive uma extensão (Translation manager extension) que ajuda na criaçãodos arquivos necessários. As linguagens podem ser empacotadas de duasmaneiras, como pacotes do core (pacotes que já vêm inclusos na instalação doJoomla!) ou pacotes de extensão. As Linguagens são uma ferramenta essencialpara a internacionalização do Joomla!. Elas possibilitam o número oficial atual de 64traduções, que fazem do Joomla! O CMS com o maior número de traduçõesatualmente. (JOOMLA!, 2011)O Joomla! utiliza a codificação de caracteres UTF-8, isso permite que tanto seuconteúdo quanto seus dados sejam traduzidos para qualquer língua, pois permite autilização de qualquer conjunto de caracteres.
  39. 39. 38TemplateUm Template é basicamente o design do website, é um tipo de extensão quemodifica a maneira como as páginas e outras extensões do website sãoapresentadas. Há dois tipos de Templates: de front-end, que modifica a interface dousuá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 lugaresdiferentes do website.PluginPlugins são extensões que se integram com a camada mais baixa do Joomla!, aFramework Layer. Eles operam entre o usuário e a aplicação, e executam algumaação ao interceptarem eventos ocorridos. Isso significa que tanto o Joomla! corequanto outras extensões podem lançar algum evento, que será “ouvido” por um oumais plugins, que dependendo do evento decidirá se deverá ou não executar umaação. No Joomla! 1.0 havia um equivalente ao Plugin,, eram os Mambots, quefuncionam da mesma forma que os Plugins. A diferença entre eles é somenteestrutural, 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.
  40. 40. 39 Figura 4 _ Funcionamento de um Plugin Fonte: Rahmel (2007, p. 267).O Plugin pode interceptar os dados de output e modificá-los antes de enviá-los para loso usuário. No sentido oposto, ele intercepta os dados do usuário e pode transform transformá-los antes de enviá-los para o repositório. losMóduloMódulo é uma extensão leve e utilizada na formação da página. Pode ser utilizadaem vários componentes, e também pode haver muitos módulos em um único árioscomponente. Os módulos são associados a componentes, dessa forma serãorenderizados apenas para os componentes a que forem associados. Muitos pacotesde extensão utilizam mais de uma extensão, um exemplo é o pacote de votação extensão,(poll), que utiliza um Módulo para apresentar a interface com o usuário, e um ),Componente para permitir configuração e administração.
  41. 41. 40ComponenteComponentes podem algumas vezes ser confundidos com Módulos, porém não édifícil distingui-los. Componentes possuem mais capacidade de interação que osMó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 maiscomplexos e contém Módulos. Por serem mais complexos, consequentemente sãode mais difícil implementação.Os componentes geralmente estão associados a um item de menu. Desta formaquando um usuário clica em um menu no Joomla! ele será direcionado para umcomponente, que na maioria das vezes exibirá uma página inicial para interaçãocom 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 deextensão no mesmo arquivo de instalação. 3.3.4. Frontend e BackendUm 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 é
  42. 42. 41permitido realizar tarefas administrativas como gerenciar extensões eusuários.Backend: parte administrativa do site, que é acessada por um endereçoespecial. Permite o gerenciamento de usuários, extensões e de opções dosite. No backend é onde a estrutura do website é definida, enquanto nofrontend será permitido somente criar e manter conteúdo que preencha estaestrutura. (SCARATE, 2007)
  43. 43. 424. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA!Este capítulo tem como objetivo apresentar um passo a passo para se desenvolverum componente internacionalizável (ver seção 4.3) para o Joomla! utilizando omodelo arquitetural Model View Controller (MVC).Apresentar-se-ão técnicas e boas práticas que devem ser seguidas na construçãode um componente para o Joomla!. Além disso será explanado sobre a estruturaque ele provê para facilitar esse desenvolvimento. Todos os detalhes deimplementaçã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 deaprofundamento e complemento do conteúdo teórico adquirido através das fontestextuais. Além disso, ele será utilizado como exemplo na apresentação da teoria dodesenvolvimento de componentes para o Joomla!.O Questões é um componente que tem como funcionalidades o cadastro dequestões de múltipla escolha, cadastro de simulados, e resolução de simulados. Osdiagramas abaixo apresentam os principais fluxos do Componente, bem como odetalhamento desses fluxos.A Figura 5 apresenta os casos de uso do Questões, que são as funcionalidades queo Componente provê: Cadastro de Questão (que deve ser precedida do cadastro deuma prova), Cadastro de Simulado e Resolução de Simulados.
  44. 44. 43 Figura 5 _ Diagrama de Casos de Uso do componente Questões Fonte: Bruno Queiroz.A Figura 6 detalha a funcionalidade mais complexa do componente, o cadastro dequestões.
  45. 45. 44 Figura 6 _ Diagrama de Atividades (Cadastrar Questão) Fonte: Bruno Queiroz.A Figura 1Figura 7 detalha a funcionalidade de cadastro de simulados.
  46. 46. 45 Figura 7 _ Diagrama de Atividades (Cadastrar Simulado) Fonte: Bruno Queiroz.A Figura 8 detalha a funcionalidade de resolução de simulados.
  47. 47. 46 Figura 8 _ Diagrama de Atividades (Resolver Simulado) Fonte: Bruno Queiroz.Apresentar-se-ão abaixo as telas relativas às funcionalidades do Questões.
  48. 48. 47A Figura 9 apresenta a tela de listagem de provas, sendo que cada prova contémvárias questões. Pode- -se cadastrar uma nova prova, editar ou excluir uma jáexistente. Além disso é possível listar provas de acordo com um filtro. Figura 9 _ Tela do componente Questões (Listagem de Provas Provas) Fonte: Bruno Queiroz.
  49. 49. 48A Figura 10 representa a funcionalidade de cadastro de questões. Esta é afuncionalidade mais complexa, onde se deve primeiro cadastrar uma prova, eposteriormente 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. Nestecomponente, 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, comoquestão de múltipla escolha, questão de múltipla escolha com assertivas ousomente texto (para textos que são utilizados por várias questões). Além disso, nãohá limites para a quantidade de itens ou de assertivas, podendo-se adicioná-los ouexcluí-los conforme a necessidade. O componente também possibilita que sejaminseridos 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.
  50. 50. 49 Figura 10 _ Tela do componente Questões (Cadastro de Questões) (Cadastro Fonte: Bruno Queiroz.A Figura 11 apresenta a funcionalidade de listagem de simulados, onde é possívellistar simulados conforme um filtro inserido, criar um novo simulado, excluir umsimulado existente ou ir para a tela de r resolução de simulados.
  51. 51. 50 Figura 11 _ Tela do componente Questões (Listagem de Simulados Simulados) Fonte: Bruno Queiroz.A Figura 12 representa a funcionalidade de cadastro de simulado. Nesta tela épossível cadastrar um simulado, que conterá as questões que se adequarem aosrequisitos determinados no formulário.
  52. 52. 51 Figura 12 _ Tela do componente Questões (Cadastro de Simulado) (Cadastro Fonte: Bruno Queiroz.A Figura 13 representa a funcionalidade de Resolução de simulados. Nesta tela épossível resolver as questões dos simulados cadastrados No momento em que a cadastrados.questão é resolvida o sistema automaticamente apresenta se a questão foi resolvidacorretamente ou não. Ao fechar se a tela, as informações continuam salvas, e ao fechar-seabri-la novamente as questões que já foram resolvidas continuarão como resolvidas lae com suas respectivas respostas e indicação de erro ou a acerto.
  53. 53. 52 Figura 13 _ Tela do componente Questões ( (Resolução de Simulado) Fonte: Bruno Queiroz. 4.2. MODEL-VIEW VIEW-CONTROLLERO Model View Controller (MVC) é um padrão de arquitetura de software que divide aestrutura da aplicação em três camadas, modelo (model), visão ( ), (view) e controle
  54. 54. 53(controller). Cada uma dessas camadas possui responsabilidades distintas. Elas sãoseparadas de forma que a parte do sistema responsável pelo domínio e acesso abanco 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 essasduas 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 devisão, inclusive trocar totalmente o tipo de visualização, sem necessitar fazermudanças no Modelo. O contrário também acontece. Quando for preciso fazermudança na forma de pesquisar dados ou no acesso aos dados, por exemplo, semudar a fonte de dados, será preciso mudar apenas o Modelo, sendo que a camadade 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 modelaa percepção que se tem do mundo real) dos elementos que compõem aapresentação do software. Ele explica também que os objetos de domínio devemfuncionar independentemente dos objetos da apresentação, sem ter conhecimentodestes, além disso devem suportar múltiplas camadas de visão.A Figura 14 apresenta a estrutura do MVC
  55. 55. 54 Figura 14 _ Estrutura do MVC Fonte: Bruno Queiroz.Tanto a Visão quanto o Controle possuem acesso ao Modelo, e o Controle possui isão odelo,acesso à Visão. A Visão e o Modelo podem lançar eventos que são interceptados isãopelo Controle. Há no entanto variações dessa arquitetura, com pequenas ontrole.modificações.ModeloO Modelo é a camada que encapsula o acesso aos dados e a lógica de negócio da oaplicação. Ele provê rotinas para manipular os dados e é responsável pelo acesso a dadosestes, independentemente da forma como estão armazenados. (ORACLE, 2011) endentemente armazenados.Visão
  56. 56. 55Visão é a camada responsável por apresentar os dados do modelo de maneira quepossibilite interação com humanos, e servir de porta de entrada para dados inseridospor humanos, como formulários, por exemplo. Pode haver diferentes Visões para ummesmo Modelo e Controle. As Visões devem ser diferentes conforme a necessidadedo usuário de visualizar dados em diferentes formas. Por exemplo, uma aplicaçãopode necessitar de uma Visão para a web e uma Visão para desktop. Nesse casodeverá ter duas Visões para o software, e a camada de Controle será encarregadade decidir qual das duas utilizar. (ORACLE, 2011)ControleO Controle, ou Controlador, é responsável por responder às ações do usuário. Eleverifica qual método deve ser utilizado e o aciona no Modelo. Depois passa oModelo para a Visão para que ela apresente os dados, ou passa apenas os dadospara 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 otermo “internationalization” onde são utilizadas sua primeira e última letra mais onúmero 18, que é a quantidade de letras intermediárias) é a criação e odesenvolvimento de um produto, aplicação ou conteúdo de um documento quepermita a localização (adaptação a determinada cultura ou idioma) fácil parapúblicos-alvo que variam em cultura, região ou idioma. Não se deve confundirlocalização com internacionalização. Enquanto a localização é o ato de modificar umconteúdo para que ele se torne apresentável a pessoas de determinada cultura eidioma, a internacionalização é apenas modificar o software para que ele seja defácil localização.O Joomla! é totalmente internacionalizado e ainda provê suporte à fácilinternacionalização de componentes de terceiros.
  57. 57. 56 4.4. O JOOMLA! FRAMEWORKUm framework é uma estrutura reutilizável dentro de uma aplicação. No Joomla! oframework consiste em uma camada completa, e é representado por sua ApplicationPrograming Interface (API). Sua API consiste em um conjunto de classes que estãoseparadas 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 classesnotáveis, apesar de todas serem importantes. São elas:JObjectJObject é a classe básica para quase todas as outras classes do Joomla!Framework. Ela é abstrata, portanto provê somente interface em vez defuncionalidade.JApplicationÉ a superclasse das classes da camada de Aplicação. Ou seja, toda aplicação noJoomla! 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 suainstalação por motivos de segurança), Administração (backend) e Site (frontend).JModel, JView e JControllerSão classes abstratas que proveem as funcionalidades básicas para as classes decada uma das camadas do padrão MVC. É extremamente recomendado que oscomponentes sejam desenvolvidos utilizando-se essa arquitetura, e portanto,estendendo essas três classes.
  58. 58. 57 4.5. DESENVOLVENDO O COMPONENTEO código do Joomla! foi projetado para facilitar o reuso e a extensibilidade, levando odesenvolvedor a utilizar uma arquitetura bem projetada de maneira automática. Seuframework tira do desenvolvedor várias responsabilidades que não poderiam serdeixadas de fora do componente, mas que deixariam o desenvolvimento maiscomplicado e demorado, caso o desenvolvedor tivesse que se preocupar com elas.Algumas dessas responsabilidades são, dentre outras, ACL (questões de segurançae controle de acesso), internacionalização; o template da aplicação, com seusmenus, rodapé, cabeçalho, dentre outros; e SEO. (JOOMLA!, 2011)Uma característica muito importante do framework do Joomla! é que ele utiliza-se doparadigma de desenvolvimento chamado Convention over Configuration(Programação por Convenção, ou CoC), igualmente a outros frameworks webfamosos, como o Ruby on Rails e o Grails. Segundo Neto (2011), o CoC é umparadigma que visa a diminuir a quantidade de decisões que o desenvolvedorprecisa 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 deconfiguração. No Joomla!, os nomes e localização dos arquivos, bem como nomesdas 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 deum componente para Joomla! é a convenção de nomenclatura. Como já foi ditoneste capítulo, o Joomla! utiliza CoC como forma de garantir um desenvolvimentomais rápido e garantir padronização entre diversos componentes desenvolvidos pordiferentes pessoas. Serão apresentadas agora as convenções de nomenclatura e deestrutura de arquivos utilizada pelo Joomla! 4.5.1. Convenções de codificação
  59. 59. 58Convenções de nomeação e estrutura de pastasAntes de tudo é importante salientar que o framework do Joomla! é bastanteflexível, portanto não é obrigatório seguir as convenções adotadas por ele.Porém seguir estes padrões é altamente recomendado, pois melhora alegibilidade e a manutenibilidade do código. Será apresentada abaixo a estruturado componente Questões, seguida por um detalhamento das convençõesseguidas por este componente.
  60. 60. 59 Figura 15 _ Estrutura de diretórios do componente Questões Fonte: Bruno Queiroz.A primeira convenção a ser seguida é o nome da pasta que contém ocomponente. Esta pasta p sta deve ter a seguinte nomenclatura:components/com_{nomedocomponente} onde components é a pasta quecomponents/com_{nomedocomponente},contém todos os componentes do font-end do Joomla!. Então no caso do .componente Questões, deve ficar components/com_questoes components/com_questoes.
  61. 61. 60Todo componente deve ter um ponto de entrada (entry point). Como o nomediz, esse arquivo deve ser o ponto de entrada de toda requisição aocomponente. É nele onde serão tomadas algumas decisões preliminares,como por exemplo, qual o controlador que será utilizado. O nome do entrypoint deve seguir o seguinte padrão:{componente}/{nomedocomponente}.php, que deverá ficar, no caso doQuestões, com_questoes/questoes.php.index.html: não faz parte de nenhuma convenção, mas é aconselhávelcolocar esse arquivo em todos os diretórios do componente, a fim de prevenirque usuários maliciosos tentem fazer uma listagem dos arquivos e pastascontidos no diretório do Joomla!. Essa listagem é realizada automaticamentepelo servidor web Apache, quando da falta de um arquivo index.html.controller.php: é o controlador padrão do componente. Deve conter umaclasse com o seguinte padrão de nomeação:{NomeDoComponente}Controller, que no nosso caso ficaráQuestoesController. Esta classe deve estender a classe baseJController.A pasta tables contém classes que representam uma tabela de banco dedados do componente. Cada arquivo que represente uma tabela deve ter seunome seguindo nomenclatura: {nomedatabela}.php, e o nome da classedeve ser JTable{NomeDaTabela}. Além disso, deve estender de JTable.A pasta models contém as classes que representam o modelo docomponente. Essas classes são responsáveis por acessar o banco de dadostanto para pesquisar dados quanto para realizar ações, como salvar, editar,listar, etc. Os arquivos do modelo devem representar uma view, e seu nomedeve ser igual ao da view que representam. Sua classe deve ter a seguintenomenclatura: {NomeDoComponente}Model{NomeDoModel}, e devemestender a classe JModel. No momento da requisição, o framework relacionaao controlador um modelo com o mesmo nome da visão atual, se odesenvolvedor tentar criar outro model nesse momento, não será possível a
  62. 62. 61menos que especifique via código qual o modelo que deverá ser criado paratal visão.A pasta controllers contém controladores adicionais para o componente,caso o desenvolvedor queira ter mais controladores além do padrão. Elesdevem conter o padrão de nomeação: {nomedocontrole}.php e sua classedeve conter o padrão{NomeDoComponente}Controller{NomeDoControlador} e deve estenderJController. O fluxo será direcionado para o controlador cujo nome sejaigual ao valor da variável controller presente na requisição. Caso a variávelcontroller não exista ou não possua valor, o fluxo será direcionado para ocontrolador padrão. Durante o desenvolvimento do Questões, observou-seque criar um controlador para cada página é o ideal, pois melhora alegibilidade do código, separando-o em várias partes; e possibilita a utilizaçãodas ações padrão do Joomla! (save, update, delete, etc) para cada página docomponente.A pasta views deve conter as diferentes visões do componente. Onde cadavisã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
  63. 63. 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çãoO Joomla! também possui variáveis padrão que devem ser enviadas na requisiçãocomo forma de acessar um componente e escolher a página ou controlador a seracessado, ação a ser realizada, e outras opções. A lista abaixo apresenta todas asvariáveis de requisição padrão do Joomla! que foram utilizadas durante odesenvolvimento do componente ou que tomou-se conhecimento durante estetrabalho.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.
  64. 64. 63 4.5.2. CodificaçãoAgora que já se tem a teoria para a criação da estrutura do componente, serãoapresentadas técnicas para a codificação de um componente para Joomla!, divididaspor arquivo, porém incluindo apenas os arquivos e partes de código relevantes parao completo entendimento do processo de desenvolvimento. ntendimentoArquivo questões.php Figura 16 _ Arquivo questoes.php (entry point do componente) Fonte: Bruno Queiroz.
  65. 65. 64O arquivo com_questoes/questões.php é o ponto de entrada do componente, issosignifica 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çãodefined(‘_JEXEC’) retornar um valor falso, significa que alguém tentou acessar ocomponente 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 dalinha 5 faz um include do arquivo controlador padrão. A funçãoJPATH_COMPONENT, ainda na linha 5, é uma constante provida pelo Joomla! quepossui o caminho para o componente, desde que este utilize as convenções deestrutura e nomeação do Joomla!. No caso do Questoes, o valor deJPATH_COMPONENT édiretorioDeInstalacaoDoJoomla/components/com_questoes. A constante DStambém é inicializada pelo Joomla! e contém o valor da barra separadora dediretórios, que pode ser “/” ou “”, dependendo do Sistema Operacional utilizado.Essa constante livra o desenvolvedor de ter que fazer a verificação de qual oSistema Operacional em que o Joomla! está instalado. É aconselhável sempreutilizar 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!, aoinvé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. Avariá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 utilizarJRequest::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 formaque impossibilite a injeção de código ou injeção de SQL por parte de usuários malintencionados. Caso a variável controller possua algum valor, o controladorinicializado será do arquivo components/controllers/nomeDoControlador, aoinvés do controlador padrão.
  66. 66. 65A instrução da linha 21 obtém o valor da variável task da requisição Essa variável requisição.representa a tarefa (função) que será executada pelo controlador. Caso nãocontenha valor, será á executada a task padrão do controlador, que éJController::display().Arquivo simulado.php Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado) Fonte: Bruno Queiroz.
  67. 67. 66O arquivo simulado.php contém a classe controladora da página de listagem deSimulado e da página de cadastro de Simulado. Como ele não é o controladorpadrão do componente, deve estar emcom_questoes/controllers/simulado.php, e sua classe deve ter anomenclatura {NomeDoComponente}Controller{NomeDoControlador}, conformedescrito no item 4.5.1.O controlador tem a função tanto de controlar a navegação entre páginas docomponente, quanto de delegar ao modelo tarefas solicitadas pela visão. Ele possuifunções, que o Joomla! trata como tasks. Portanto as funções save e cancelcontidas no arquivo são tasks, que realizam determinada tarefa. Por exemplo, paraexecutar a função save do controlador Simulado do componente Questoes, a URLdeve ser a seguinte:index.php?option=com_questoes&controller=simulado&task=save.Na função save, na linha 29, a instrução obtém o model para o controladorSimulado. A função getModel(‘nomeDoModelo) automaticamente procura o modelocujo nome é {NomeDoComponente}Model{NomeDoModelo}. Mas só obtém omodelo 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 denome {NomeDoComponente}Model{NomeDoControlador}, que no caso doQuesões é QuestoesModelSimulado.Na linha 34 a instrução JRequest::setVar(‘id_simulado’, $id_simulado), criauma variável chamada id_simulado na requisição com valor igual ao valor davariável $id_simulado. Na linha 35 a instrução inicializa a variável view na requisiçãocom o valor ‘simulados’. Isso faz com que o Joomla! redirecione para a visãoSimulados após o retorno dessa função.Arquivo view.html.php
  68. 68. 67 Figura 18 _ Arquivo view.html.php da visão Simulado Fonte: Bruno Queiroz.O arquivo view.html.php representa determinada visão. Sua função é obter osdados do modelo e pass passá-los para um template, por meio do método ,JView::assignRef. É importante salientar que o nome da variável atribuída aotemplate por meio de JView::assignRef não pode conter under underline em seu início,como por exemplo JView::assignRef(‘_variavel’, $variavel). A funçãodisplay deste arquivo é a função padrão que será executada pela função display do 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 por ela, que por padrão será o arquivo com nomenclatura{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default.php,{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default.php porém é
  69. 69. 68posssível setar um arquivo diferente como template através da variável derequisição layout.Arquivo de templateO arquivo de template contém a lógica da apresentação, é nele que se encontram asreferências a arquivos de estilo ou JavaScript, códigos JavaScript códigos de estilo cript,CSS e código de marcação HTML. Eles acessam os dados atribuídos pela visãoutilizando $this->nomeDaVariavel. Por exemplo, se a visão passa um simulado >nomeDaVariavel ,para o template, ele o acessa da seguinte forma: $this->simulado. O principal , >simuladoobjetivo da existência dos templates, é possibilitar que uma mesma visão possautilizar templates diferentes conforme a necessidade, a fim de poder modificar aforma como os mesmos dados são apresentados, sem precisar mudar de visão. sãoArquivo do modelo Figura 19 _ Arquivo simulados.php (modelo de simulados) Fonte: Bruno Queiroz.Ao arquivo simulados.php contém uma classe que estende de JModelList, porémela continua estendendo JModel indiretamente, pois JModelList é subclasse deJModel. A classe JModelList é também um modelo, mas provê funcionalidades
  70. 70. 69extras, como facilitar a obtenção dos filtros de determinada pesquisa para obter osdados no banco, listagem de múltiplos itens e facilitar na paginação de uma lista deitens. Figura 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 umapesquisa. A instrução $this->getUserStateFromRequest() obtém o valor davariável da requisição e salva na sessão, a fim de que esses valores não se percam sessão,entre uma requisição e outra e outra.Há ainda o método getListQuesry(), que retorna uma consulta que será utilizadapara buscar a lista a ser exibida, e será utilizada pela paginação sempre que forrequisitada uma nova página desta. Os filtros salvos durante o métodopopulateState() serão utilizados nesse método como filtros na consulta.Arquivos de tabela
  71. 71. 70 Figura 21 _ Arquivo tables/simulado.php Fonte: Bruno Queiroz.São arquivos que represent representam uma tabela no banco de dados, e facilitam todas as aoperações feitas no banco sobre esta tabela. Devem ter a seguinte nomenclatura: emJTable{nomeDaTabela} e devem estender a classe JTable. Eles devem estar .localizados no caminho {nomeDoComponente}/tables/{nomeDoArquivo}.php {nomeDoComponente}/tables/{nomeDoArquivo}.php.Esses arquivos contêm variáveis que representam cada coluna da tabela e seu presentam tabela,construtor recebe o nome da tabela e o nome da sua chave primária. Como se podever na linha 26, o nome da tabela começa com o prefixo “#__”. Esse prefixo é prefixoconvertido automaticamente pelo Joomla! para o prefixo utilizado pelas tabelas no Joomla!banco de dados. Isso é necessário pois toda tabela de uma determinada instalaçãodo Joomla! possui um mesmo prefixo, a fim de evitar incompatibilidad entre incompatibilidadeinstalações diferentes em um mesmo banco. No caso do Questões, que utiliza o .
  72. 72. 71prefixo 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 internacionalizadoO Questões utiliza uma extensão do tipo Linguagem para fins deinternacionalizaçã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 problemascom sua utilização é necessário que o banco de dados ofereça suporte a estacodificação. Portanto, é aconselhável utilizar o banco de dados MySQL a partir daversã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 eum para a instalação. Para criar um pacote de Linguagem para o frontend de umcomponente é necessário uma estrutura como a seguinte:

×