monografia - explorando o desenvolvimento de componentes para o joomla 1.6

FACULDADE 7 DE SETEMBRO - FA7

CURSO GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO

BRUNO QUEIROZ DUARTE

EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6

FORTALEZA – 2011

BRUNO QUEIROZ DUARTE

EXPLORANDO O DESENVOLVIMENTO DE COMPONENTES PARA O JOOMLA 1.6

Monografia apresentada à Faculdade 7

de Setembro como requisito parcial para

obtenção do título de Bacharel em

Sistemas de Informação.

Orientador: Prof. Francisco Ivan de Oliveira, MSc.

FORTALEZA – 2011

DEDICATÓRIA

Dedico este trabalho aos meus queridos pais,

David e Jaqueline, à minha querida esposa,

Nayara, e à minha querida tia, Erineire; que

foram meu porto seguro nos momentos bons e

ruins ao longo dessa trajetória. A eles devo o

sucesso alcançado.

AGRADECIMENTOS

Por trás do “grande passo para a humanidade” houve certamente uma série de sucessos e fracassos, que não foram com ela compartilhados. Por trás deste meu “grande passo”, também houve uma série de sucessos e fracassos, e também superações, porém eu tive a sorte de ter tido sempre pessoas com quem compartilhar os sucessos e com quem chorar os fracassos. Este trabalho é apenas um coroamento da minha trajetória até aqui, trajetória essa que não iniciou na faculdade, mas quando ainda nem sabia “dar passos”. Diante deste “grande passo”, tenho no mínimo o dever de agradecer a todos que de alguma forma contribuíram para ele se concretizasse: A Deus, por ter permitido que eu chegasse até aqui, e por ter me dado a sorte e sabedoria necessária em todos os momentos da minha vida. Aos meus pais, por terem me ensinado o valor da família, por todos os valores que hoje tenho, por terem me educado para ser essa pessoa “do bem” que sou hoje, por serem boas referências para mim; e especificamente à minha mãe, que mesmo com pouco estudo me alfabetizou, pelas historinhas que me contava, e por coisas simples como me falar com entusiasmo que aquele animal correndo na TV era uma lebre ao invés de coelho, me incentivando, mesmo sem querer, a ser uma pessoa curiosa e amante do conhecimento. À minha tia, Erineide, por ter me acolhido em sua casa aqui em Fortaleza, e assim ter me possibilitado concluir esta etapa, por ter me amado como um filho, sempre ficando feliz por cada realização minha; e a seu filho, Marlon, por ter me recebido como um irmão e por ter sempre sido uma boa companhia para mim. À minha esposa, Nayara, por ser minha companheira, sempre tendo paciência comigo nas noites que passei em claro durante este trabalho, e por ter me dado forças para concluí-lo. Aos meus irmãos, David Filho e Daniele, por terem sido sempre uma ótima companhia para mim, por me proporcionarem bons momentos e por estarem do meu lado durante grande parte dessa caminhada. Aos meus professores, desde o jardim até aqui, por terem me guiado e me ajudado na construção do meu conhecimento, e principalmente àqueles que foram além da sala de aula, se preocupando com os problemas pessoais de cada um, e inclusive os meus. Aos meus amigos de Ibaretama: Cícero, Eveton, Getúlio, Ivanzinho, Renato, Tamilles, Umbertinho e Zezinho, por terem sido minha primeira e até agora única turma, e por terem me ensinado o quanto é bom ter uma vida social. A todos os autores, livros, e programas de TV (principalmente os da TV Cultura e TV escola) que foram por algum tempo uma agradável companhia e fonte de conhecimentos e lazer.

Ao PROUNI, por ter possibilitado àquele garoto simples e sem grandes pretensões, que achava que iria morrer sem ao menos ver um computador, a cursar um ensino superior na área de TI. A todos os meus colegas da faculdade, principalmente Beatriz, Gimael, Jeferson, Kete, Lucivaldo e Milliam, por terem estado juntos comigo por praticamente todos esses anos, e por terem compartilhado juntos comigo os bons e os difíceis momentos da faculdade. Ao meu professor orientador, Ivan de Oliveira, por ter me guiado na escolha desse tema, por ter sempre me encorajado durante o desenvolvimento deste trabalho, e por ter levantado minha auto-estima nas vezes em que achei que não conseguiria.

À FA7, por ter sido minha terceira casa durante muito tempo, e por sempre ter me dado a possibilidade de estudar com os melhores professores que há; Ao curso de SI e à coordenação do curso, por sempre estarem do lado dos alunos e por buscarem sempre a melhoria do nosso conhecimento. A muitas outras pessoas que não foram citadas aqui, mas que também tiveram uma parcela de importância neste trabalho, meus sinceros agradecimentos.

RESUMO

Este trabalho surgiu da necessidade de se ter um material completo acerca do

desenvolvimento de componentes para a versão 1.6 do CMS Joomla!, visto que a

documentação encontrada na Internet ainda é bastante vaga e dispersa, e os livros

que tratam desse assunto estão desatualizados, sendo que sua maioria aborda a

versão 1.5 do Joomla!. Este estudo tem o objetivo de ser uma fonte de pesquisa

para desenvolvedores de componentes para o Joomla! 1.6, discorrendo sobre

técnicas e padrões que devem ser seguidos para que se possa desenvolver um

componente com arquitetura robusta e extensível, além de apresentar as facilidades

providas pelo Joomla! 1.6 para o desenvolvimento de componentes.

Palavras-chave: Gestão de Conteúdo. CMS. Joomla!. Componentes. MVC.

Internacionalização.

ABSTRACT

This scientific monograph arose from the need to have a complete stuff about the

development of components to version 1.6 of Joomla!, since the documentation

found on the Internet is still quite vague and scattered, and books dealing with this

subject are outdated, and which mostly deals with version 1.5 of Joomla. This study

aims to be a resource for developers of components for the Joomla! 1.6, discussing

techniques and standards that must be followed so that we can develop a robust and

flexible architecture for the component, and present the facilities provided by the

Joomla! 1.6 for the development of components.

Keywords: Content Management. CMS. Joomla!. Components. MVC.

Internationalization.

LISTA DE ILUSTRAÇÕES

Figura 1 _ Estrutura geral de um CMS ...................................................................... 20

Figura 2 _ Estrutura do Sistema de Coleta ............................................................... 21

Figura 3 _ Arquitetura do Joomla! ............................................................................. 35

Figura 4 _ Funcionamento de um Plugin ................................................................... 39

Figura 5 _ Diagrama de Casos de Uso do componente Questões ........................... 43

Figura 6 _ Diagrama de Atividades (Cadastrar Questão) .......................................... 44

Figura 7 _ Diagrama de Atividades (Cadastrar Simulado) ........................................ 45

Figura 8 _ Diagrama de Atividades (Resolver Simulado) .......................................... 46

Figura 9 _ Tela do componente Questões (Listagem de Provas) ............................. 47

Figura 10 _ Tela do componente Questões (Cadastro de Questões) ....................... 49

Figura 11 _ Tela do componente Questões (Listagem de Simulados) ...................... 50

Figura 12 _ Tela do componente Questões (Cadastro de Simulado) ........................ 51

Figura 13 _ Tela do componente Questões (Resolução de Simulado) ..................... 52

Figura 14 _ Estrutura do MVC ................................................................................... 54

Figura 15 _ Estrutura de diretórios do componente Questões .................................. 59

Figura 16 _ Arquivo questoes.php (entry point do componente) ............................... 63

Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado) ............. 65

Figura 18 _ Arquivo view.html.php da visão Simulado .............................................. 67

Figura 19 _ Arquivo simulados.php (modelo de simulados) ...................................... 68

Figura 20 _ Arquivo simulados.php (método populateState) ..................................... 69

Figura 21 _ Arquivo tables/simulado.php .................................................................. 70

Figura 22 _ Estrutura de um pacote de Linguagem .................................................. 72

Figura 23 _ Arquivo ini (arquivo de tradução)............................................................ 73

LISTA DE ABREVIATURAS E SIGLAS

ACL Access Control List

CMS Content Management System

CoC Convention Over Configuration

DAM Digital Asset Management System

DMS Document Management System

ECMS Enterprise Content Management System

ERM Electronic Records Management

ERP Enterprise Resource Planning

GC Gerenciamento de Conteúdo

GPL General Public License

HTML HyperText Markup Language

LAN Local Area Network

OCR Optical Character Recognition

MOS Mambo Open Source

SEO Search Engine Optimization

WAN Wide Area Network

WCMS Web Content Management System

SUMÁRIO

DEDICATÓRIA ............................................................................................................ 2

AGRADECIMENTOS .................................................................................................. 3

RESUMO..................................................................................................................... 5

ABSTRACT ................................................................................................................. 6

LISTA DE ILUSTRAÇÕES .......................................................................................... 7

LISTA DE ABREVIATURAS E SIGLAS ...................................................................... 8

SUMÁRIO.................................................................................................................... 9

1. INTRODUÇÃO .................................................................................................... 11

1.1. OBJETIVO GERAL ...................................................................................... 12

1.2. OBJETIVOS ESPECÍFICOS ........................................................................ 13

2. SISTEMA DE GESTÃO DE CONTEÚDO ........................................................... 14

2.1. O QUE É CONTEÚDO ................................................................................. 14

2.2. GESTÃO DE CONTEÚDO ........................................................................... 15

2.3. BENEFÍCIOS DA GESTÃO DE CONTEÚDO .............................................. 15

2.4. SISTEMA DE GESTÃO DE CONTEÚDO .................................................... 16

2.4.1. Principais funcionalidades de um CMS ................................................. 16

2.4.2. Estrutura de um CMS ............................................................................ 19

2.4.3. Tipos de CMS ........................................................................................ 26

3. O CMS JOOMLA! ............................................................................................... 32

3.1. O QUE É JOOMLA!...................................................................................... 32

3.2. HISTÓRICO DO JOOMLA! .......................................................................... 32

3.3. CONHECENDO O JOOMLA! ....................................................................... 34

3.3.1. Requisitos de instalação ........................................................................ 34

3.3.2. Arquitetura ............................................................................................. 35

3.3.3. Extensões .............................................................................................. 36

3.3.4. Frontend e Backend .............................................................................. 40

4. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA! ...................... 42

4.1. O COMPONENTE “QUESTÕES”................................................................. 42

4.2. MODEL-VIEW-CONTROLLER .................................................................... 52

4.3. INTERNACIONALIZAÇÃO (I18N) ................................................................ 55

4.4. O JOOMLA! FRAMEWORK ......................................................................... 56

4.5. DESENVOLVENDO O COMPONENTE ....................................................... 57

4.5.1. Convenções de codificação ................................................................... 57

4.5.2. Codificação ............................................................................................ 63

4.5.3. Tornando o Questões internacionalizado .............................................. 71

5. CONSIDERAÇÕES FINAIS ................................................................................ 75

BIBLIOGRAFIA ......................................................................................................... 76

11

1. INTRODUÇÃO

Segundo Batista (2007), o conteúdo disponível na internet vem crescendo a cada

dia. Além disso, há também o aumento da necessidade de se ter conteúdo atual e

de natureza colaborativa, onde se possa comentá-lo e até mesmo modificá-lo. As

empresas cada vez mais estão buscando ter uma presença na web, pois isso é

fundamental para que sua marca sobreviva no mercado atual. Tal necessidade faz

parte do conceito de “Darwinismo Digital”, que segundo Romaní e Kuklinski (2007), é

o princípio que explica que no mercado de aplicações web sobrevivem apenas os

mais adaptados. Outro fator responsável pelo aumento da quantidade de conteúdo

na web e da necessidade do dinamismo de tal conteúdo são os próprios usuários da

web. Impulsionados pelos mais diversos objetivos esses usuários necessitam de

ferramentas que os auxiliem na publicação de conteúdo de forma rápida e

transparente, sem a necessidade de conhecimentos de protocolos ou de linguagens

de programação/marcação relacionados à web.

Tanto a necessidade das empresas quanto as necessidades pessoais dos

indivíduos de manter conteúdo de forma eletrônica podem ser satisfeitas com a

utilização de ferramentas chamadas Content Management Systems (CMS), em

português, Sistemas de Gerenciamento de Conteúdo, ou Sistemas de Gestão de

Conteúdo, que facilitam o gerenciamento dos diversos tipos de conteúdo existentes.

Segundo W³Techs (2011), Dentre os vários CMS, um dos mais populares é o

Joomla!, sendo utilizado por 10,5% dos sites que utilizam CMS. Além disso, segundo

Idealware (2011) o Joomla! é o CMS que possui o melhor equilíbrio entre

flexibilidade e facilidade de uso, o que o torna um dos CMS mais cotados para vários

tipos de websites. Parte dessa flexibilidade deve-se às extensões providas pelo

Joomla!, especialmente a do tipo Componente, que possibilitam estender as suas

funcionalidades básicas de maneira simples e rápida. Apesar da vasta

documentação encontrada na web referente à utilização do CMS Joomla!, há certa

dificuldade em se encontrar material referente ao desenvolvimento de extensões,

sendo o site oficial do Joomla! um dos poucos lugares onde se pode encontrar

documentação mais aprofundada. Apesar de aprofundada, a documentação oficial

12

do Joomla! contém algumas informações importantes para o desenvolvimento que

encontram-se dispersas por várias páginas às vezes difíceis de se encontrar. Além

disso, essa documentação não contempla certas peculiaridades que podem

aparecer durante o desenvolvimento e que às vezes são resolvidas somente através

dos fóruns de discussão do Joomla!

Diante dessa crescente necessidade da utilização de CMS em websites, e da

grande parcela de adoção do CMS Joomla! como tecnologia para esses websites,

fazem-se necessárias novas fontes de documentação sobre o desenvolvimento de

extensões, que venham a trazer uma perspectiva diferente para o desenvolvimento

de componentes; das encontradas na documentação oficial.

Este trabalho é dividido em quatro capítulos. O segundo capítulo aborda os

Sistemas de Gestão de Conteúdo, explicando inicialmente o que é conteúdo, depois

explica o que é gestão de conteúdo e seus benefícios, e depois, com esses

conceitos já construídos, explica o que é Sistema de Gestão de Conteúdo,

explanando sobre suas principais funcionalidades, sua estrutura e os principais tipos

de CMS. O terceiro capítulo apresenta uma visão do CMS Joomla!, apresentando

um breve resumo do seu histórico e depois aprofunda-se um pouco mais, explicando

seus requisitos, arquitetura e suas extensões. O quarto capítulo é o principal capítulo

deste trabalho, onde é explorado o desenvolvimento de componentes para a versão

1.6 do Joomla!.

1.1. OBJETIVO GERAL

Explorar o desenvolvimento de componentes para a versão 1.6 do Joomla!,

apresentando a arquitetura padrão que deve ser adotada no componente, padrões

de codificação e boas práticas que devem ser seguidas para melhoria de

extensibilidade, manutenibilidade e segurança do componente.

13

1.2. OBJETIVOS ESPECÍFICOS

Apresentar o que é CMS e para que ele serve, além de categorizá-los por tipo.

Apresentar o CMS Joomla! e explicar sua arquitetura, suas características principais

e conceitos importantes como, extensões, frontend e backend. Apresentar conceitos

de MCV e Internacionalização, que sirvam de base para o completo entendimento

do estudo. Apresentar o componente Questões, componente de coma finalidade de

cadastro de questões e resolução de simulados, que foi desenvolvido durante este

estudo. Apresentar o framewowk do Joomla!, as convenções de codificação que ele

utiliza e as facilidades que ele provê para o desenvolvimento de componentes.

Apresentar os artefatos de desenvolvimento (código) do componente Questões,

como exemplos explicativos da utilização da arquitetura, do framework, das

convenções de código e das boas práticas de programação para componentes com

Joomla!.

14

2. SISTEMA DE GESTÃO DE CONTEÚDO

2.1. O QUE É CONTEÚDO

Antes de nos aprofundarmos no conceito de Sistema de Gestão de Conteúdo, é

importante termos um conceito bem construído de conteúdo.

Segundo Batista (2007), Conteúdo é a identificação dada aos produtos e serviços de

informação, tais como: dados, textos, imagens, sons e software. Já Boiko (2005), faz

uma explanação sobre os conceitos de dado e informação, e através destes

fundamenta o conceito de conteúdo. Ele explica que dados são pequenos trechos de

“informação” computacional, como palavras, números, imagens e sons que, de

maneira isolada, não possuem muito significado relevante aos humanos, enquanto

que informação é um conjunto de dados organizados de maneira que possuam

alguma semântica. Já o conteúdo é a informação com determinado propósito, e em

uma forma utilizável por humanos. Ele afirma que informação que flui casualmente

não é conteúdo. Ela torna-se conteúdo apenas depois que alguém dá a ela uma

utilidade.

Alguns autores também incluem a funcionalidade como uma forma de conteúdo.

Boiko (2005) é um destes. Ele primeiro explica que: funcionalidade é uma série de

interações homem-computador, utilizando uma interface entre o usuário e a

máquina, a fim de realizar determinado processo; depois explica que a

implementação de funcionalidade nos sistemas está ficando cada vez mais granular,

com objetos que podem ser adicionados de diversas fontes e maneiras, fazendo

com que a funcionalidade possa ser gerenciável tal qual conteúdo, tornando a

distinção entre os dois cada vez mais difícil.

15

2.2. GESTÃO DE CONTEÚDO

Gestão de conteúdo é o processo de coletar, gerenciar e publicar conteúdo. (BOIKO,

2005)

� Coletar: criar conteúdo, ou adquirir este de uma fonte já existente.

� Gerenciar: persistência do conteúdo e dos dados relativos à administração

deste conteúdo.

� Publicar: extrair o conteúdo do repositório e disponibilizá-lo com uma

formatação específica.

Neves (2003), afirma que Gestão de Conteúdo significa controlar o conteúdo desde

a sua criação, até a sua disponibilização, arquivamento ou eliminação.

2.3. BENEFÍCIOS DA GESTÃO DE CONTEÚDO

A Gestão de Conteúdo fornece suporte às organizações no processo de captação,

organização e publicação de conteúdos, que podem ser originados de várias fontes

e destinados a diversos tipos de dispositivos de saída. (BATISTA, 2007)

Segundo Batista (2007), a Gestão de Conteúdo visa a dar respostas aos seguintes

problemas principais:

a) Gargalos que dificultam a produção de conteúdos para a web.

b) Falta de comprometimento dos usuários devido às dificuldades técnicas de

publicação e uso.

c) Falta de organização mais elaborada do conteúdo.

16

d) Riscos de diversos erros e informação de baixa qualidade.

e) Informações sobre estrutura misturadas ao conteúdo.

2.4. SISTEMA DE GESTÃO DE CONTEÚDO

Em uma abordagem de mais alto nível, um CMS é uma ferramenta ou conjunto de

ferramentas responsável pela coleta, gerenciamento e publicação de “pedaços” de

informação conhecidas como content components (componentes de conteúdo).

(BOIKO, 2005)

Alguns CMS bastante conhecidos atualmente são: Joomla!, Wordpress, Drupal,

Plone, MediaWiki, Alfresco, DotNetNuke, Blogger, osCommerce, dentre outros.

2.4.1. Principais funcionalidades de um CMS

De acordo com Fraser (2002), embora os CMS não sejam criados da mesma forma,

eles devem conter sempre as mesmas funcionalidades mínimas: manutenção e

publicação de conteúdo. Porém, a grande maioria dos CMS possui funcionalidades

que vão além das mínimas. Apesar da grande variedade, há um conjunto de

funcionalidades que são mais comuns entre os sistemas, merecendo portanto, uma

explanação sobre elas.

Serão apresentadas agora as funcionalidades mais comumente encontradas nos

CMS, segundo Fraser (2002).

Interface padrão para criação, edição e aprovação d e conteúdo

17

A padronização das interfaces torna desnecessário ter de aprender tudo do zero

toda vez que uma nova funcionalidade seja utilizada, pois o usuário já estará

acostumado com a estrutura da interface, e deverá aprender somente as diferenças

existentes nas novas interfaces em relação às já existentes.

Apesar de parecer óbvio essa funcionalidade, há alguns CMS que ainda não a

possuem. Isso se deve ao fato de esses CMS terem sido criados a partir da junção

de outras ferramentas, cada uma com sua interface padrão. Essas interfaces então

passaram a fazer parte do novo CMS.

Repositório comum

Colocar o conteúdo em apenas um lugar torna-o de fácil manutenção e pesquisa,

elem de ser uma forma mais segura de armazenamento.

Alguns CMS não proveem um repositório comum. Em vez disso eles proveem um

arquivo de controle que informa ao CMS em qual repositório o conteúdo está

guardado.

Controle de Versão, Monitoramento e Rollback

Manter informação de controle de versão do conteúdo é uma das funcionalidades

mais importantes no CMS.

Quando não há um controle de versão no CMS, normalmente o conteúdo pode ficar

desatualizado. Por exemplo, o autor A inclui um conteúdo. Então o editor B edita o

conteúdo e o aprova. Então o autor A altera a cópia original do conteúdo, que ainda

estava na sessão, e a salva novamente, sobrescrevendo o conteúdo previamente

aprovado e publicado pelo editor B. Como conseqüência disso, no final restará

apenas o conteúdo publicado pelo autor A, e as mudanças realizadas pelo editor B

serão perdidas.

Às vezes edições de conteúdo podem acrescentar erros, ou simplesmente o usuário

resolve desistir da mudança feita, com o controle de versão essa mudança pode ser

18

feita sem muito esforço, através do rollback. Rollback reverte um conteúdo para

estágios prévios deste.

Workflow (fluxo de trabalho)

Segundo Fraser (2002), um workflow (fluxo de trabalho) é um conjunto de tarefas

realizadas de maneira sequencial ou paralela, por mais de uma pessoa, com a

finalidade de alcançar um objetivo comum.

Todos os CMS possuem algum workflow. Uma característica importante em um

CMS é o quão simples e flexível é seu sistema de workflow. Muitos CMS permitem

ao usuário criar workflows personalizados, enquanto outros permitem ao usuário

realizar apenas as tarefas básicas já pré-definidas: criação, edição, aprovação e

publicação.

Geração dinâmica de páginas

Um CMS gera páginas dinamicamente através de layouts e componentes retirados

do repositório. A utilização de páginas dinâmicas permite que requisições iguais

possam gerar páginas diferentes para diferentes usuários.

Personalização

A personalização permite que o site apresente apenas o conteúdo específico para

determinado usuário, baseado nas preferências pessoais e na sua forma de

navegação. Podem haver vários níveis de personalização, desde uma simples

presença do nome do usuário em um site, até sites que não deixam aparecer

determinados conteúdos dependendo da configuração feita pelo usuário.

Gerenciamento de cache

No que concerne às funcionalidades de um CMS, cache é o processo de armazenar

páginas pré-configuradas em memória ou repositório, de maneira a facilitar a

pesquisa dessas páginas posteriormente.

Conversão de conteúdo

19

Alguns CMS possuem a funcionalidade de converter arquivos de um formato para o

formato requerido pelo repositório. Por exemplo, um CMS pode transformar

automaticamente dados de uma planilha do Microsoft Excel em uma tabela HTML.

Essa funcionalidade permite que o usuário crie seu conteúdo em sua ferramenta de

preferência, desde que o CMS consiga converter seu formato.

Integração com Sistemas de Busca

A maioria dos CMS utiliza sistemas de busca externos. A vantagem disso é que o

CMS ficará especializado somente na gestão de conteúdo, enquanto as buscas

serão realizadas por sistemas especializados em busca, ou seja, sistemas que

proveem a melhor solução para tal problema.

Alguns CMS possuem seu próprio sistema de buscas. Porém esses sistemas não

são tão avançados quando os providos por terceiros.

Monitoramento e análise

É o processo de analisar o comportamento do usuário no site. Isso significa que será

analisada a forma como os usuários utilizam determinada página, quais são as

páginas iniciais e finais que predominam em cada vez que um usuário acessa o

sistema.

2.4.2. Estrutura de um CMS

A Figura 1 ilustra a estrutura básica de um CMS.

Boiko (2005) divide a estrutura dos CMS em três subsiste

Sistema de Gestão e Sistema de Publicação

possibilitar a gestão do conteúdo.

logicamente separados, eles

adjacentes. Abaixo será apresentado cada um deles

Sistema de Coleta

O sistema de coleta é respons

conteúdo esteja pronto para

em um conjunto bem organizado de

serviços oferecidos no processo

agregação e serviços de coleta

Figura 1 _ Estrutura geral de um CMS

Fonte: Boiko (2005, p. 86).

Boiko (2005) divide a estrutura dos CMS em três subsistemas:

Sistema de Publicação , que trabalham em conjunto a fim de

possibilitar a gestão do conteúdo. Apesar de estes subsistemas estarem

logicamente separados, eles podem sobrepor sua funcionalidade à dos subsistemas

será apresentado cada um deles.

O sistema de coleta é responsável por todos os processos ocorridos antes que um

conteúdo esteja pronto para ser publicado. É ele quem torna a informa

bem organizado de content components. A

serviços oferecidos no processo de coleta, que são: autoria, aquisição, conversão,

de coleta.

20

Sistema de Coleta ,

que trabalham em conjunto a fim de

Apesar de estes subsistemas estarem

sua funcionalidade à dos subsistemas

por todos os processos ocorridos antes que um

É ele quem torna a informação simples

Figura 2 ilustra os

autoria, aquisição, conversão,

Figura

� Autoria: refere-se ao processo de criar conte

que deve ser esp

aquisição ao invés de autoria.

processos providos pelo CMS, pois ele é

dependendo somente da habilidade e capacidade do autor.

poder automatizar o processo de autoria, o CMS

para o autor. São elas:

o Ambiente de autoria, com uma aplicação completa e extensões qu

facilitam o trabalho do autor.

Figura 2 _ Estrutura do Sistema de Coleta

Fonte: Boiko (2005, p. 87).

se ao processo de criar conteúdo do zero. Um autor é alguém

que deve ser especificado para esta, caso contrário

aquisição ao invés de autoria. O processo de autoria é diferente dos demais

rovidos pelo CMS, pois ele é essencialmente manual

dependendo somente da habilidade e capacidade do autor.

poder automatizar o processo de autoria, o CMS provê

ão elas:

Ambiente de autoria, com uma aplicação completa e extensões qu

facilitam o trabalho do autor.

21

údo do zero. Um autor é alguém

, caso contrário o processo será

O processo de autoria é diferente dos demais

essencialmente manual,

dependendo somente da habilidade e capacidade do autor. Apesar de não

algumas facilidades

Ambiente de autoria, com uma aplicação completa e extensões que

22

o Pode-se predefinir o tipo de conteúdo que o autor poderá criar.

o Provê ajuda para criação de informação padrão. Por exemplo, incluir

automaticamente o nome do autor e data de criação em determinado

conteúdo.

o Provê templates, de forma que o autor possa inserir informações

mesclando-as com elementos já existentes, como em um template do

Microsoft Word, onde já se tenha o lugar para ser inserido o título,

dentre outros.

o Provê workflow, status e controle de versão para o conteúdo que está

sendo processado.

� Aquisição: é o processo de recolher informação que não foi originalmente

criada para determinado CMS. Isto significa que na Aquisição, a informação

não é criada, mas copiada de uma fonte externa para o CMS. Esse processo

pode ser tanto manual quanto automático. A informação adquirida pode vir

das seguintes fontes:

o Syndications: são fontes projetadas para o reuso. Elas são entregues

em formato XML ou outro formato que possibilite fácil integração, e já

possuem metadados adicionados à informação. O exemplo mais

comum de syndication são os web feeds.

o Found Sources: podem ser qualquer tipo de informação preexistente,

incluindo fontes não eletrônicas, como fotografias, filmes analógicos,

dentre outros, que possam ser digitalizados. Geralmente necessitam

de certo trabalho manual para transformá-los em conteúdo, pois são

desprovidos de metadados e não são segmentados.

� Conversão: deve acontecer quando o formato ou estrutura do conteúdo que

você criou ou adquiriu é diferente do formato ou estrutura requerida pelo

sistema. O processo de conversão consiste de três passos:

23

o Stripping: remoção de informação desnecessária, tal como cabeçalhos

e rodapés de páginas e conteúdo desnecessário.

o Mapeamento de Formato: modifica o formato binário da informação

para formato suportado pelo CMS.

o Mapeamento de Estrutura: torna explícita a estrutura da informação, ou

a modifica se necessário.

� Agregação: é o processo de juntar informações de fontes diversas em uma

única estrutura. É dividido em três passos:

o Processo Edi torial: responsável pelas funções de estilo,

consistência e uso.

o Processo de segmentação: consiste na transformação do conteúdo em

em pequenos componentes (content components).

o Processo Metatorial: adéqua o novo conteúdo ao sistema. Assegura

que os metadados referentes ao conteúdo agregado estão completos e

consistentes.

� Serviços de Coleta: sua principal função é ajudar a coletar conteúdo para o

repositório. Eles ajudam tanto no processo de autoria quanto no processo de

aquisição. Para isso, possui os dois serviços principais listados abaixo:

o Criação de conteúdo diretamente no repositório (principalmente

através de formulários web).

o Inclusão, no repositório, de componentes previamente criados. Um

exemplo comum é a utilização do Microsoft Word para edição de um

texto, que posteriormente será adicionado ao repositório.

24

Sistema de gestão

O Sistema de Gestão é o subsistema responsável pelo armazenamento e

administração do conteúdo. Ele provê detalhes sobre seu conteúdo, como quais

componentes estão sendo gerenciados no momento, e em que fase do ciclo de vida

cada componente está. Além de informar quais conteúdos estão sendo utilizados ou

não utilizados. Informa também quem tem acesso a determinado conteúdo.

O Sistema de Gestão possui as seguintes capacidades:

� Repositório: É o principal componente do Sistema de Gestão. Consiste no

conjunto das bases de dados, diretórios e arquivos de configuração, que

armazenam tanto o conteúdo coletado quanto dados de configuração do

CMS. Componentes e outros recursos do CMS são inseridos no repositório

através do sistema de coleta.

� Administração: O Sistema de Administração é responsável por administrar as

opções de configuração e a estrutura do CMS. Ele atua nos três subsistemas

do CMS.

o No Sistema de Coleta: administra configurações pessoais, como

direitos de acesso, e configurações do sistema, onde são configurados

as estrutura e o workflow do CMS.

o No Sistema de Gestão: ele é responsável pela administração de

usuários, permissões, backup, dentre outras tarefas que envolvem a

base de dados. Além disso também realiza tarefas específicas para

conteúdos, tais como criação de tipos de conteúdo, revisão de

metadados e criação de workflows.

o No Sistema de Publicação: possibilita a revisão de hardware e software

para que seja assegurado que o conteúdo poderá ser apresentado.

Permite saber se determinado conteúdo foi realmente publicado.

25

� Workflow: é responsável pela coordenação, agendamento (scheduling) e

tarefas pessoais.

� Conexões: o Sistema de Gestão pode necessitar estar conectado a fontes de

dados e infraestruturas externas, tais como Local Area Network (LAN), Wide

Area Network (WAN), base de dados de usuários em uma organização

(necessário para que os usuários e suas permissões sejam importados para o

CMS sem que haja necessidade de incluí-los manualmente), conexão com

sistema Enterprise Resource Planning (ERP) da organização, dentre outros.

Sistema de Publicação

O Sistema de Publicação é o subsistema responsável por obter o conteúdo

previamente salvo no repositório, a fim de publicá-lo, ou seja, apresentá-lo de

alguma forma ao usuário. Um Sistema de Publicação inclui:

� Templates: programas que constroem a estrutura de uma publicação, a forma

como o conteúdo deve ser apresentado.

� Serviços de Publicação: são serviços que contêm a lógica de negócio da

publicação. Ajudam na criação da publicação, escolhendo quais templates

devem ser utilizados e os executando. Podem também se utilizar de

conexões com serviços externos ao CMS, para obter dados que devam ser

utilizados em determinada publicação.

� Conexões: o Sistema de Publicação pode precisar manter conexões com

serviços externos ao CMS, para ter acesso a dados da organização que não

estejam persistidos no repositório do CMS. Neste caso o conteúdo é mantido

por sistemas externos e a função do CMS é somente a de publicação.

26

2.4.3. Tipos de CMS

Williams (2010) explica que há vários tipos de conteúdo digital, e que

consequentemente há também diversas categorias de ferramentas de Gestão de

Conteúdo, que podem ser classificadas de acordo com o tipo de conteúdo que

gerenciam. Ele divide essas ferramentas em: Sistema de Gestão de Ativos Digitais,

em inglês, Digital Asset Management System (DAM); Sistema de Gestão de

Documentos, em inglês, Document Management System (DMS); Gestão de

Registros Eletrônicos, em ingês, Electronic Records Management (ERM); Sistema

de Gestão de Conteúdo Web, em inglês, Web Content Management System

(WCMS); e Sistema de Gestão de Conteúdo Empresarial, em inglês, Enterprise

Content Management System (ECMS). Detalhar-se-á cada um desses tipos a seguir,

conforme descrição de Williams (2010).

Sistema de Gestão de Ativos Digitais

É similar ao DMS, porém é especializado em gestão de documentos de mídia

(vídeo, logos, fotografia, áudio etc.). Algumas das funções que ele desempenha são:

organizar, manipular, pesquisar, verificar a integridade, fazer entrega e distribuição,

proteger e fazer backup de Ativos Digitais. O DMS é utilizado principalmente pela

indústria de mídia e entretenimento. Alguns exemplos de DAM são: Fedora

Commons, FocusOPEN e Gallery.

Os DAM podem ser divididos em dois tipos básicos, segundo a forma como eles

armazenam o conteúdo:

� Catálogo de Mídia (Media Catalogue): delega ao Sistema Operacional a

função de gerenciar o ativo, ou seja, ele não controla realmente o conteúdo,

mas apenas mantém um índice de ativos, que será utilizado para a pesquisa

destes. Como o ativo está sob o controle do Sistema Operacional, o DAM não

consegue lhes oferecer nenhuma segurança.

� Repositório de Ativos (Asset Repository): diferentemente do Catálogo de

Mídia, o Repositório de Ativos é quem armazena e gerencia o conteúdo.

27

Desta forma, o ativo não pode ser visualizado de outra maneira que não

através do próprio DAM. Isso proporciona maior segurança aos ativos

gerenciados.

Sistema de Gestão de Documentos

DMS são ferramentas construídas com a finalidade de auxiliar as organizações no

gerenciamento da criação, armazenamento e obtenção de informação armazenada

na forma de documentos digitais (planilhas do Microsoft Excel, documentos do

Microsoft Word, PDFs, dentre outros). Ele utiliza um repositório centralizado para

armazenar os documentos, adicionando esquemas de classificação e protegendo-os

contra perdas.

As principais características do DMS são:

Foco no gerenciamento de documentos, cada documento armazenado é

independente (não está agregado a outro documento), capacidade de agrupar

documentos, foco no gerenciamento do ciclo de vida de um documento, acesso a

documentos pode ser restringido por pasta.

Devido ao tipo de conteúdo gerido pelo DMS, ele pode ser classificado como um

DAM, porém uma característica observada que pode distingui-los é que o DMS é

focado no ciclo de vida do documento, enquanto o DAM não o é.

Alguns exemplos de DMS são: Microsoft SharePoint, Xerox DocuShare, Google

Docs e DOCS Open.

Gestão de Registros Eletrônicos

O ERM é uma especialização do DMS com a finalidade de gerenciar registros de

uma empresa e de seus funcionários (contratos, faturas, registro de reclamações,

emails, dentre outros).

Sistema de Gestão de Conteúdo Web

28

Um WCMS é uma ferramenta utilizada tanto por pessoas com conhecimento técnico

quanto por pessoas sem conhecimento técnico para a criação de páginas web e de

websites. Para as pessoas com conhecimento técnico, o WCMS provê

principalmente criação descentralizada de conteúdo e separação entre layout e

conteúdo. Porém, os WCMS foram criados com o propósito de provê a pessoas sem

conhecimento técnico facilidade de criação e manutenção de páginas web.

Os WCMS podem ser divididos de acordo com as funcionalidades que eles proveem

e o quão estruturados podem ser os sites criados por eles.

Segundo Digital (2010), os WCMS podem ser divididos em:

� Portal: possuem muitas funcionalidades e podem gerenciar websites com

estrutura complexa. Alguns exemplos desse tipo de WCMS são Joomla! e

Drupal.

� Blog: é um tipo de WCMS em que artigos e posts são organizados

cronologicamente. São ideais para websites com estrutura simples. Alguns

softwares muito utilizados são WordPress e Movable Type.

� Wiki: permite a usuários criar e modificar facilmente o conteúdo, geralmente

utilizando uma linguagem de marcação própria, porém mais simples que

HTML. Geralmente possuem documentos de múltiplas páginas que podem

ser modificados de forma colaborativa. O software de wiki mais famoso é o

MediaWiki, que gerencia a Wikipedia.

� Fórum: software construído para manter discussões entre usuários. Um

exemplo de software de Fórum é o phpBB.

� Groupware: também chamado de software de colaboração, é um software

que permite que pessoas trabalhem de forma colaborativa. Auxiliando seus

usuários no cumprimento de tarefas comuns. Exemplos de groupware são:

agenda corporativa e chat.

29

Sistema de Gestão de Conteúdo Empresarial

Aproximadamente 80% das informações/documentos das empresas não se

encontram em bancos de dados. Normalmente essas informações estão na forma

não-estruturada: e-mails, arquivos digitais, vídeos, sons, documentos em papel ou

digitalizados, páginas web, conversas telefônicas, dentre outras. O ECMS surgiu

como um conjunto de ferramentas com o objetivo de gerir esse tipo de conteúdo e

possibilitar acesso a ele de forma rápida, online e segura. Os principais objetivos dos

ECMS são: redução de custos; organização das informações; facilidade de acesso e

compartilhamento das informações; manter a integridade destas; disponibilização do

conteúdo através da intranet e internet, facilidade no gerenciamento de conteúdo na

web e principalmente proporcionar agilidade nas tomadas de decisões. (T-

SYSTEMS, 2011)

Segundo AIIM (2011), ECMS é um conjunto de ferramentas para obter, gerenciar,

armazenar e distribuir conteúdo relacionado aos processos organizacionais. O

ECMS possibilita a gestão da informação organizacional, onde quer que ela exista

ou seja qual for sua forma.

De acordo com Williams (2010), Uma ferramenta para ser considerada um ECMS

deve possibilitar a gestão dos principais tipos de conteúdo, além de prover

escalabilidade em nível empresarial, suportando uma grande porcentagem dos

processos de uma empresa que possam ser automatizados.

Serão listados abaixo alguns dos principais serviços que um ECMS deve possuir a

fim de possibilitar uma abrangência completa dos processos de uma empresa.

� Reconhecimento de padrões: diz respeito a tecnologias que permitem que

dados inseridos por meio de digitalização de documentos sejam traduzidos

para caracteres através de Optical Character Recognition (OCR), ao invés de

ser gerada apenas uma imagem do que foi digitalizado.

� Categorização: provê uma estrutura formal para a informação, baseado nas

necessidades individuais do negócio. A categorização automatiza a

30

localização do conteúdo, para que no futuro essa informação seja recuperada

baseada em sua categorização.

� Indexação: consiste em criar metadados para documentos que foram

digitalizados, de forma que possam ser buscados posteriormente. A

indexação pode ser feita através de palavras-chave ou de full-text.

� Gestão de Documentos: ajuda a organização a gerenciar a criação, revisão,

aprovação e consumo de documentos eletrônicos.

� Gestão de Registros: os registros de valor de negócio de longo prazo

(contratos, faturas, registro de reclamações, dentre outros) são gerenciados

de acordo com seu tempo de retenção (tempo máximo que precisam ser

mantidos)

� Gestão de Email: email é a principal fonte de comunicação em uma

empresa, e por isso não devem ser apenas armazenados. Eles devem ser

classificados, armazenados e destruídos, ou seja, ter um ciclo de vida

completo, como qualquer outro tipo de documento.

� Gestão de Conteúdo Web: consiste na criação, revisão, aprovação e

publicação de conteúdo web.

� Gestão de Ativos Digitais: Similar à Gestão de Documentos, porém é

focado na gestão de documentos de mídia (vídeo, logo, fotografias, áudio,

dentre outros).

� Repositório: é onde estão armazenados os dados de todo conteúdo da

empresa gerenciado pelo ECMS.

� Armazenamento: não confundir com Repositório. Armazenamento é um

meio físico, onde o repositório reside. Exemplos são (discos ópticos, fitas

magnéticas e RAID). Proveem opções tanto para armazenamento online

quanto offline.

31

� Integração de Conteúdo: possibilita aos diferentes tipos de conteúdo a

serem tratados como se estivessem em um mesmo repositório.

� Backup: faz backup dos dados em diversos formatos e locais, a fim de

prevenir a perda de dados em caso de perda do repositório atual.

� Busca: é uma das principais funcionalidades de qualquer ECMS. Pois

permite a busca e recuperação do conteúdo previamente inserido.

� Syndication: distribuição do conteúdo para reuso e integração em outros

conteúdos.

� Localização: modificação da apresentação do conteúdo para se adequar à

cultura local de determinada empresa.

� Publicação: consiste na apresentação de um conteúdo através de

determinado meio, como impressão, email, website, portal, RRS feeds, etc.

� Segurança: restringe acesso ao conteúdo, tanto durante a criação e

gerenciamento, quanto durante a publicação.

� Colaboração: possibilita a criação e manutenção de equipes de trabalho,

mesmo em locais separados geograficamente. Além de possibilitar a tomada

de decisão e criação de conteúdo por essa equipe.

32

3. O CMS JOOMLA!

3.1. O QUE É JOOMLA!

Joomla! é um bem conceituado CMS que permite criar websites de forma fácil e

rápida. A relação bem equilibrada entre extensibilidade, quantidade de recursos e

facilidade de utilização fez com que ele se tornasse um dos WCMS mais populares

dentre os existentes. Ele além de ser uma ferramenta gratuita, é também open

source, liberado sob a licença General Public License (GPL), o que proporciona

liberdade para desenvolver extensões conforme a necessidade. Apesar de a

ferramenta primariamente instalada ser totalmente gratuita, algumas extensões

podem não o ser, desde que incluam o código fonte com elas. (JOOMLA!, 2010)

O Joomla! possui grande flexibilidade quanto ao tipo de website que ele produz,

podendo ser desde um website simples, como um blog até um complexo e bem

estruturado, como um portal.

Alguns exemplos de websites que podem ser criados e gerenciados pelo Joomla!

são: Portais e websites corporativos, intranets e extranets corporativas, revistas e

publicações online, E-commerce, Aplicações para o governo, websites para

pequenas empresas, websites para não profissionais, portais baseados em

comunidades, websites para escolas e sites pessoais.

3.2. HISTÓRICO DO JOOMLA!

O Joomla! nasceu quando o grupo de desenvolvedores do Mambo Open Source

(MOS) ficou insatisfeito com os interesses da Miro, empresa criadora do Mambo

CMS, que se tornara detentora dos direitos do MOS, podendo a qualquer momento

33

vendê-lo a outra empresa ou comercializá-lo de forma não gratuita. Como o MOS

era open source, seus desenvolvedores então resolveram dar continuidade ao

projeto, que já obtivera bastante sucesso, ficando inclusive mais famoso que seu

irmão de código fechado, Mambo CMS. Eles então criaram um grupo chamado

Open Source Matters, que foi o responsável pela criação do projeto Joomla! Em

primeiro de setembro de 2005, com o objetivo de dar continuidade à crescente

popularidade do MOS, tanto em relação aos usuários quanto em relação à

comunidade de desenvolvedores. O nome “Joomla!” tem origem africana e pode ser

traduzido como “todos juntos”, expressão que faz alusão ao fato dele ser totalmente

de código aberto, o que possibilita que ele seja desenvolvido e mantido por várias

pessoas independentemente de sua cultura ou posição geográfica.

Como o código do Joomla! fora herdado do MOS, sua versão 1.0 era idêntica a este,

e portanto as extensões do Joomla! 1.0 eram totalmente compatíveis com o MOS.

Algumas restrições que o Joomla! possuía levaram os codificadores a repensar sua

estrutura, e após dois anos de desenvolvimento, foi lançado em 2007 o Joomla! 1.5,

com uma estrutura totalmente diferente da versão 1.0. (KENNARD, 2007)

Em 10 de janeiro de 2011 foi anunciado o Joomla! 1.6. Esta versão não trouxe

tantas diferenças em sua estrutura em relação à estrutura da versão 1.5; quanto

trouxera a versão 1.5 em relação à 1.0, que era apenas o MOS com o nome

modificado. A versão 1.6 trouxe, no entanto, uma gama muito grande de melhorias

tanto para desenvolvedores de extensões, quanto para administradores e usuários.

(JOOMLA!, 2011)

Algumas das melhorias mais importantes adicionadas na versão 1.6 são: melhoria

da Access Control List (ACL), aumentando a flexibilidade e a personalização no

gerenciamento de usuários, grupos e controle de acesso; novas funções de Search

Engine Optimization (SEO); melhoria no gerenciador de mídias e melhorias no

gerenciador de instalação, com a inclusão de arquivos de atualização de extensões,

que facilitam a atualização de extensões de terceiros por parte dos administradores.

(JOOMLA!, 2011)

34

3.3. CONHECENDO O JOOMLA!

3.3.1. Requisitos de instalação

O Jommla! foi totalmente desenvolvido na linguagem de programação PHP, por isso

é necessário uma servidor web com PHP instalado para executá-lo.

Segundo Joomla! (2011), a configuração mínima para execução da versão 1.6 do

Joomla! é:

� Apache (servidor web) versão 2.x

� PHP (interpretador de código) versão 5.2

� MySQL (banco de dados) versão 5.0.4

Também pode ser utilizado o servidor da Microsoft

� Microsoft IIS: versão 7

� MySQL: versão 5.1

Observações:

� A partir da versão 5.5.15 o Joomla! é compatível com o PHP 5.3, porém ele

possui uma biblioteca, OpenID, que não é compatível com esta versão.

� Na versão 6 do Joomla!, a biblioteca OpenID foi removida, portando, esta

versão possui total compatibilidade com PHP 5.3.

� Joomla! ainda não é compatível com a versão 6.x do MySQL.

3.3.2. Arquitetura

A Figura 3 apresenta a arquitetura do Joomla!

Segundo Joomla! (2011

estrutura de três camadas: camada de Aplicação, camada de Extensão e camada de

Framework.

Arquitetura

apresenta a arquitetura do Joomla!

Figura 3 _ Arquitetura do Joomla!

Fonte: Joomla! (2011).

1), O Joomla! 1.6 pode ser descrito como

três camadas: camada de Aplicação, camada de Extensão e camada de

35

pode ser descrito como possuindo uma

três camadas: camada de Aplicação, camada de Extensão e camada de

36

Na camada de Extensão (ver item 3.3.3) estão os pacotes que estendem o

comportamento padrão do Joomla!. Algumas extensões já vêm por padrão na

instalação, enquanto outras podem ser adicionadas posteriormente.

A camada de Aplicação consiste de aplicações que possuem um comportamento em

comum. Elas possuem uma função essencial para o funcionamento do Joomla!. A

versão 1.6 possui três dessas aplicações: instalação, administração (responsável

pelo backend), e site (responsável pelo frontend). Na versão 1.5 havia também a

aplicação XML-RPC, que suportava administração remota do website, porém na

versão 1.6 ela tornou-se desnecessária.

A camada de Framework consiste em:

� Framework provido pelo Joomla!: conjunto de classes que proveem

funcionalidades básicas e facilitam o trabalho de desenvolvedores.

� Libraries: bibliotecas de terceiros que são requeridas pelo framework ou são

instaladas por extensões.

� Plugins: também é um tipo de extensão. Provê rotinas responsáveis por

responder a eventos ocorridos na aplicação. Possibilitando adicionar

funcionalidades que dependam da ocorrência de determinados eventos.

3.3.3. Extensões

Uma das principais razões para a popularidade do Joomla! é a enorme variedade de

Extensões disponíveis, o que possibilita uma gama muito grande de funcionalidades,

além de possibilitar ao administrador do website escolher qual extensão, dentre as

várias disponíveis, se adéqua melhor às suas necessidades. Isso torna o Joomla! o

preferido tanto para usuários quanto para desenvolvedores, em se tratando de CMS

para portais. (RAHMEL, 2007)

37

Uma Extensão é um termo genérico que consiste em um pacote que pode ser

adicionado ao seu website Joomla!, incluindo novas funcionalidades ou

simplesmente modificando funcionalidades já existentes na instalação padrão deste.

Algumas Extensões, no entanto, já vêm inclusas na sua instalação padrão. Diante

disso, pode-se dizer que uma Extensão, ao contrário do que se pode pensar, não é

somente um add-on (que pode ser adicionado ao website), mas um pacote que

estende o core do Joomla!, podendo portanto já vir como padrão na instalação ou

ser adicionado posteriormente. Consultando a Figura 3, vê-se que as Extensões,

exceto Plugins, estão em uma camada, Extension Layer, que se sobrepõe à

Application Layer. Isso significa que o termo “Extensão”, no Joomla!, designa

estrutura em vez de estado (o fato de ser previamente ou posteriormente instalado).

No Joomla! 1.6 as extensões são divididas em sete tipos: Componente, Linguagem,

Módulo, Plugin (na versão 1.0.x era chamado de Mambot), Template, Library e

Package. Algumas extensões são muito simples, enquanto outras são mais

complexas e exigem maior tempo e cuidado no desenvolvimento. Apresentar-se-ão

a seguir cada um desses tipos.

Linguagens

Linguagens (Languages) são o tipo de extensão mais básico do Joomla!. São tão

simples que podem ser implementadas por uma pessoa sem conhecimentos de

programação, devendo apenas possuir o conhecimento necessário para a tradução.

Há inclusive uma extensão (Translation manager extension) que ajuda na criação

dos arquivos necessários. As linguagens podem ser empacotadas de duas

maneiras, como pacotes do core (pacotes que já vêm inclusos na instalação do

Joomla!) ou pacotes de extensão. As Linguagens são uma ferramenta essencial

para a internacionalização do Joomla!. Elas possibilitam o número oficial atual de 64

traduções, que fazem do Joomla! O CMS com o maior número de traduções

atualmente. (JOOMLA!, 2011)

O Joomla! utiliza a codificação de caracteres UTF-8, isso permite que tanto seu

conteúdo quanto seus dados sejam traduzidos para qualquer língua, pois permite a

utilização de qualquer conjunto de caracteres.

38

Template

Um Template é basicamente o design do website, é um tipo de extensão que

modifica a maneira como as páginas e outras extensões do website são

apresentadas. Há dois tipos de Templates: de front-end, que modifica a interface do

usuário e de back-end, que modifica a interface de administrador do website.

Templates tornam possível modificar todo o layout da aplicação de forma rápida,

fácil e uniforme, sem ter problemas de ficarem estilos diferentes para lugares

diferentes do website.

Plugin

Plugins são extensões que se integram com a camada mais baixa do Joomla!, a

Framework Layer. Eles operam entre o usuário e a aplicação, e executam alguma

ação ao interceptarem eventos ocorridos. Isso significa que tanto o Joomla! core

quanto outras extensões podem lançar algum evento, que será “ouvido” por um ou

mais plugins, que dependendo do evento decidirá se deverá ou não executar uma

ação. No Joomla! 1.0 havia um equivalente ao Plugin,, eram os Mambots, que

funcionam da mesma forma que os Plugins. A diferença entre eles é somente

estrutural, sendo a estrutura do Joomla! 1.5 e 1.6 mais limpa que a 1.0.

A Figura 4 apresenta o funcionamento de um Plugin.

O Plugin pode interceptar os dados de

o usuário. No sentido oposto, ele intercepta os dados do usuário e pode transform

los antes de enviá-los para o repositório.

Módulo

Módulo é uma extensão leve e utilizada na formação da página. Pode ser utilizada

em vários componentes, e também pode haver muitos módulos em um único

componente. Os módulos são associados a componentes, dessa forma serão

renderizados apenas para os componentes a que forem associados. Muitos pacotes

de extensão utilizam mais de uma extensã

(poll), que utiliza um Módulo para apresentar a interface com o usuário, e um

Componente para permitir configuração e administração.

Figura 4 _ Funcionamento de um Plugin

Fonte: Rahmel (2007, p. 267).

pode interceptar os dados de output e modificá-los antes de

No sentido oposto, ele intercepta os dados do usuário e pode transform

los para o repositório.


ários componentes, e também pode haver muitos módulos em um único



de extensão utilizam mais de uma extensão, um exemplo é o pacote de votação

), que utiliza um Módulo para apresentar a interface com o usuário, e um

Componente para permitir configuração e administração.

39

los antes de enviá-los para

No sentido oposto, ele intercepta os dados do usuário e pode transformá-


ários componentes, e também pode haver muitos módulos em um único



o, um exemplo é o pacote de votação

), que utiliza um Módulo para apresentar a interface com o usuário, e um

40

Componente

Componentes podem algumas vezes ser confundidos com Módulos, porém não é

difícil distingui-los. Componentes possuem mais capacidade de interação que os

Módulos e são eles quem renderizam o corpo da página, enquanto Módulos são

“componentes” que existem dentro da página, ou seja, Componentes são mais

complexos e contém Módulos. Por serem mais complexos, consequentemente são

de mais difícil implementação.

Os componentes geralmente estão associados a um item de menu. Desta forma

quando um usuário clica em um menu no Joomla! ele será direcionado para um

componente, que na maioria das vezes exibirá uma página inicial para interação

com o usuário.

Bibliotecas (Library)

São pacotes de código que provêem um grupo de funções relacionadas. Elas já

existiam na versão anterior, mas na atual é possível instalar, atualizar e desinstalá-

los.

Pacote (Package)

Package é uma extensão que nada mais é do que a junção de mais de um tipo de

extensão no mesmo arquivo de instalação.

3.3.4. Frontend e Backend

Um website produzido com Joomla! é dividido em duas aplicações básicas:

� Frontend: parte principal do website. É utilizada por usuários sem direitos

administrativos. No frontend é possível gerenciar conteúdo, como incluir e

modificar artigos, dependendo do nível de acesso do usuário; mas não é

41

permitido realizar tarefas administrativas como gerenciar extensões e

usuários.

� Backend: parte administrativa do site, que é acessada por um endereço

especial. Permite o gerenciamento de usuários, extensões e de opções do

site. No backend é onde a estrutura do website é definida, enquanto no

frontend será permitido somente criar e manter conteúdo que preencha esta

estrutura. (SCARATE, 2007)

42

4. DEDENVOLVIMENTO DE COMPONENTES PARA O JOOMLA!

Este capítulo tem como objetivo apresentar um passo a passo para se desenvolver

um componente internacionalizável (ver seção 4.3) para o Joomla! utilizando o

modelo arquitetural Model View Controller (MVC).

Apresentar-se-ão técnicas e boas práticas que devem ser seguidas na construção

de um componente para o Joomla!. Além disso será explanado sobre a estrutura

que ele provê para facilitar esse desenvolvimento. Todos os detalhes de

implementação serão apresentados a partir do código do componente Questões,

que foi desenvolvido como forma de auxiliar neste trabalho.

4.1. O COMPONENTE “QUESTÕES”

O Questões foi desenvolvido como parte deste trabalho, como forma de

aprofundamento e complemento do conteúdo teórico adquirido através das fontes

textuais. Além disso, ele será utilizado como exemplo na apresentação da teoria do

desenvolvimento de componentes para o Joomla!.

O Questões é um componente que tem como funcionalidades o cadastro de

questões de múltipla escolha, cadastro de simulados, e resolução de simulados. Os

diagramas abaixo apresentam os principais fluxos do Componente, bem como o

detalhamento desses fluxos.

A Figura 5 apresenta os casos de uso do Questões, que são as funcionalidades que

o Componente provê: Cadastro de Questão (que deve ser precedida do cadastro de

uma prova), Cadastro de Simulado e Resolução de Simulados.

43

Figura 5 _ Diagrama de Casos de Uso do componente Q uestões

Fonte: Bruno Queiroz.

A Figura 6 detalha a funcionalidade mais complexa do componente, o cadastro de

questões.

44

Figura 6 _ Diagrama de Atividades (Cadastrar Questã o)


A Figura 1Figura 7 detalha a funcionalidade de cadastro de simulados.

45

Figura 7 _ Diagrama de Atividades (Cadastrar Simula do)


A Figura 8 detalha a funcionalidade de resolução de simulados.

46

Figura 8 _ Diagrama de Atividades (Resolver Simulad o)


Apresentar-se-ão abaixo as telas relativas às funcionalidades do Questões.

A Figura 9 apresenta a tela de listagem de

várias questões. Pode-

existente. Além disso é possível listar provas

Figura 9 _ Tela do componente Questões (Listagem de

apresenta a tela de listagem de provas, sendo que cada prova contém

-se cadastrar uma nova prova, editar

Além disso é possível listar provas de acordo com um filtro.

_ Tela do componente Questões (Listagem de Provas


47

provas, sendo que cada prova contém

ou excluir uma já

de acordo com um filtro.

Provas )

48

A Figura 10 representa a funcionalidade de cadastro de questões. Esta é a

funcionalidade mais complexa, onde se deve primeiro cadastrar uma prova, e

posteriormente incluir as questões nesta. Quando são cadastradas novas questões,

estas aparecem em uma listagem, sendo possível editá-las ou excluí-las. Neste

componente, concebeu-se uma forma bastante simples de cadastro de questões,

onde em um único formulário é possível cadastrar vários tipos de questões, como

questão de múltipla escolha, questão de múltipla escolha com assertivas ou

somente texto (para textos que são utilizados por várias questões). Além disso, não

há limites para a quantidade de itens ou de assertivas, podendo-se adicioná-los ou

excluí-los conforme a necessidade. O componente também possibilita que sejam

inseridos estilos para as frases incluídas, através de um editor de texto. Dessa forma

é possível inserir negrito, itálico, modificar tamanho e tipo de letra, dentre outros.

Figura 10 _ Tela do componente Questões (

A Figura 11 apresenta a funcionalidade de listagem de simulados, onde é possível

listar simulados conforme um filtro inserido, criar um novo simulado, excluir um

simulado existente ou ir para a tela de r

Tela do componente Questões ( Cadastro de Questões)


apresenta a funcionalidade de listagem de simulados, onde é possível


simulado existente ou ir para a tela de resolução de simulados.

49

Cadastro de Questões)

apresenta a funcionalidade de listagem de simulados, onde é possível


Figura 11 _ Tela do componente

A Figura 12 representa a funcionalidade de cadastro de simulado.

possível cadastrar um simulado, que conterá as questões que se adequarem aos

requisitos determinados

Tela do componente Questões (Listagem de Simulados


representa a funcionalidade de cadastro de simulado.


no formulário.

50

Questões (Listagem de Simulados )

representa a funcionalidade de cadastro de simulado. Nesta tela é



A Figura 13 representa a funcionalidade de Resolução de simulados.

possível resolver as questões dos simulados cadastrados

questão é resolvida o sistema automaticamente

corretamente ou não. Ao fechar

abri-la novamente as questões que já foram resolvidas continuarão como resolvidas

e com suas respectivas respostas e indicação de erro ou a

Tela do componente Questões ( Cadastro de Simulado)


representa a funcionalidade de Resolução de simulados.

possível resolver as questões dos simulados cadastrados. No momento em que a

questão é resolvida o sistema automaticamente apresenta se a questão foi resolvida

Ao fechar-se a tela, as informações continuam salvas, e ao

la novamente as questões que já foram resolvidas continuarão como resolvidas

e com suas respectivas respostas e indicação de erro ou acerto.

51

Cadastro de Simulado)

representa a funcionalidade de Resolução de simulados. Nesta tela é

No momento em que a

apresenta se a questão foi resolvida

se a tela, as informações continuam salvas, e ao

la novamente as questões que já foram resolvidas continuarão como resolvidas


4.2. MODEL-VIEW

O Model View Controller

estrutura da aplicação em três

Tela do componente Questões ( Resolução de Simulado)


VIEW-CONTROLLER

Controller (MVC) é um padrão de arquitetura de software que

estrutura da aplicação em três camadas, modelo (model), visão (

52

de Simulado)

de arquitetura de software que divide a

), visão (view) e controle

53

(controller). Cada uma dessas camadas possui responsabilidades distintas. Elas são

separadas de forma que a parte do sistema responsável pelo domínio e acesso a

banco de dados fique separada da parte do sistema responsável pela visualização.

Para possibilitar isso há também uma camada que controla a interação entre essas

duas camadas. O objetivo dessa separação é manter o código mais organizado,

facilitando a manutenção. Dessa forma é possível fazer modificações na camada de

visão, inclusive trocar totalmente o tipo de visualização, sem necessitar fazer

mudanças no Modelo. O contrário também acontece. Quando for preciso fazer

mudança na forma de pesquisar dados ou no acesso aos dados, por exemplo, se

mudar a fonte de dados, será preciso mudar apenas o Modelo, sendo que a camada

de Visão não precisará ser modificada.

Segundo Fowler (2011), a ideia principal do MVC é a separação da apresentação,

que consiste na separação dos objetos de domínio (a parte do software que modela

a percepção que se tem do mundo real) dos elementos que compõem a

apresentação do software. Ele explica também que os objetos de domínio devem

funcionar independentemente dos objetos da apresentação, sem ter conhecimento

destes, além disso devem suportar múltiplas camadas de visão.

A Figura 14 apresenta a estrutura do MVC

Tanto a Visão quanto o

acesso à Visão. A Visão e o Modelo podem lançar eventos que são interceptados

pelo Controle. Há no entanto variações dessa arquitetura, com pequenas

modificações.

Modelo

O Modelo é a camada que encapsula

aplicação. Ele provê rotinas para manipular os dado

estes, independentemente da forma como estão armazenados

Visão

Figura 14 _ Estrutura do MVC


isão quanto o Controle possuem acesso ao Modelo, e o

isão e o Modelo podem lançar eventos que são interceptados

ontrole. Há no entanto variações dessa arquitetura, com pequenas

o é a camada que encapsula o acesso aos dados e a lógica de negócio

aplicação. Ele provê rotinas para manipular os dados e é responsável pelo acesso a

endentemente da forma como estão armazenados. (ORACLE, 2011)

54

odelo, e o Controle possui

isão e o Modelo podem lançar eventos que são interceptados

ontrole. Há no entanto variações dessa arquitetura, com pequenas

e a lógica de negócio da

s e é responsável pelo acesso a

. (ORACLE, 2011)

55

Visão é a camada responsável por apresentar os dados do modelo de maneira que

possibilite interação com humanos, e servir de porta de entrada para dados inseridos

por humanos, como formulários, por exemplo. Pode haver diferentes Visões para um

mesmo Modelo e Controle. As Visões devem ser diferentes conforme a necessidade

do usuário de visualizar dados em diferentes formas. Por exemplo, uma aplicação

pode necessitar de uma Visão para a web e uma Visão para desktop. Nesse caso

deverá ter duas Visões para o software, e a camada de Controle será encarregada

de decidir qual das duas utilizar. (ORACLE, 2011)

Controle

O Controle, ou Controlador, é responsável por responder às ações do usuário. Ele

verifica qual método deve ser utilizado e o aciona no Modelo. Depois passa o

Modelo para a Visão para que ela apresente os dados, ou passa apenas os dados

para a Visão, isso dependendo da implementação do MVC. (ORACLE, 2011)

4.3. INTERNACIONALIZAÇÃO (I18N)

Segundo W3C (2011), a internacionalização (ou I18N, que é um acrônimo para o

termo “internationalization” onde são utilizadas sua primeira e última letra mais o

número 18, que é a quantidade de letras intermediárias) é a criação e o

desenvolvimento de um produto, aplicação ou conteúdo de um documento que

permita a localização (adaptação a determinada cultura ou idioma) fácil para

públicos-alvo que variam em cultura, região ou idioma. Não se deve confundir

localização com internacionalização. Enquanto a localização é o ato de modificar um

conteúdo para que ele se torne apresentável a pessoas de determinada cultura e

idioma, a internacionalização é apenas modificar o software para que ele seja de

fácil localização.

O Joomla! é totalmente internacionalizado e ainda provê suporte à fácil

internacionalização de componentes de terceiros.

56

4.4. O JOOMLA! FRAMEWORK

Um framework é uma estrutura reutilizável dentro de uma aplicação. No Joomla! o

framework consiste em uma camada completa, e é representado por sua Application

Programing Interface (API). Sua API consiste em um conjunto de classes que estão

separadas em diversos pacotes. Os pacotes existentes são os seguintes:

Access, application, base, cache, client, database, document, environment, error,

event, filesystem, filter, form, HTML, installer, language, mail, plugin, registry,

session, updater, user e utilities.

Há algumas classes que não se pode deixar de mencionar aqui. Elas são classes

notáveis, apesar de todas serem importantes. São elas:

JObject

JObject é a classe básica para quase todas as outras classes do Joomla!

Framework. Ela é abstrata, portanto provê somente interface em vez de

funcionalidade.

JApplication

É a superclasse das classes da camada de Aplicação. Ou seja, toda aplicação no

Joomla! deve estender essa classe. Atualmente há três aplicações no Joomla!:

Instalação (responsável pela instalação do Joomla!, e deve ser removida após sua

instalação por motivos de segurança), Administração (backend) e Site (frontend).

JModel, JView e JController

São classes abstratas que proveem as funcionalidades básicas para as classes de

cada uma das camadas do padrão MVC. É extremamente recomendado que os

componentes sejam desenvolvidos utilizando-se essa arquitetura, e portanto,

estendendo essas três classes.

57

4.5. DESENVOLVENDO O COMPONENTE

O código do Joomla! foi projetado para facilitar o reuso e a extensibilidade, levando o

desenvolvedor a utilizar uma arquitetura bem projetada de maneira automática. Seu

framework tira do desenvolvedor várias responsabilidades que não poderiam ser

deixadas de fora do componente, mas que deixariam o desenvolvimento mais

complicado e demorado, caso o desenvolvedor tivesse que se preocupar com elas.

Algumas dessas responsabilidades são, dentre outras, ACL (questões de segurança

e controle de acesso), internacionalização; o template da aplicação, com seus

menus, rodapé, cabeçalho, dentre outros; e SEO. (JOOMLA!, 2011)

Uma característica muito importante do framework do Joomla! é que ele utiliza-se do

paradigma de desenvolvimento chamado Convention over Configuration

(Programação por Convenção, ou CoC), igualmente a outros frameworks web

famosos, como o Ruby on Rails e o Grails. Segundo Neto (2011), o CoC é um

paradigma que visa a diminuir a quantidade de decisões que o desenvolvedor

precisa tomar, tendo como padrão algo que é comumente utilizado, uma convenção.

Isto torna desnecessária ou pouco necessária a utilização de arquivos de

configuração. No Joomla!, os nomes e localização dos arquivos, bem como nomes

das classes, são utilizados ao invés de configuração explicita.

O principal ponto que deve ser notado antes de se começar o desenvolvimento de

um componente para Joomla! é a convenção de nomenclatura. Como já foi dito

neste capítulo, o Joomla! utiliza CoC como forma de garantir um desenvolvimento

mais rápido e garantir padronização entre diversos componentes desenvolvidos por

diferentes pessoas. Serão apresentadas agora as convenções de nomenclatura e de

estrutura de arquivos utilizada pelo Joomla!

4.5.1. Convenções de codificação

58

Convenções de nomeação e estrutura de pastas

Antes de tudo é importante salientar que o framework do Joomla! é bastante

flexível, portanto não é obrigatório seguir as convenções adotadas por ele.

Porém seguir estes padrões é altamente recomendado, pois melhora a

legibilidade e a manutenibilidade do código. Será apresentada abaixo a estrutura

do componente Questões, seguida por um detalhamento das convenções

seguidas por este componente.

Figura 15 _

� A primeira convenção a ser seguida é o nome da pasta

componente. Esta p

components/com_{nomedocomponente}

contém todos os componentes do

componente Questões, deve ficar

_ Estrutura de diretórios do componente Questões


A primeira convenção a ser seguida é o nome da pasta

componente. Esta pasta deve ter a seguinte nomenclatura:

components/com_{nomedocomponente} , onde components

contém todos os componentes do font-end do Joomla!.

componente Questões, deve ficar components/com_questoes

59

Estrutura de diretórios do componente Questões

A primeira convenção a ser seguida é o nome da pasta que contém o

sta deve ter a seguinte nomenclatura:

components é a pasta que

. Então no caso do

components/com_questoes .

60

� Todo componente deve ter um ponto de entrada (entry point). Como o nome

diz, esse arquivo deve ser o ponto de entrada de toda requisição ao

componente. É nele onde serão tomadas algumas decisões preliminares,

como por exemplo, qual o controlador que será utilizado. O nome do entry

point deve seguir o seguinte padrão:

{componente}/{nomedocomponente}.php, que deverá ficar, no caso do

Questões, com_questoes/questoes.php.

� index.html: não faz parte de nenhuma convenção, mas é aconselhável

colocar esse arquivo em todos os diretórios do componente, a fim de prevenir

que usuários maliciosos tentem fazer uma listagem dos arquivos e pastas

contidos no diretório do Joomla!. Essa listagem é realizada automaticamente

pelo servidor web Apache, quando da falta de um arquivo index.html.

� controller.php: é o controlador padrão do componente. Deve conter uma

classe com o seguinte padrão de nomeação:

{NomeDoComponente}Controller, que no nosso caso ficará

QuestoesController. Esta classe deve estender a classe base

JController.

� A pasta tables contém classes que representam uma tabela de banco de

dados do componente. Cada arquivo que represente uma tabela deve ter seu

nome seguindo nomenclatura: {nomedatabela}.php, e o nome da classe

deve ser JTable{NomeDaTabela}. Além disso, deve estender de JTable .

� A pasta models contém as classes que representam o modelo do

componente. Essas classes são responsáveis por acessar o banco de dados

tanto para pesquisar dados quanto para realizar ações, como salvar, editar,

listar, etc. Os arquivos do modelo devem representar uma view, e seu nome

deve ser igual ao da view que representam. Sua classe deve ter a seguinte

nomenclatura: {NomeDoComponente}Model{NomeDoModel}, e devem

estender a classe JModel. No momento da requisição, o framework relaciona

ao controlador um modelo com o mesmo nome da visão atual, se o

desenvolvedor tentar criar outro model nesse momento, não será possível a

61

menos que especifique via código qual o modelo que deverá ser criado para

tal visão.

� A pasta controllers contém controladores adicionais para o componente,

caso o desenvolvedor queira ter mais controladores além do padrão. Eles

devem conter o padrão de nomeação: {nomedocontrole}.php e sua classe

deve conter o padrão

{NomeDoComponente}Controller{NomeDoControlador} e deve estender

JController. O fluxo será direcionado para o controlador cujo nome seja

igual ao valor da variável controller presente na requisição. Caso a variável

controller não exista ou não possua valor, o fluxo será direcionado para o

controlador padrão. Durante o desenvolvimento do Questões, observou-se

que criar um controlador para cada página é o ideal, pois melhora a

legibilidade do código, separando-o em várias partes; e possibilita a utilização

das ações padrão do Joomla! (save, update, delete, etc) para cada página do

componente.

� A pasta views deve conter as diferentes visões do componente. Onde cada

visão deve representar uma página, e deve conter uma pasta com seu nome.

o Dentro da pasta de uma visão, há o arquivo view.html.php, que é o

ponto de entrada para esta visão. Este arquivo deve declarar a classe

{NomeDoComponente}View{NomeDaVisao}, que no caso do

Questões, e para a visão que foi escolhida para exemplo, que é a visão

“simulado”, ficará QuestoesViewSimulado. Esta classe deve estender

a classe JView. O “.html” contido no nome do arquivo significa o

formato de visualização que deve ser apresentado. Este formato é

escolhido através da variável format. Por exemplo, caso seja preciso

apresentar a visão no formato pdf, deve-se passar na requisição o

parâmetro format=pdf , que será apresentada a visão cujo arquivo

principal chama-se view.pdf.php.

o O arquivo de visão é responsável por obter, através do modelo, os

dados que serão apresentados na tela, porém quem apresenta

62

realmente os dados é o template. O template deve ficar na pasta

/nomedavisao/tmpl, e normalmente seu nome será default.php .

Caso queira ter o template com nome diferente, deve-se setar a

variável layout com o nome do arquivo de template desejado.

Variáveis de requisição

O Joomla! também possui variáveis padrão que devem ser enviadas na requisição

como forma de acessar um componente e escolher a página ou controlador a ser

acessado, ação a ser realizada, e outras opções. A lista abaixo apresenta todas as

variáveis de requisição padrão do Joomla! que foram utilizadas durante o

desenvolvimento do componente ou que tomou-se conhecimento durante este

trabalho.

Option Nome do componente que deve ser executado.

View Nome da visão que deve ser executada.

Controller Nome do controlador que deverá executar determinada ação.

Task Nome da ação que será executada no controlador selecionado.

Layout Especifica qual o arquivo de template que será utilizado pela visão.

Format Especifica qual o formato da página que será carregada. Ex.:

format=pdf direciona para o arquivo view.pdf.php.

Tmpl Indica qual o template em que o componente deve ser adicionado.

Caso necessite que seu componente não utilize o template padrão

do Joomla!, de modo a não caregar menu, rodapé e o topo da

página, deve-se utilizar o parâmetro tmpl=component na requisição.

Isso geralmente é necessário quando se quer abrir uma tela modal

sem que esta apresente o template padrão.

4.5.2. Codificação

Agora que já se tem a teoria para a criação da estrutura do componente, serão

apresentadas técnicas para a codificação de um componente para

por arquivo, porém incluindo apenas

o completo entendimento

Arquivo questões.php

Figura 16 _

Codificação


apresentadas técnicas para a codificação de um componente para

incluindo apenas os arquivos e partes de código

ntendimento do processo de desenvolvimento.

_ Arquivo questoes.php (entry point do componente)


63


apresentadas técnicas para a codificação de um componente para Joomla!, divididas

os arquivos e partes de código relevantes para

Arquivo questoes.php (entry point do componente)

64

O arquivo com_questoes/questões.php é o ponto de entrada do componente, isso

significa que toda requisição ao Questões deve passar primeiro por este arquivo.

A linha 3 verifica se a constante _JEXEC teve seu valor inicializado. Ela é

inicializada pelo Joomla! no momento da requisição. Se a função

defined(‘_JEXEC’) retornar um valor falso, significa que alguém tentou acessar o

componente sem ser através do Joomla!, então a execução é encerrada. É

aconselhável ter esta instrução em todos os arquivos do componente. A instrução da

linha 5 faz um include do arquivo controlador padrão. A função

JPATH_COMPONENT, ainda na linha 5, é uma constante provida pelo Joomla! que

possui o caminho para o componente, desde que este utilize as convenções de

estrutura e nomeação do Joomla!. No caso do Questoes, o valor de

JPATH_COMPONENT é

diretorioDeInstalacaoDoJoomla/components/com_questo es. A constante DS

também é inicializada pelo Joomla! e contém o valor da barra separadora de

diretórios, que pode ser “/” ou “\”, dependendo do Sistema Operacional utilizado.

Essa constante livra o desenvolvedor de ter que fazer a verificação de qual o

Sistema Operacional em que o Joomla! está instalado. É aconselhável sempre

utilizar a constante DS ao invés do separador em hard code. Também é

aconselhável nunca utilizar uma string com a url para o diretório do Joomla!, ao

invés disso deve-se sempre utilizar a constante JPATH_COMPONENT.

A instrução da linha 8 verifica se há a variável controller na requisição. Se houver,

significa que será utilizado outro controlador ao invés do controlador padrão. A

variável controller é obtida através da função JRequest::getWord(‘controller’) .

Essa função obtém uma variável da requisição, que pode estar contida tanto em

$_POST quanto em $_GET, porém é uma boa prática de segurança sempre utilizar

JRequest::getWord ao invés dos arrays $_POST e $_GET providos pelo PHP,

pois essa função filtra o valor, aceitando somente caracteres de “A” a “Z”, de forma

que impossibilite a injeção de código ou injeção de SQL por parte de usuários mal

intencionados. Caso a variável controller possua algum valor, o controlador

inicializado será do arquivo components/controllers/nomeDoControlador , ao

invés do controlador padrão.

A instrução da linha 21

representa a tarefa (função) que será executada pelo controlador.

contenha valor, será executada

JController::display().

Arquivo simulado.php

Figura 17 _ Arquivo simulado.php (controlador para as telas de Simulado)

A instrução da linha 21 obtém o valor da variável task da requisição

representa a tarefa (função) que será executada pelo controlador.

á executada a task padrão do controlador, que é

JController::display().

Arquivo simulado.php (controlador para as telas de Simulado)


65

da requisição. Essa variável

representa a tarefa (função) que será executada pelo controlador. Caso não

do controlador, que é

Arquivo simulado.php (controlador para as telas de Simulado)

66

O arquivo simulado.php contém a classe controladora da página de listagem de

Simulado e da página de cadastro de Simulado. Como ele não é o controlador

padrão do componente, deve estar em

com_questoes/controllers/simulado.php, e sua classe deve ter a

nomenclatura {NomeDoComponente}Controller{NomeDoControlador}, conforme

descrito no item 4.5.1.

O controlador tem a função tanto de controlar a navegação entre páginas do

componente, quanto de delegar ao modelo tarefas solicitadas pela visão. Ele possui

funções, que o Joomla! trata como tasks. Portanto as funções save e cancel

contidas no arquivo são tasks, que realizam determinada tarefa. Por exemplo, para

executar a função save do controlador Simulado do componente Questoes, a URL

deve ser a seguinte:

index.php?option=com_questoes&controller=simulado&t ask=save.

Na função save, na linha 29, a instrução obtém o model para o controlador

Simulado. A função getModel(‘nomeDoModelo) automaticamente procura o modelo

cujo nome é {NomeDoComponente}Model{NomeDoModelo}. Mas só obtém o

modelo que estiver incluso na lista de modelos deste controlador. E por padrão o

único que já é inicializado como sendo um modelo deste controlador é o modelo de

nome {NomeDoComponente}Model{NomeDoControlador}, que no caso do

Quesões é QuestoesModelSimulado.

Na linha 34 a instrução JRequest::setVar(‘id_simulado’, $id_simulado) , cria

uma variável chamada id_simulado na requisição com valor igual ao valor da

variável $id_simulado. Na linha 35 a instrução inicializa a variável view na requisição

com o valor ‘simulados’. Isso faz com que o Joomla! redirecione para a visão

Simulados após o retorno dessa função.

Arquivo view.html.php

Figura

O arquivo view.html.php

dados do modelo e pass

JView::assignRef. É importante

template por meio de JView::assignRef

como por exemplo JView::assignRef(‘_variavel’, $variavel)

display deste arquivo é a função padrão

controlador. A visão não tem a função de formatar a saída dos dados. Quem faz isso

é o template utilizado pela

{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php

Figura 18 _ Arquivo view.html.php da visão Simulado


view.html.php representa determinada visão. Sua função é obter os

dados do modelo e passá-los para um template, por meio do método

É importante salientar que o nome da variável atribuída ao

JView::assignRef não pode conter under

JView::assignRef(‘_variavel’, $variavel)

deste arquivo é a função padrão, que será executada pela função

A visão não tem a função de formatar a saída dos dados. Quem faz isso

utilizado pela por ela, que por padrão será o arquivo

{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php

67

Arquivo view.html.php da visão Simulado

Sua função é obter os

, por meio do método

o nome da variável atribuída ao

underline em seu início,

JView::assignRef(‘_variavel’, $variavel) . A função

que será executada pela função display do

A visão não tem a função de formatar a saída dos dados. Quem faz isso

será o arquivo com nomenclatura

{NomeDoComponente}/views/{NomeDaVisao}/tmpl/default .php , porém é

posssível setar um arquivo diferente como

requisição layout.

Arquivo de template

O arquivo de template contém

referências a arquivos de estilo ou

CSS e código de marcação HTML.

utilizando $this- >nomeDaVariavel

para o template, ele o acessa da seguinte forma:

objetivo da existência dos

utilizar templates diferentes conforme a necessidade, a fim de poder modificar a

forma como os mesmos dados s

Arquivo do modelo

Figura 19

Ao arquivo simulados.php

ela continua estendendo

JModel. A classe JModelList

posssível setar um arquivo diferente como template através da

contém a lógica da apresentação, é nele que

referências a arquivos de estilo ou JavaScript, códigos JavaScript

código de marcação HTML. Eles acessam os dados atribuídos pela visão

>nomeDaVariavel . Por exemplo, se a visão passa um simulado

, ele o acessa da seguinte forma: $this- >simulado

objetivo da existência dos templates, é possibilitar que uma mesma visão possa

diferentes conforme a necessidade, a fim de poder modificar a

forma como os mesmos dados são apresentados, sem precisar mudar de visão.

19 _ Arquivo simulados.php (modelo de simulados)


simulados.php contém uma classe que estende de

ela continua estendendo JModel indiretamente, pois JModelList

JModelList é também um modelo, mas provê funcionalidades

68

através da variável de

é nele que se encontram as

cript, códigos de estilo

Eles acessam os dados atribuídos pela visão

, se a visão passa um simulado

>simulado . O principal

é possibilitar que uma mesma visão possa

diferentes conforme a necessidade, a fim de poder modificar a

ão apresentados, sem precisar mudar de visão.

Arquivo simulados.php (modelo de simulados)

contém uma classe que estende de JModelList, porém

JModelList é subclasse de

é também um modelo, mas provê funcionalidades

extras, como facilitar a obtenção dos filtros de determinada pesquisa para obter os

dados no banco, listagem de múltiplos itens e facilitar na paginação

itens.

Figura 20

Esse método tem a função de popular variáveis com os valores dos filtros de uma

pesquisa. A instrução

variável da requisição e salva na sessão

entre uma requisição e outra

Há ainda o método getListQuesry()

para buscar a lista a ser exibida, e será utilizada pela paginação sempre que for

requisitada uma nova página desta.

populateState() serão

Arquivos de tabela

a obtenção dos filtros de determinada pesquisa para obter os

listagem de múltiplos itens e facilitar na paginação

20 _ Arquivo simulados.php (método populateState)



A instrução $this->getUserStateFromRequest()

variável da requisição e salva na sessão, a fim de que esses valores não se percam

e uma requisição e outra.

getListQuesry() , que retorna uma consulta que será utilizada


requisitada uma nova página desta. Os filtros salvos durante o método

serão utilizados nesse método como filtros na

69

a obtenção dos filtros de determinada pesquisa para obter os

listagem de múltiplos itens e facilitar na paginação de uma lista de

Arquivo simulados.php (método populateState)


obtém o valor da

, a fim de que esses valores não se percam

que retorna uma consulta que será utilizada


Os filtros salvos durante o método

como filtros na consulta.

São arquivos que represent

operações feitas no banco sobre

JTable{nomeDaTabela}

localizados no caminho {nomeDoComponente}/tables/{nomeDoArquivo}.php

Esses arquivos contêm

construtor recebe o nome da tabela e o nome da sua chave primária.

ver na linha 26, o nome da tabela começa com o prefi

convertido automaticamente pelo Joomla

banco de dados. Isso é necessário pois toda

do Joomla! possui um

instalações diferentes em um mesmo

Figura 21 _ Arquivo tables/simulado.php


arquivos que representam uma tabela no banco de dados, e

operações feitas no banco sobre esta tabela. Devem ter a seguinte nomenclatura:

JTable{nomeDaTabela} e devem estender a classe JTable.

{nomeDoComponente}/tables/{nomeDoArquivo}.php

variáveis que representam cada coluna da tabela

construtor recebe o nome da tabela e o nome da sua chave primária.

ver na linha 26, o nome da tabela começa com o prefixo “#__”. Esse prefixo é

convertido automaticamente pelo Joomla! para o prefixo utilizado pelas

Isso é necessário pois toda tabela de uma determinada

do Joomla! possui um mesmo prefixo, a fim de evitar incompatibilidad

em um mesmo banco. No caso do Questões, que utiliza o

70

a no banco de dados, e facilitam todas as

em ter a seguinte nomenclatura:

. Eles devem estar

{nomeDoComponente}/tables/{nomeDoArquivo}.php .

presentam cada coluna da tabela, e seu

construtor recebe o nome da tabela e o nome da sua chave primária. Como se pode

xo “#__”. Esse prefixo é

! para o prefixo utilizado pelas tabelas no

tabela de uma determinada instalação

prefixo, a fim de evitar incompatibilidade entre

. No caso do Questões, que utiliza o

71

prefixo sugerido pela instalação do Joomla!: o “jos_”; o nome da tabela será

convertido para “jos_quest_simulado”.

4.5.3. Tornando o Questões internacionalizado

O Questões utiliza uma extensão do tipo Linguagem para fins de

internacionalização. Apresentar-se-á a seguir a criação desta extensão.

O Joomla! utiliza a codificação de caracteres UTF-8, porém para evitar problemas

com sua utilização é necessário que o banco de dados ofereça suporte a esta

codificação. Portanto, é aconselhável utilizar o banco de dados MySQL a partir da

versão 4.1.2, pois as versões anteriores não oferecem suporte a esta codificação.

(KENNARD, 2007)

O Joomla! utiliza três pacotes de linguagem, um para frontend, um para backeend e

um para a instalação. Para criar um pacote de Linguagem para o frontend de um

componente é necessário uma estrutura como a seguinte:

Figura

Um pacote de Linguagem

diretório:

{nomedoc omponente}/language/{nomeDoPacote}

ponente}.ini . No caso

com_questoes/language/en

O nome do pacote da Linguagem deve seguir o padrão:

código da linguagem segundo a

especifica que o código de uma linguagem deve ser formado pela junção do nome

abreviado da linguagem (segundo a ISO 639

da região (segundo a ISO 3166

Os arquivos de extensão “.ini” são os que contêm a tradução. O nome dess

arquivos deve ter o padrão:

extensão].ini , onde [tipo de extensão]

A Figura 23 mostra como deve ser um arquivo ini.

Figura 22 _ Estrutura de um paco te de Linguagem


Um pacote de Linguagem de um componente deve ser instalado no seguinte

omponente}/language/{nomeDoPacote} /{nomeDoPacote}.{nomedocom

caso de uma tradução para inglês do Questões, ficaria

com_questoes/language/en -GB/en-GB.com_questoes.ini.

O nome do pacote da Linguagem deve seguir o padrão: [ln-LN]

segundo a Request for Comment 3066


abreviado da linguagem (segundo a ISO 639-2), mais o caractere “

da região (segundo a ISO 3166-1); por exemplo: pt-BR, en-US, fr

são “.ini” são os que contêm a tradução. O nome dess

arquivos deve ter o padrão: [ln- LN].[tipo de extensão]_[nome da

[tipo de extensão] pode ser (“com”, “mod”, “plg”, “tpl”

mostra como deve ser um arquivo ini.

72

te de Linguagem

de um componente deve ser instalado no seguinte

/{nomeDoPacote}.{nomedocom

de uma tradução para inglês do Questões, ficaria

LN], onde [ln-LN] é o

3066 (RFC3066), que


2), mais o caractere “-”, mais o código

fr-FR.

são “.ini” são os que contêm a tradução. O nome desses

LN].[tipo de extensão]_[nome da

“com”, “mod”, “plg”, “tpl”).

Figura

A chave representa a variável

quem será traduzida. Recomenda

e em inglês. O Valor representa a tradução da chave, ou seja, enquanto a chave é o

que será utilizado pelos desenvolvedores

será apresentado ao usuário final

forma de textos, labels ou mensagens.

Após ser inserida uma chave no arquivo de linguagens essa chave está pronta para

ser utilizada no Joomla!. Ela deve ser utilizada através da classe

exemplo, se precisarmos apresentar a

utilizar a instrução JText::_(‘ESCOLHA_UMA_OPCAO’)

Além do frontend, um componente também pode ter uma tradução para o (tanto no gerenciamento do componente quanto no gerenciamento de menus)a sua instalação. O arquivo de linguagem para o componente) seguirá o padrão administrator/la nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n

te}.ini, o arquivo de linguagem padrão administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen

te}.sys.ini . Já o arquivo de tradução da instalação

Figura 23 _ Arquivo ini (arquivo de tradução)


A chave representa a variável que é utilizada na aplicação e nas extensões, é ela

Recomenda-se que elas sejam escritas com letras

O Valor representa a tradução da chave, ou seja, enquanto a chave é o

que será utilizado pelos desenvolvedores, no código do Joomla!, o valor é o que

será apresentado ao usuário final. O valor aparecerá na visualização do sistema

ou mensagens.


no Joomla!. Ela deve ser utilizada através da classe

exemplo, se precisarmos apresentar a label “Escolha uma Opção”

JText::_(‘ESCOLHA_UMA_OPCAO’) .

um componente também pode ter uma tradução para o (tanto no gerenciamento do componente quanto no gerenciamento de menus)

O arquivo de linguagem para o backend (gerenciamento do seguirá o padrão

nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n

o arquivo de linguagem do backend (gerenciamento de menus)

administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen

Já o arquivo de tradução da instalação deve ser inserido no pacote de

73

que é utilizada na aplicação e nas extensões, é ela

se que elas sejam escritas com letras maiúsculas

O Valor representa a tradução da chave, ou seja, enquanto a chave é o

, no código do Joomla!, o valor é o que

na visualização do sistema na


no Joomla!. Ela deve ser utilizada através da classe JText. Por

“Escolha uma Opção” na tela, devemos

um componente também pode ter uma tradução para o backend (tanto no gerenciamento do componente quanto no gerenciamento de menus) e para

(gerenciamento do

nguage/{nomeDoPacote}/{nomeDoPacote}.{nomedocompone n

(gerenciamento de menus) seguirá o

administrator/language/{nomeDoPacote}/{nomeDoPacote }.{nomedocomponen

deve ser inserido no pacote de

74

instalação com o seguinte padrão: language/{nomeDoPacote}/{nomeDoPacote}.ini.

75

5. CONSIDERAÇÕES FINAIS

Como resultado principal deste estudo, demonstraram-se os principais aspectos

relacionados ao desenvolvimento de componentes para a versão 1.6 do Joomla!,

sendo apresentados seu framework, a arquitetura e as convenções de codificação

que ele propõe que sejam utilizados na construção de componentes; ao passo que

discorre-se sobre os benefícios de se utilizar tais padrões. Portanto tem-se agora

uma fonte consistente e centralizada, que apresenta ao desenvolvedor todos os

passos necessários para o desenvolvimento de um componente para o Joomla!, que

siga as boas práticas e os padrões de codificação propostos para este CMS. Além

disso, foi desenvolvido um componente que tem a função de cadastro, publicação e

resolução de questões de múltipla escolha; e poderá ser utilizado por websites que

utilizem o Joomla! 1.6, e que precisem ter essa funcionalidade, como sites de

concursos, vestibulares ou sites de escolas.

Um resultado secundário deste trabalho, mas que terá grande importância para

pesquisas futuras, é o estudo realizado acerca do tema CMS, que possibilitou ter

vários conceitos importantes sobre este tema reunidos em um único trabalho, e

servirá portanto como uma fonte de consulta abrangente mas sucinta sobre CMS.

O componente Questões poderá ter uma grande importância para os websites que

precisem implementar a funcionalidade de resolução de questões. No entanto esse

componente ainda não está completo o suficiente para servir aos requisitos da

maioria dos websites, portanto fica proposto como trabalho futuro a melhoria do

componente Questões, tanto nas funcionalidades já existentes quanto na

implementação de novas funcionalidades.

76

BIBLIOGRAFIA

AIIM. What is Enterprise Content Management (ECM)? . Disponível em: < http://www.aiim.org/What-is-ECM-Enterprise-Content-Management>. Acesso em: 15 mai. 2011.

BATISTA, André Luiz Franca. Proposta de um sistema para ranqueamento de sistemas gerenciadores de conteúdo baseado em análi ses comparativas. 2007. 47f. Monografia (graduação em Ciência da Computação) - Departamento de Ciência da Computação, Universidade Federal de Lavras, Lavras, 2007.

BOIKO, Bob. Content Management Bible. 2. ed., Indianapolis: Wiley Publishing, Inc, 2005.

DIGITAL Purview. Types of CMS. Disponível em: < http://www.digitalpurview.com/types-of-cms/ >. Acesso em: nov. 2010.

FOWLER Martin. GUI Architectures. Disponível em: < http://www.martinfowler.com/eaaDev/uiArchs.html>. Acesso em: 16 mai. 2011.

FRASER, Stepen R. G. Real World ASP.NET: Building a Content Management System. [s.l]: Apress, 2002.

77

IDEALWARE. Comparing open source Content Management Systems: Wordpress, Joomla, Drupal and Plone. Disponível em: < http://www.idealware.org/sites/idealware.org/files/idealware_os_cms_2010_1.pdf>. Acesso em: 14 mai. 2011.

JOOMLA!. Site Oficial da Comunidade Joomla!. Disponível em: < http://www.joomla.org/ >. Acesso em: 28 Nov. 2010.

KENNARD James. Mastering Joomla! 1.5 Extension and Framework Development: The Professional's Guide to Programming Joomla!. Olton: Packt Publishing Ltd., 2007.

NETO Jurmir Canal. Conhecendo mais do Framework Grails . Disponível em: < http://imasters.com.br/artigo/17545/desenvolvimento/conhecendo-mais-do-framework-grails>. Acesso em: 16 mai. 2011.

NEVES Ricardo. As ferramentas de gestão de conteúdo – parte 1. Webinsider, [s.l], mai 2003. Seção Sem Categoria. Disponível em: <http://webinsider.uol.com.br/2003/05/26/as-ferramentas-de-gestao-de-conteudo-parte-1/>. Acesso em: 16 nov. 2010.

ORACLE. Java BluePrints Model-View-Controller. Disponível em: < http://www.oracle.com/technetwork/java/mvc-detailed-136062.html>. Acesso em: 16 mai. 2011.

78

RAHMEL, Dan. Beginning Joomla!: From Novice to Professional. New York: Apress, 2007.

ROMANÍ, Cristóbal Cobo; KUKLINSKI, Hugo Pardo. Planeta Web 2.0. Inteligencia colectiva o medios fast food. México: Grup de Recerca d'Interaccions Digitals,Universitat de Vic. Flacso México. Barcelona / México DF, 2007.

SCARATE, André Luís. Implantação de Gerenciadores de Conteúdo para administrar sites da Assessoria de Comunicação Soci al da Universidade Estadual De Maringá. 2007. 88f. Trabalho de Conclusão de Curso (Especialização em Desenvolvimento de Sistemas para Web) – Universidade Estadual de Maringá, Maringá, 2007.

T-SYSTEMS. ECM - Enterprise Content Management: Do arquivamento eletrônico para a solução de gerenciamento de conhecimento. Disponível em: http://www.t-systems.com.br/tsi/pt/229150/Homepage/Solutions-Industries/Solutions/Horizontal-Applications-&-Transformational-Outsourcing-/ECM---Enterprise-Content. Acesso em: 15 mai. 2011.

WILLIAMS Steve. Enterprise Content Management. Disponível em: <http://www.contentmanager.eu.com>. Acesso em: 28 nov. 2010.

W3C. Internacionalização: Localização vs. Internacionalização. Disponível em: <http://www.w3.org/International/questions/qa-i18n>. Acesso em: 19 mai. 2011.

79

W³TECHS. Usage of content management systems for websites. Disponível em: <http://w3techs.com/technologies/overview/content_management/all>. Acesso em: 18 mai. 2011.

monografia - explorando o desenvolvimento de componentes para o joomla 1.6

Documents