Llibre Blanc CMS

C/ Sancho de Àvila, 52, 6. 3. · 08018 - Barcelona

Tel. 902 88 77 71 | www.cometatech.com ·

Llibre blanc:

Gestió de continguts Solucions obertes

Títol Gestió de Continguts – Solucions Obertes Pàgina Pàgina 2 de 53

ÍNDEX 1 PREÀMBUL ________________________________________ _______________________________________ 3

1.1 Cometa Technologies __________________________________________________________________________________________ 3

1.2 Smile _______________________________________________________________________________________________________ 4

1.3 Aquest llibre blanc _____________________________________________________________________________________________ 5

1.4 Algunes referències de Cometa __________________________________________________________________________________ 6

1.5 Algunes referències de Smile ____________________________________________________________________________________ 7

1.6 Versió 2.1 ___________________________________________________________________________________________________ 8

1.7 Versió 3.0 ___________________________________________________________________________________________________ 8

1.8 Els CMS_____________________________________________________________________________________________________ 9

1.9 Els CMS open source _________________________________________________________________________________________ 10

1.10 Durabilitat, suport ___________________________________________________________________________________________ 10

2 ELS CMS DE SOLUCIONS OBERTES ____________________ _____________________________________ 12

2.1 Mambo, Joomla, Zope _________________________________________________________________________________________ 12

2.2 Spip _______________________________________________________________________________________________________ 13

2.3 Typo3______________________________________________________________________________________________________ 14

2.4 OpenCms __________________________________________________________________________________________________ 14

2.5 eZ publish __________________________________________________________________________________________________ 15

2.6 Jahia ______________________________________________________________________________________________________ 16

2.7 Apache Lenya _______________________________________________________________________________________________ 17

2.8 InfoGlue ____________________________________________________________________________________________________ 18

2.9 Joomla _____________________________________________________________________________________________________ 18

2.10 Drupal ____________________________________________________________________________________________________ 19

3 CONCEPTES FONAMENTALS DE LA GESTIÓ DE CONTINGUTS __________________________________ 20

3.1 Gestió de continguts i gestió de publicació _________________________________________________________________________ 20

3.2 Framework o llest per a utilitzar-se? ______________________________________________________________________________ 21

3.3 Separació de la forma i el fons __________________________________________________________________________________ 23

3.4 Estructura d’articles ___________________________________________________________________________________________ 25

3.5 Pàgines i continguts __________________________________________________________________________________________ 28

3.6 Organització de continguts _____________________________________________________________________________________ 29

3.7 Edició de continguts __________________________________________________________________________________________ 32

3.8 Workflow de validació _________________________________________________________________________________________ 34

3.9 Webdav ____________________________________________________________________________________________________ 36

3.10 Gestió de versions ___________________________________________________________________________________________ 37

3.11 Cicle de vida dels articles _____________________________________________________________________________________ 39

3.12 Publicació _________________________________________________________________________________________________ 40

3.13 Selecció de continguts________________________________________________________________________________________ 41

3.14 Presentació i plantilles ________________________________________________________________________________________ 42

3.15 Personalizació de la presentació ________________________________________________________________________________ 45

3.16 Intercanvi de continguts i sindicació _____________________________________________________________________________ 46

3.17 Mesura i seguiment de l’audiència ______________________________________________________________________________ 47

3.18 Indexació i motor de recerca ___________________________________________________________________________________ 49

3.19 Gestió d’url ________________________________________________________________________________________________ 51

4 SÍNTESI _________________________________________________________________________________ 53


1 PREÀMBUL

1.1 COMETA TECHNOLOGIES

La missió de Cometa és ser el partner referent dels nostres clients per a projectes de comunicació i gestió

empresarial basats en eines Open Source i tecnologies estàndards.

Cometa neix l'any 2000 fruit d'un spin-off del Centre de Serveis Informàtics de la Universitat La Salle, de

Barcelona.

Durant 9 anys Cometa s'ha anat especialitzant en diferents àmbits de negoci basats en eines i tecnologies molt

diverses, totes basades Open Source i estàndards.

Els directius de Cometa sempre han participat en diverses iniciatives no lucratives orientades a impulsar el teixit

empresarial mitjançant l'aplicació de tecnologies obertes i estàndards.

L'any 2005 Cometa s’instal·la al 22 @, districte d'innovació tecnològica impulsada per l'Ajuntament de Barcelona.

L'any 2007 Cometa participa en el projecte de consultoria "RoadMap de programari lliure» de la Generalitat de

Catalunya, permetent assessorar al govern en termes de què metodologies de treball adoptar i amb quines eines

treballar en l'àmbit Open Source.

L'any 2009, totalment consolidats en el mercat nacional, Cometa arriba a un acord per integrar-se al grup Smile,

líder a Europa en integració d'eines Open Source. Amb aquest acord Cometa consolida definitivament el seu

projecte empresarial i dóna un important impuls al seu pla de creixement i millora dels serveis.


1.2 SMILE

El grup Smile, nascut l'any 1991 i amb una facturació anual de 20M €, és líder a Europa en projectes que giren al

voltant d'eines Open Source i estàndards.

Durant la dècada dels 90 es va posicionar com un actor destacat en arquitectures, tecnologies i eines per la

construcció de grans plataformes a internet.

A partir de l'any 2001 el core business de Smile passa a ser la construcció de sistemes d'informació, web i

plataformes basades en les millors solucions Open Source del mercat. Això implica invertir fortament en identificar

les solucions Open Source que juntament amb ser madures, estables i segures, aportin un benefici real a les

empreses. Una mostra d'aquesta inversió són els Llibres Blancs de Smile, estudis objectius i neutrals sobre

diferents àmbits del món Open Source i que s'han convertit en un punt de referència per als decisors tecnològics

Europeus.

Amb oficines centrals a París, Smile és present en cinc països i té com a objectiu obrir mercat en quatre més en

els propers 3 anys.

Està format per un equip de 340 persones, dedicades a prestar serveis en les diferents capes de valor d'un

projecte tecnològic basat en Open Source: Consultoria, Creativitat i Disseny Gràfic, Integració i Desenvolupament

d'Eines, Allotjament i Manteniment d'Aplicacions.

Les seves principals referències són: Bureau Veritas, Christian Dior, JC Decaux, Renault; Lagardere, Mondadori,

Nestlé, Via Michelin, Laboratoris Merck, Lafarge, Avis, Le Figaro, Eurosport, Yves Rocher, Seat, i molts altres.

Des d’ aproximadament l'any 2000, Smile porta a terme una activa vigilància tecnològica que li permet descobrir

els productes més prometedors de solucions obertes, de qualificar-los i avaluar-los, amb l'objectiu de proposar als

seus clients els productes més adequats, més robustos i els més perennes .

Aquesta iniciativa ha donat origen a tota una gamma de llibres blancs que cobreixen diferents camps d'aplicació.

La gestió de continguts (2004), els portals (2005), Business Intelligence (2006), els Frameworks PHP (2007), la

virtualització (2007), la gestió electrònica de documents (2008), i els ERPs (2008).

Cadascuna d'aquestes obres presenta una selecció de les millors solucions de continguts oberts en un camp

específic, les seves qualitats respectives, així com comentaris i reaccions a partir de l'experiència d'ús.

A mesura que vagin sorgint i consolidant-se solucions obertes sòlides i guanyin nous terrenys, Cometa proposarà

als seus clients beneficiar-se d'elles sense cap risc. Amb el grup Smile, Cometa es posiciona com el proveïdor

d'elecció per acompanyar a les empreses més grans en l'adopció de les millors solucions obertes.


1.3 AQUEST LLIBRE BLANC

Aquest document no és una simple comparació entre les solucions obertes CMS que hem seleccionat. Ens

esforcem també en fer una introducció als conceptes fonamentals dels CMS i a la seva aplicació. La gestió de

continguts no és només un problema d'eines, abans d'escollir un instrument, és necessari haver analitzat bé els

objectius del projecte.

Per aquesta raó proposem, per a cada un dels conceptes més importants, la nostra anàlisi dels reptes i opcions

que diferencien les eines del mercat.

Després d'aquesta anàlisi, intentem posicionar cada un dels CMS dins de l'estudi.


1.4 ALGUNES REFERÈNCIES DE COMETA


1.5 ALGUNES REFERÈNCIES DE SMILE

• Intranets - Extranets

o Société Générale - Caisse d'Épargne - Bureau Veritas - Commissariat à l'Energie Atomique

o Visual - Vega Finance - Camif - Lynxial - RATP - AMEC-SPIE - Sonacotra - Faceo - CNRS

o AmecSpie - Château de Versailles - Banque PSA Finance - Groupe Moniteur - CIDJ - CIRAD

o Bureau Veritas - Ministère de l’Environnement - JCDecaux - Ministère du Tourisme

o DIREN PACA - SAS - Institut National de l’Audiovisuel - Cogedim - Ecureuil Gestion

o IRP-Auto - AFNOR - Conseil Régional Ile de France - Verspieren - Zodiac – OSEO - Prolea

o Conseil Général de la Côte d’Or - IPSOS - Bouygues Telecom - Pimkie Diramode

o Prisma Presse - SANEF - INRA – HEC

• Internet, Portades informàtiques i de e-Commerce

o cadremploi.fr - chocolat.nestle.fr - creditlyonnais.fr - explorimmo.com - meilleurtaux.com

o cogedim.fr - capem.fr - editions-cigale.com - hotels-exclusive.com - souriau.com - pci.fr

o gdf.fr/presse - dsv-cea.fr - egide.asso.fr - osmoz.com - spie.fr - nec.fr - sogeposte.fr

o metro.fr - stein-heurtey-services.fr - bipm.org - buitoni.fr - aviation-register.com - cci.fr

o schneider-electric.com - calypso.tm.fr - inra.fr - cnil.fr - longchamp.com - aesn.fr

o Dassault Systemes 3ds.com - croix-rouge.fr - worldwatercouncil.org - projectif.fr

o editionsbussiere.com - glamour.com - fratel.org - tiru.fr - faurecia.com - cidil.fr - prolea.fr

o ETS Europe - ecofi.fr - credit-cooperatif.fr - odit-france.fr - pompiersdefrance.org

o watermonitoringaliance.net - bloom.com - meddispar.com - nmmedical.fr - medistore.fr

o Yves Rocher - jcdecaux.com - cg21.fr - Bureau Veritas veristar.com - voyages-sncf.fr

o eurostar.com - AON conseil - OSEO - cea.fr - eaufrance.fr - banquepsafinance.com

o nationalgeographic.fr - idtgv.fr - prismapub.com - Bouygues Construction

o Hachette Filipacchi Media - ELLE.fr - femmeactuelle.fr - AnnoncesJaunes.fr

• Aplicacions de negocis, sistemes documentals, intel·ligència de negocis

o Renault - Le Figaro - Sucden - Capri - Libération - Société Générale - Ministère de l’Emploi

o CNOUS - Neopost Industries - ARC - Laboratoires Merck - Egide - Bureau Veritas

o ATEL-Hotels - Exclusive Hotels - Ministère du Tourisme - Groupe Moniteur - Verspieren

o Caisse d’Epargne - AFNOR - Souriau - MTV - Capem - Institut Mutualiste Montsouris

o Dassault Systemes - Gaz de France - CFRT - Zodiac - Croix-Rouge Française

o Centre d’Information de la Jeunesse (CIDJ) - Pierre Audoin Consultants - EDF R&D


1.6 VERSIÓ 2.1

Amb més de 10.000 descàrregues, la versió 1 d'aquest llibre blanc es remunta al 2004 en francès. La versió 2.1

suposa una revisió important respecte a versions anteriors.

Per començar, es va eliminar del panell la solució Redhat CMS , per diferents raons: Redhat s'havia convertit en

Byline, sota la responsabilitat del consorci ObjectWeb, però la transferència estava lluny de ser finalitzada i el

desenvolupament semblava detingut. A més, ObjectWeb tenia ja una solució de portals i de gestió de continguts,

amb la integració de eXoplatform, un projecte molt més dinàmic. En aquest context ens semblaria difícil creure

que una solució tan poc present perdurés.

No obstant això, es va integrar Apache Leny i InfoGlue , dos productes de l'entorn Java, que responen a

necessitats completament diferents. Aquestes dues solucions són de qualitat i tenen ja diverses referències al seu

favor, el que permet completar l'oferta de solucions obertes J2EE, actualment relativament reduïda.

Finalment, actualitzem els nostres comentaris amb les evolucions importants de diferents solucions. Typo3 havia

evolucionat considerablement , amb les extensions TemplaVoila per a les estructures de continguts, i les

extensions de gestió de versions i de flux de treball que fins aleshores faltaven. OpenCMS també va aprofitar la

seva última versió per fer-se amb una estructura de continguts, mentre que eZ publish aporta un sense nombre

de millores impressionants en les seves versions 3.6 i 3.7

1.7 VERSIÓ 3.0

Després de 25.000 descàrregues en Francès, ja és aquí una major actualització d'aquest llibre, per primera

vegada en català. Vam voler afegir dues eines al panell ja extens de solucions: Joomla i Drupal , eines prou

generalitzades i amb semblances actives i fèrtils. Aquestes dues eines gaudeixen d'una simplicitat d'integració, de

configuració i d'utilització, el que ha permès crear una gran base de referències en el medi associatiu, personal i

de petites empreses.

Aquestes eines han demostrat la seva estabilitat i la seva maduresa. La seva simplicitat, de vegades amb

funcionalitats avançades, pot constituir una elecció alternativa a la utilització d'eines més completes però també

complexes de portar a terme.

No obstant això, hem retirat els CMS Cofax , i PHPNuke , que ja no es mantenen actius i les seves funcionalitats

són actualment menys completes que les propostes per altres solucions.

Altres eines també han incorporat nombroses millores des de la versió anterior d'aquest Llibre Blanc. Alguns

exemples són:


• eZ Publish 3.9 : suport de clustering, gestió multilingüe avançada, Single Sign-On ... Actualment la última

versió estable és la 4.2, que encara que no es compara en aquest estudi, millora de forma substancial el

rendiment i afegeix importants prestacions com eZ Flow (gestor de portades dinàmiques), eZ Find

(cercador corporatiu basat en Solre i Lucene) i amplia la gestió de fluxos de treball i els estats dels

objectes de contingut.

• Typo3 4.1 : espais de treball, control d'accés front office, …

• I InfoGlue 2.5 : Editor d'imatges, serveis de xarxa, nous mòduls d'autenticació …

• Jahia 5 : Back-office Ajax, nous portals, Import Export XML, fluxos de treball específics multi nivells,

compatibilitat JSR168, detadatos, editor FCKEditor, hibernate, cache ESI, clustering, …

1.8 ELS CMS

Actualment un lloc web, ja sigui Intranet o Internet, ha de ser administrat d'una manera interactiva, és a dir, ha

d'oferir una interfície per permetre als seus responsables definir noves pàgines, noves opcions així com

l'actualització i reorganització de la informació.

Però més enllà de les necessitats específiques d'un lloc web, algunes empreses identifiquen la necessitat

d'establir i administrar un marc referencial de continguts, sobre el qual es recolzaran diferents publicacions, tant en

la xarxa com en altres mitjans de comunicació.

Per descomptat, són nombroses les eines disponibles per satisfer aquesta necessitat. En la gamma de productes

CMS (Content Management Systems) es poden distingir:

D'una banda els productes orientats només per a la gestió de llocs web, simples, llestos per utilitzar, amb

possibilitats d'extensió generalment limitades, per una altra, els productes de més alta qualitat, que permeten

construir un veritable marc de referència de continguts en una empresa , definir processos de gestió associats, i

distribuir aquests continguts sobre una varietat de mitjans de comunicació.

Actualment, el primer camp constituït pels CMS integrats, està totalment conquerit pels productes derivats de les

solucions obertes com Mambo, Joomla, Typo3, Drupal o Spip. Aquests productes són de tal qualitat i de tal

dinamisme, per a necessitats concretes, que cap proposició comercial pot competir amb ells.

Per contra, la millor qualitat pel que fa als CMS era fins fa poc el domini de productes comercials com ara

Documentum, Vignette o Interwoven. Però solucions com Jahia, eZ publish i Infoglue, aporten alternatives de pes

en el camp del Content Management Empresarial.

Des de l'any 2001 fins ara, Cometa i el grup Smile ha construït una experiència única en l'àmbit de la gestió de

continguts i en particular un fort coneixement de les millors solucions obertes.

Aquesta és la raó per la qual proposem aquest llibre blanc, que correspon a una mostra d'aquesta experiència.


Diverses solucions de codi obert prou diferents són esmentades a manera d'exemple per il·lustrar la manera com

són tractats els principals conceptes de la gestió de continguts.

Tingueu en compte que primer hem realitzat una estr icta

selecció, de manera que els productes presentats aq uí,

constitueixen cadascun d'ells una solució de qualit at. Seran

posteriorment les especificitats de cada projecte q ue ens

orientaran cap a una o altra d'aquestes solucions.

1.9 ELS CMS OPEN SOURCE

Un analista de Gartner Group va assenyalar que en la gestió de continguts, "la gent actualment no veu cap

benefici de pagar els preus elevats dels productes comercials més importants, i estan a la recerca d'alternatives

de més baix cost.”

Però com subratlla l'analista John McGrath: «els avantatges de les solucions obertes no es limiten a l'aspecte

econòmic. La gestió de continguts, per la seva mateixa naturalesa, requereix una part important d'adaptacions

específiques i tenint accés al codi font, es poden realitzar noves funcions com definir un nou tipus de continguts,

directament en el codi, cosa que no és possible amb altres eines pròpies..»

Des de fa alguns anys, els CMS de codi obert han estat adoptats i estesos per les grans comptes, així com ho

demostren les referències del grup Smile. Sovint, a causa de la revisió d'un projecte o la renovació d'un contracte

de suport d'un producte propi en servei després d'alguns anys, es consideren les alternatives basades en

solucions obertes, i els avantatges econòmics, es deixen veure de manera indiscutible.

1.10 DURABILITAT, SUPORT

Al triar un producte sobre el qual es construirà la totalitat o una part del seu sistema d'informació, la qüestió de la

durabilitat és a vegades més important que la llista de prestacions.

En aquest sentit, les solucions obertes ofereixen dos avantatges importants:

� En primer lloc, la seva supervivència no depèn de la seva rendibilitat, o consideracions de màrqueting.

Mentre el públic s'interessi, el producte viurà...

� A continuació, la lliure disposició de fonts és una garantia fonamental de la durabilitat, tot i que -cal

destacar- no és necessari que el client les domini.

Cal tenir en compte que un editor de solucions CMS com REEF, que havia estat una de les principals empreses

del mercat, es va enfonsar un dia, deixant als seus antics clients despullats, sense tenir un altre remei que

reconstruir amb urgència els seus llocs web, amb altres eines. Hi ha nombrosos exemples similars en els darrers


anys: un nom, un fabricant, una llicència, fins i tot referències ... no són garanties de la durabilitat. La fi anunciada

del pioner NetPortal és un nou testimoni.

És cert que el fet de ser una solució oberta no és una garantia en si mateixa d'eterna joventut, certes solucions

poden perdre lentament la seva comunitat i dinamisme. Però una cosa és segura: una solució oberta no s'acaba

mai d'aquesta manera, d'un dia per l'altre, i més una empresa que s'ha construït en base a una solució oberta

conserva sempre, juntament amb les fonts, el coneixement per fer que el seu sistema perduri com a mínim alguns

anys..

Pel que fa al suport, les especificitats de les solucions obertes són actualment ben conegudes. Ofereixen un

suport a dos nivells: d'una banda una comunitat amb una activitat que es recolza en un lloc de referència, on estan

disponibles les descàrregues o downloads i les fonts, per descomptat, però també el pla d'evolucions, els errors

reportats, els mailing-lists de suport. Aquest suport comunitari no és contractual, però és molt fort. Pot ser

complementat per un suport d'una empresa com Cometa, que sí que pot fer-ho contractual.

Al costat de les solucions obertes veritablement comunitàries existeixen també les solucions que provenen dels

fabricants, empreses comercials amb finalitats lucratives, que han optat per una difusió sota llicència de solucions

obertes. La distribució gratuïta de productes permet als fabricants donar a conèixer els seus productes el més

àmpliament possible. Aquest model de negoci es recolza sobre una prestació de suport i d'assessoria.


2 ELS CMS DE SOLUCIONS OBERTES

2.1 MAMBO, JOOMLA, ZOPE

Hi ha una oferta interessant de CMS d'entrada a la gamma de l'entorn PHP. Productes com Spip , Mambo o

Joomla responen a les funcions de base de la gestió de continguts i han de considerar-se per a la construcció de

certs llocs.

Mambo i Joomla són eines per a la gestió de llocs Web molt eficients i de molt fàcil accés. Igual que altres eines

d'aquest tipus, tenen molts mòduls llestos per al consum, i pràctics per als llocs de comunitat: llibre de visites,

fòrum, galeria de fotos, bloc, etc. La seva simplicitat d'ús permet a més crear llocs gràficament exitosos, fin i tot

pels que no pertanyen al sector informàtic.

En termes de pura gestió de continguts, SPIP, Mambo i Joomla són, però, limitats, especialment en l'estructuració

del contingut, la classificació i la transversalitat de la informació, la multi-ubicació dels continguts, els canals de la

validació. .. en poques paraules, tot el que fa que una eina de gestió de continguts sigui considerada professional.

Tot i així, aquestes eines PHP mereixen consideració, i són solucions apropiades per a determinats llocs. Hem fet

una selecció i conservat només aquelles que tenen un posicionament únic, és a dir que cada una d'elles és la

millor resposta a una categoria de necessitat.

Així és com vam retenir Spip , Joomla , Drupal , Typo3 i eZ publish en la classificació que tractem aquí, deixant

també un lloc a les solucions del món de servidors Java.

Finalment, no podem parlar de CMS sense esmentar Zope, almenys per evitar atraure la ira de molts fans

d'aquest producte.

Zope és un servidor d'aplicacions molt complet, que va més enllà de la funció CMS. Tothom està d'acord a pensar

que pràcticament el seu únic defecte és haver estat construït en un entorn Python. És cert que les competències

són escasses per al desenvolupament o manteniment en Python, i això probablement no millorarà. És la raó per la

que vam decidir no mantenir Zope entre les solucions CMS privilegiades, ja que volem estar en disposició de

completar o d'adaptar les funcions originals de l'eina quan sigui necessari. Addicionalment, el fet que Zope CPS

hagi estat interromput pel seu principal promotor Nuxeo va confirmar l'abandonament progressiu d'aquest entorn.


2.2 SPIP

Spip és un veritable CMS, amb les principals funcionalitats que es poden esperar. Originalment, Spip era

principalment utilitzat pels internautes per gestionar el seu lloc web personal, o pels llocs d'associacions, però Spip

va créixer i ara és utilitzat per organismes privats o públics, per gestionar els seus llocs web professionals. Spip és

un projecte francès de codi obert, i la seva comunitat pot ser qualificada d'activa, té diverses versions per any i

centenars - o més aviat milers - de membres.

Spip és un dels pocs CMS que disposa de diversos milers de referències al món. Aquest èxit s'explica per la

simplicitat del producte : simplicitat d'ús, però també simplicitat de desenvolupament i adaptació.

En contrapartida a aquesta simplicitat, Spip presenta algunes limitacions pel que fa a les funcionalitats de gestió

de continguts, el que indiscutiblement el limita al món de les eines de gestió de continguts no corporatius. Hem de

tenir en compte també que Spip compta amb una interfície d'administració completament multilingüe, traduïda en

més de vint idiomes, incloent àrab, esperanto, rus i fins i tot xinès.

Paral·lelament a Spip, el projecte Spip-Agora es va desenvolupar, esponsoritzat per un projecte del govern

francès, amb la intenció d'afegir noves funcionalitats al projecte Spip pel seu ús dins de l'administració de

projectes més complexos.

Les funcionalitats addicionals, com ara l'arborescència de paraules o la personalització del front-office, són molt

interessants.

El projecte Àgora és ara un projecte de codi obert diferent de Spip (un fork), ja que les decisions tècniques d'Àgora

impedeixen la fusió dels dos projectes. Àgora està disponible per a la seva descàrrega sota llicència GPL. La

comunitat Spip s'assegura de la durabilitat del producte, però Spip-Agora mai ha pogut construir una comunitat

similar, i per tant, perd posicions.

Smile ha construït diversos llocs amb Spip, particularment un generador de llocs Spip per a les delegacions de la

Creu Roja Francesa, o pel lloc de Fratel, una xarxa de parla francesa per a la regulació de les telecomunicacions.


2.3 TYPO3

Typo3 és el fruit de diversos anys de treball d'un guru danès de nom Kasper Skårhøj. El producte va néixer a

finals del 2000, i des d'aleshores s'ha desenvolupat una comunitat molt activa, en particular en els països

germànics.

En termes de funcionalitats incloses en el producte , Typo3 és una de les eines més riques que hem trob at

avui en dia . Proposa gairebé tot el que podríem desitjar i amb un nivell d'acabat excepcional. Gestió de drets i de

contribucions, plantilles, etc. tot això, amb poques limitacions.

Entre les funcionalitats que ofereix Typo3 podem citar la manipulació d'imatges, que li permet canviar la mida de

les imatges, crear vinyetes i també generar dinàmicament els títols de les mateixes.

Un dels punts forts de Typo3 és la seva extensibilitat a través de mòduls. Un mòdul pot afegir un conjunt de

funcionalitats, però també pot modificar una funcionalitat ja existent, sense modificar el codi de Typo3, i per tant,

pot ser compatible amb versions futures de Typo3.

Al lloc del producte es poden trobar milers de referències . Smile ha desenvolupat més de 40 llocs amb Typo3, i

ha realitzat un gran nombre de sessions de capacitació i de traspàs de coneixement per ajudar a altres

integradors.

Typo3 va ser seleccionat per Dassault Systèmes per construir la seva intranet. En aquesta ocasió, un treballador

de Smile va tenir el privilegi de treballar al costat de Kasper en aquest ambiciós i apassionant projecte.

Smile ha utilitzat Typo3 per al lloc Internet de la CNIL, l'intranet del Castell de Versalles, l'Institut Nacional de

l'Audiovisual, PROLEA, AmecSpie, Glamour.com, Face, PSA Peugeot Citroën, IPSOS, le3 Crédit Coopératif,

Dassault Systèmes, SAS, l'AESN, CIDIL, ETS, amue, la Regió Ile de France, Jaccede.com, ODIT France, etc.

2.4 OPENCMS

OpenCms és l'eina CMS de l'agència web sueca Framfab, i en particular de la seva filial alemanya. És un producte

de gran importància, sòlid, que representa un important esforç de desenvolupament.

A causa dels problemes de Framfab, el producte semblava no funcionar, però les últimes versions demostren que

la dinàmica de desenvolupament continua, amb un suport de JSP i taglibs JSTL, i sobretot, amb el fet d'haver

tingut en compte continguts estructurats, en format XML. Un llibre publicat en anglès està disponible i mostra

la relativa vivacitat d'aquesta eina.


OpenCms està construït en un marc de treball Java e specífic, amb la perspectiva d'extensió . Així, encara

que les funcions de base estan preparades per a utilitzar-.se, qualsevol tipus de desenvolupament sofisticat hauria

de realitzar-se basant-se en l'extensió de tipus Java.

Una de les característiques de l'eina és un back-office en què el grafisme reprodueix pràcticament una interfície

Windows : estructura d'arbre, menús contextuals, finestres de diàleg, etc. Molt seductor des del pla estètic, la

interfície és una mica pesada en l'ús. Des de la versió 6, la eina permet també editar els continguts en front-office,

sense passar pel back-office. Però aquesta funcionalitat queda reservada a casos molt simples, i no per

l'administració completa de continguts.

O OpenCms posseeix algunes excel·lents referències de llocs 'corporatius', majoritàriament a Alemanya.

Anomenen particularment el lloc de Essilor Alemanya: www.essilor.de, el lloc d'un fabricant d'equips per a

automòbils: www.newtron.net, el lloc de Sumitomo Canadà: www.sumitomocanada.com, el lloc de l'Unicef a

Holanda : www.unicef.nl …

Smile va integrar OpenCms per a UDF, i per a les Ediciones Francis Lefebvre.

2.5 EZ PUBLISH

eZ publish es distingeix d'altres CMS de solucions obertes per les seves possibilitats de configuració i

d'extensió : es presenta com una eina llista per a utilitzar-se però també com un marc de treball de

desenvolupament per aconseguir noves aplicacions de negocis.

Pel que fa als punts fonamentals per a la gestió de continguts, eZ publish és una de les eines més

poderoses disponibles en codi obert : continguts estructurats, workflow, categorització, gestió de versions.

eZ publish permet crear tipus de continguts en línia. En uns quants clics i formularis, és possible crear el tipus de

contingut 'Acta de reunió "o" Actualitat "o" Fitxa bibliogràfica. El primer contingut serà compost d'un títol, un

número de projecte, data, llista de participants, cos del text ... El segon contindrà només un títol i un petit text. El

tercer, serà més complex.

eZ publish afavoreix l'orientació a objectes al màxim, fent de cada contingut un objecte i aplicant-li tots els

mètodes disponibles: multi-ubicació, diversitat de versions, multilingüisme, drets d'accés, workflow. Aquesta noció

fa que sigui un CMS altament personalitzable.

En quant a l'aspecte tècnic, eZ publish està desenvolupat en PHP, funciona sobre Apache i MySql (també

PostgreSql), així com Oracle i Microsoft SqlServer), implementa el protocol WebDAV, permet tres vistes diferents

en els arxius i separa completament contingut i presentació.


Cometa és el principal integrador d'eZ publish en el mercat Espanyol, amb desenes de referències entre les quals

destaquen: Institut Cartogràfic de Catalunya, Random House Mondadori, RBA Editores, Tecnocasa, MC

Ediciones, Teyco, Madaus, Flumotion, Comunicalia, Ajuntament de Molins de Rei, RESA, Cidob, WPA, Col·lectiu

Ronda,…

A la vegada, Smile França ha utilitzat eZ publish en més de 50 projectes, incloent Bouygues Telecom, Voyages-

Sncf.com, NationalGeographic.fr, Eurostar.com, l'INRA, le CIRAD, Zodiac, ossi, Hospital Saint-Camille, De

Dietrich, Prisma Presse, Prisma Pub, Femme Actuelle, Elle, le Groupe Moniteur, Gîtes de France, CEA, Altavia,

Hachette Filipacchi, GPdis, AEP, Degrémont, DxO, UCANSS, l'UDF, Merkur, CNDP, Ecureuil Gestion, Institut de

l'élevage, Suez environnement, Air Pays de Loire, Amnesty International, Come and Stay, Jour du Seigneur,

Souriau, Institut Français du pétrole, National Geographic, Motorpress, GS1, Cnopos, Sport24, …

2.6 JAHIA

Jahia és un producte franco-suís, que té un posicionament particular en el món dels portals i dels CMS J2EE. Això

té dos motius:

Primerament, en termes de llicència. Hi ha una versió «Community», genuïna solució oberta, però que no és

freqüentment utilitzada. Per a les versions comercials, les fonts es distribueixen, però la llicència no és

veritablement una solució oberta (a partir de 5M € per servidor). La llicència es diu «col·laborativa», en el sentit

que el client final pot demanar noves funcionalitats i deduir el cost del desenvolupament del preu de la llicència.

Els nous desenvolupaments són integrats llavors en les noves versions del producte.

En segon lloc, en termes de posicionament, ja que Jahia és una de les poques solucions que reuneix un

portal J2EE i la gestió de continguts en un product e únic, perfectament integrat i a un preu molt raonable.

Vam voler fer figurar Jahia en la nostra comparativa CMS de codi obert, ja que constitueix una excel·lent

alternativa a les solucions de portals de grans fabricants. La possibilitat de veure i de modificar el codi font de

Jahia assegura la durabilitat i l'adequació d'aquesta eina a les necessitats particulars.

Una de les forces de Jahia és reunir CMS i portal a un tot perfectament empaquetat fàcil d'administrar. El

compliment d'estàndards tècnics, principalment de la norma JSR 168, assegura una perfecta compatibilitat i

sobretot la capacitat d'integrar «portlets" que donin accés a les aplicacions internes de l'empresa.

Jahia està llest per a utilitzar-se i generalment no necessita cap desenvolupament en la seva integració. És

lliurement descarregable, Jahia té un nivell d'acabat impressionant: s'instal·la en alguns minuts, llest per a

funcionar. Això demostra el nivell d'acabat de l'eina, a més de la seva riquesa funcional.

Jahia es distingeix d'altres CMS per la seva interfície d'administració de continguts, incorporada al propi lloc. Un

cop identificat, s'obté l'accés a les funcions de valor afegit, modificació i eliminació, directament sobre el lloc, a


l'interior de les pàgines i els menús. Aquesta manera de gestió aporta una veritable simplicitat per a l'usuari, que

veu i entén directament on ha de modificar la informació.

El grup Smile ha utilitzat el portal Jahia per Bouygues Immobilier, Valorissimo, Arjowiggins, Eutelsat, Beauté

Prestige International, Veolia Eau, Académie de Rennes, Conseil Régional d’Ile de France, SANEF, Groupe

COLAS, Fondation d’Auteuil, Académie de Créteil, IRP Auto, Pimkie-Diramode, AFNOR, OCP, Conseil Général de

la Côte d’Or, Diagnostica Stago, Conseil Régional du Centre, Adoma, Chambre des Notaires de France…

2.7 APACHE LENYA

Apache Lenya és una eina a part en el món de la gestió de continguts. Integrat a la fundació Apache, és un

producte de Wyona CMS, d'origen suís, i compta amb molts llocs (www.nzz.ch, www.unipublic.unizh.ch,

www.computerworld.ch, ...). La fase d'incubació prèvia a la integració a Apache va permetre comprovar el

dinamisme i la serietat de la comunitat al voltant de Lenya.

Lenya és un programari de gestió de continguts o de documents, desenvolupat en Java, basat en el marc de

treball Cocoon i que manipula continguts XML.

Una de les particularitats de Lenya és que totes les dades que utilitza són emmagatzemats en fitxers XML, fins i

tot les informacions relatives a l'estructura com els grups i els usuaris. Lenya no necessita d'una base de dades

per funcionar. Els fitxers XML estan organitzats en arbre i es despleguen en HTML - o en un altre format -

mitjançant fulls d'estil XSL.

Un simple navegador n'hi ha prou per poder crear, modificar, suprimir documents XML. Un cop identificat, es pot

navegar en l'estructura de documents, fer una recerca per trobar el document desitjat, i realitzar les accions

administratives necessàries.

Lenya permet definir diverses estructures de documents XML mitjançant la utilització d'esquemes XSD o

RelaxNG . Es pot definir un model estricte per a una notícia (títol, data i text), o bé, un model més ampli per a un

document genèric (un document Word) permetent fer paràgrafs, títols 1, títols 2, separacions, o per definir un

model XHTML...

La modificació de continguts XML es fa mitjançant e ls editors wysiwyg integrats a la interfície, resultants de

projectes separats de codi obert: BXE, que es recolza en un esquema RNG de definició XML, o Kupu per XHTML

únicament.

El grup Smile ha posat en marxa Apache Lenya en tres projectes de bases documentals Xml, per a Pierre Audoin

Consultants, le CIDJ et EDF. El sistema permet generar documents estructurats, complexos, associats a circuits

de validació complexos, i s'utilitza per a substitu ir eines com Microsoft Word. Cal tenir en compte qu e

Michael Wechner, el creador de Lenya, va col·laborar amb Smile en la realització d'un d'aquests projectes.


2.8 INFOGLUE

InfoGlue és una eina d'origen suec, que compta amb nombrosos avantatges:

• Avantatges tecnològiques: InfoGlue està desenvolupat en Java, i pot utilitzar indistintament bases de

dades MySql, Oracle, Microsoft Sql Server, PostgreSQL o DB2. InfoGlue integra l'eina de codi obert

anomenada Pluto , el que li permet acceptar mòduls d'extensió. I InfoGlue integra l'eina de flux de

treball de codi obert OpenSymphony , el que li permet també configurar qualsevol flux de treball en

XML.

• Avantatges funcionals: InfoGlue permet configurar sense desenvolupar nous tipus de continguts i de

categories, dues funcions essencials de la gestió de continguts d'alta qualitat. Les altres funcionalitats

estan també resoltes de forma satisfactòria.

El desenvolupament al voltant d'aquesta eina és dinàmic i amb diverses actualitzacions importants per any. La

versió 2.5, que va sortir el 2007 millora el back office, la interoperabilitat i les prestacions.

Tot i que el projecte s’hagi iniciat el 2003, és poc conegut, però la seva implementació en les solucions de portals,

afavoreix la seva promoció.

En el món Java, InfoGlue és la solució que faltava en la gamma de solucions obertes . D'instal·lació i

utilització simples, gratuïta, configurable i extensible, InfoGlue respon a necessitats diverses, per a llocs a la

xarxa, però també per utilitzar contingut d'empreses.

2.9 JOOMLA

Joomla és un CMS desenvolupat a partir del CMS «Mambo». Va ser creat com a resultat a les diferències entre

els programadors principals i l'empresa coordinadora del desenvolupament. Actualment, la majoria de

programadors i de la comunitat, es concentren a Joomla , el que inclina la balança a favor seu.

Aquesta eina es diferencia principalment per la usabilitat de la seva interfície d'administració . El lema és "donar

el control total del producte a una persona no tècnica". Creació de pàgines, categorització, cerca, accés a

estadístiques, url significatives així com nombrosos mòduls que estan directament integrats i no requereixen

coneixements específics per a la seva aplicació.

No obstant això, Joomla no permet utilitzar diferents tipus de continguts, i no podrà ser utilitzat quan es tingui una

forta necessitat de re-estructurar-los.


Aquest CMS s'ajusta perfectament a llocs personals encara que també pot respondre a les necessitats d'alguns

llocs professionals.

2.10 DRUPAL

Drupal és un CMS amb múltiples facetes. Creat per formar part d'un bloc col·lectiu, actualment té aplicacions més

variades: pot ser un portal comunitari o un lloc corporatiu, utilitzar-se en intranet o en llocs d'e-commerce.

La força d'aquest CMS és la seva extensibilitat. Hi ha molts mòduls fàcilment (fòrum, galeria, formulari

d'enquesta, butlletí de notícies, correu electrònic, xat, enquestes, pagament en línia, calendari compartit, etc.).

Pel que fa a la gestió de continguts, Drupal se situa entre Joomla i eZ Publish. El seu punt fort: la interfície

d'administració li permet crear fàcilment nous tipus de contingut estructurats .

Drupal integra un sistema de plantilles PHP (molt flexible), la gestió de drets dels usuaris, el multi posicionament

dels continguts, i altres funcionalitats com la recerca i les estadístiques.


3 CONCEPTES FONAMENTALS DE LA GESTIÓ DE CONTINGUTS

3.1 GESTIÓ DE CONTINGUTS I GESTIÓ DE PUBLICACIÓ

La majoria de les vegades es reuneix en una mateixa eina la gestió de continguts i la gestió del lliurament

d'aquests continguts. En anglès, es refereix a les nocions de Content Management per una banda, i Content

Delivery per l'altre.

Les eines CMS més simples, combinen voluntàriament

aquestes dues funcions: el seu objectiu específic és utilitzar

els continguts destinats a formar un lloc a la xarxa, i el seu

funcionament és considerablement simple gràcies a

aquesta associació.

En el sentit

més

estricte,

però, convé

distingir la gestió de continguts i la publicació: la gestió de

continguts consisteix a construir i administrar una base de

continguts, sense presagiar la utilització d'aquest contingut.

Aquests continguts poden servir per construir un lloc a la xarxa, o

més llocs diferents alimentats per la mateixa base però presentant

seleccions de continguts diferents. O bé diferents llocs responent a

línies gràfiques diferents.

Però aquests continguts podrien també ser estructurats sobre

altres mitjans: en la construcció d'un catàleg sobre paper, per

exemple. O bé, la mateixa estructura de continguts pot ser

construïda amb la perspectiva de gestió del coneixement però

sense propòsit de publicació.

Pel que fa a la publicació, aquesta consisteix en reproduir una selecció de continguts provinents d'un origen en

algun mitjà en particular, com per exemple per elaborar un lloc web. Detallarem les modalitats d'aquesta funció

més endavant.


Content Repository

Framework Java orientat CMS

Eines Content

Management

Eines Content

Delivery

Eines

específiques

Eines framework

3.2 FRAMEWORK O LLEST PER A UTILITZAR-SE?

En l'univers J2EE, alguns CMS d'alta qualitat tenen dos nivells d'implementació: d'una banda, un conjunt de

components Java especialitzats en la gestió de continguts, i per altra, una sèrie d'eines construïdes per donar

suport a aquests components.

Aquest enfocament ofereix una alta extensibilitat, en la mesura que els

components d'un marc de referència (framework) estan perfectament

documentats, i poden ser utilitzats per construir eines específiques, tant

per a la funció gestió com per a la funció lliurament.

A més, i en això resideix la força de l'entorn Java, aquests marcs de

referència són igualment concebuts perquè els components d'aquesta

base ja inclosa puguin ser estesos i enriquits.

Spip està llest per a la utilització. La interfície d'administració tracta i engloba totes les

manipulacions necessàries per a l'administració i l'explotació d'un lloc.

Joomla i Drupal estan també a punt per a la utilització. No constitueixen un

frameword, però posseeixen un sistema de mòduls que permet estendre les

funcionalitats si es desitja. Els nombrosos mòduls disponibles permeten adaptar

aquests CMS a la majoria de les necessitats.

Encara que també està llest per a usar, Typo3 es caracteritza també per una

arquitectura prevista per posseir mòduls d'extensió. Els mòduls existents van més

enllà de les funcionalitats de CMS. Cal destacar que el grup Smile ha realitzat alguns

d'aquests mòduls.

eZ publish és més freqüentment utilitzat amb una instal·lació automàtica disponible

que funciona amb diverses plataformes. Disposa també d'un sistema d'extensions,

així com un framework en PHP.

Jahia està llest a la utilització, amb una excepcional qualitat d'embalatge: es pot

descarregar i funciona automàticament en qüestió de minuts. No obstant això,

presenta bones capacitats d'extensió mitjançant els mecanismes de portades.

OpenCms és un CMS orientat a marc de referència, de manera que les vies

d'extensió estan ja estudiades i marcades. Cal tenir en compte que el domini d'un

marc de referència Java, encara que ben concebut i ben documentat, és una inversió

important. Els enginyers de Smile dotats d'una forta experiència J2EE van necessitar


Content Repository

Framework Java orientat CMS

Eines Content

Management

Eines Content

Delivery

Eines

específiques

Eines framework

més de tres setmanes per dominar els conceptes i l'aplicació d'aquests marcs de

referència per poder construir extensions.

Apache Lenya està llest per a la utilització, però la seva aplicació és més tècnica i

relativament més complexa. Lenya no està fet per acceptar extensions, tot i que és

possible d'estendre el producte modificant el codi del nucli.

InfoGlue està llest per a la utilització, però és extensible per mòduls. No està orientat

a ser un marc de referència, però pot acceptar altres mòduls o aplicacions, per la seva

funcionalitat de portal.

Cal tenir en compte que una de les extensions clàssiques consisteix a

ampliar objectes 'Articles' estàndard, per definir un objecte corresponent a

un tipus de contingut específic. La programació consistirà aleshores a

definir la capa persistent del nou objecte, en referència a les taules de la

base de continguts, i a definir un kit d'edició (kit d'autoria), que manegi una

interfície d'actualització específica per a aquest nou contingut. Però

haurem de fer servir el framework pel desenvolupament d'extensions, o

considerar cicles de vida específics, o integrar el CMS amb aplicacions a la

mesura.

La nostra anàlisi és que l'enfocament a marc de ref erència que

predominava fins fa uns quants anys per als project es de més alta

qualitat, està ara superat.

Les necessitats de gestió i lliurament de continguts s'han estabilitzat el suficient per que les eines puguin cobrir-la

per simple configuració o parametrització. L'enfocament a marc de referència o extensible segueix sent interessant

per funcionalitats annexes a la gestió de continguts que són específiques a cada projecte. Aquestes funcionalitats

s'han de desenvolupar sense tocar al codi font de l'eina en els mòduls basats en aquest marc de referència.


3.3 SEPARACIÓ DE LA FORMA I EL FONS

Un dels principals objectius d'un CMS és delimitar una frontera entre el contenidor i el contingut, entre la forma i el

fons, entre la presentació gràfica i el text dels articles.

Existeixen innombrables bones raons per preservar aquesta separació.

En primer lloc la presentació i el contingut són integrats per diferents equips: el disseny és desenvolupat per un

dissenyador gràfic, mentre que el contingut és integrat per un programador tècnic.

En segon lloc, presentació i contingut han d'evolucionar de manera independent. Ha de ser possible, en particular,

modificar el disseny d'un lloc sense haver d'intervenir en el contingut i al inrevés, afegir o canviar un text sense

preocupar-se per el format.

Finalment, un format únic és compartit per diversos continguts: és el que constituirà l'homogeneïtat del lloc. Seria

impossible aconseguir-ho si cada vegada que s’afegís o canviés un contingut s’hagués també de redefinir el

disseny.

Cal afegir també que la maquetació es defineix sempre en referència a un mitjà de publicació, de manera que

barrejar forma i contingut implica reduir les possibilitats de publicació a un sol mitjà.

Queda clar llavors: d'una banda la forma i l'altre el fons. De manera pràctica, els textos integrats en l'estructura de

continguts no han d'incloure cap maquetació.

Aquesta limitació és de vegades massa forta, i ha de llavors permetre algunes excepcions: negretes, cursives,

subratllades. És a dir, el nivell del format que seria acceptat en un article de diari. Però no més: tipus i mida de

lletra, colors, marges, columnes, ... tot això forma part del model i no s’ha de permetre en el contingut.

Per respondre a la necessitat de format, els CMS inclouen en general una eina d'edició HTML, un tipus de «mini-

word», que permet no només formatejar els textos, sinó afegir enllaços i imatges. La integració d'aquesta eina pot

ser més o menys completa, segons prengui en compte o no els estils CSS definits per al lloc, que la inserció de

l'enllaç permeti seleccionar un contingut del lloc o que la inserció d'una imatge es faci a partir d'una imatge d'una

mediateca.


Joomla ofereix d'entrada l'editor HTML de codi obert TinyMCE, editor wysiwyg de bon

nivell, que genera un codi html de qualitat.

Drupal no integra d'entrada el mini-word, però els mòduls complementaris permeten

afegir fàcilment aquesta funcionalitat, utilitzant els editors de codi obert més comuns i

corrents. La integració de l'editor extern és més simple, sense la gestió d'enllaços cap

als continguts.

OpenCms té d'entrada una solució d'edició HTML, ben integrada en l'eina.

Fins ara Typo3 havia optat per una solució VBscript que només funcionava amb

Internet Explorer. En la versió 4, Typo3 integra l'editor wysiwyg HtmlArea, obrint així la

compatibilitat als navegadors Firefox. Aquest editor està perfectament integrat en

Typo3, amb una gestió d'imatges i la possibilitat de personalització de l'editor d'acord

amb els usuaris.

Pel que fa a Spip , no té editor HTML wysiwyg, és reemplaçat per marques

específiques que l'usuari ha de conèixer. Això limita molt les possibilitats d'edició de

pàgines, per exemple, per incloure imatges en el text, o una taula o una estructura

més complexa. És possible però, integrar a Spip un editor wysiwyg com Fckeditor. És

important observar que l'absència d'editor imposa formats simplificats, fàcilment

separables del contingut, sobretot quan s'exporten en format Xml.

Jahia integra diversos editors web, el que permet un funcionament per a tot tipus de

plataformes.

eZ publish integra des de fa poc el seu propi editor "Online editor", recentment

convertit en solució oberta sota llicència GPL. Aquest editor wysiwyg escriu de fet en

llenguatge XML en lloc de html, el que implica algunes limitacions en el format, però

garanteix una sepacián perfecta de la forma i del fons. A més, perfectament integrat en

el CMS, aquest editor permet inserir fitxers provinents de la mediateca ezPublish, o

pujar un arxiu directament com a arxiu adjunt de contingut.

Apache Lenya proposa d'entrada dos editors wysiwyg. Kupu que permet fer xhtml, i

BXE que permet modificar continguts Xml. BXE va més enllà del simple format. BXE

permet crear un contingut visual, treballant al mateix temps en el format, segons els

límits imposats per l'esquema RNG. Per necessitats dels projectes, Smile ha integrat

l'editor Xml Xopus, eina de pagament i que es recolza sobre els esquemes XSD.

InfoGlue integra d'entrada un mini-word, basat en FCKEditor, molt ben integrat en el

CMS, i que permet crear un enllaç cap a un contingut seleccionant-lo de la mateixa

manera que les imatges.

La bona separació de la forma i el fons és més una qüestió de política que d'eines.


En un CMS integrat com Spip , Joomla , Drupal , OpenCMS o Typo3 , és raonable

permetre als participants definir el format més enllà de la utilització de negretes o de

lletres cursives. La limitació de multi-canal sol ser més petita, i podem comptar amb el

procés de validació per al control d'aquestes contribucions i assegurar la uniformitat de

les pàgines.

Inversament, en l'òptica de CMS corporatiu, com són eZ publish , InfoGlue , Lenya o

Jahia , aquesta limitació ha de ser respectada rigorosament. Cal assenyalar que les

possibilitats d'estructuració dels tipus específics d'articles limiten significativament la

necessitat d'inserir format en els articles, ja que per a cada camp de l'article podria

definir-se un format a nivell de les plantilles com veurem posteriorment.

3.4 ESTRUCTURA D’ARTICLES

Un article és un element de contingut. Segons el cas, pot tractar un tema específic amb una extensió entre

algunes línies i algunes pàgines de text.

Un article, però, no és la unitat més petita de l'estructuració de continguts: generalment, un article es descompon

en camps elementals, que poden ser per exemple el títol, el subtítol, una imatge o el cos del text.

Així, es poden diferenciar dues maneres d'estructurar els articles: una estructuració funcional i una estructuració

semàntica.

L'estructuració funcional va a descompondre l'article basant-se en el rol i la funció de cada document, títol,

subtítol, resum. Aquesta estructura és independent del subjecte que tracti, del tema de l'article: ja sigui una

recepta de cuina o un partit de futbol, es pot identificar un camp títol per a cada camp resum.

L'estructuració semàntica descompon l'article segons el significat de cada document. Per a una recepta de cuina,

es poden distingir els camps ingredients, temps de cocció, temperatura del forn, nivell de dificultat, etc. Per als

equips de futbol: equips, estadi, data i hora, etc. Com observem, l'estructuració semàntica depèn estretament del

tema de l'article, de manera que dins d'una mateixa gestió de contingut, podem definir diferents estructures o tipus

d'articles. Cada contingut serà d'un tipus o d'un altre, i no sempre serà possible substituir un article A, on

esperàvem tenir un article de tipus B.

En realitat, estructurar bé cada article de manera específica presenta els següents avantatges importa nts:

• D'una banda permet l'entrada de dades dels articles a partir d'un formulari adaptat , i per tant

assegurar-se que tots estan inclosos dins del motlle corresponent al seu tipus. Per tant, és un factor que

ajuda a la qualitat del contingut.


• També permet distingir, en el moment de la publicació, cada un dels components de l'article, i per tant

separar perfectament bé la forma del fons , com ho evoquem anteriorment. És possible definir a la

maqueta de representació de l'article, que el camp ingredients es presenti en lletra cursiva, mentre que el

camp temps de cocció estigui en lletra negreta. I per descomptat podrem modificar aquesta representació

sense tocar les receptes de cuina. En absència d'estructura de l'article, hauria estat necessari renunciar a

aquests efectes en les lletres sobre els ingredients o el temps de cocció, i haguessin tingut el mateix

format que la resta del cos de l'article.

• Finalment, és el que dóna sentit als continguts . Els continguts ja no són camps de text, són atributs que

qualifiquen un objecte: país, ciutat, preu, data, etc. ... I es desglossen totes les possibilitats d'utilització

d'aquests continguts.

Comprenem llavors l'interès que existeix en aquesta forma de gestionar les estructures d'un article. Però s'ha de

ser conscient que aquests avantatges s'obtenen a costa de certa complexitat . El CMS es converteix en un

veritable SGBD: es defineixen noves entitats, els atributs d'aquestes entitats, els controls a efectuar per a un dels

camps, les relacions entre les entitats, etc. ... No obstant això, el fet que una declaració d'un tipus de contingut

estructurat es pugui fer-se sense programació informàtica és una de les funcionalitats més importants d'un

CMS.

A la imatge precedent, a l'esquerra observem la recepta de la «Charlotte aux pommes» en versió no estructurada,

i a la dreta, la mateixa recepta, en versió estructurada. Es comprèn perfectament que la possibilitat de

representació i de la utilització dels continguts, és molt més gran en el cas de continguts ben estructurats.

Joomla i Spip no permeten definir tipus de continguts específics. Això implica algunes

limitacions, però també una gran senzillesa, en la gestió i l'organització d'un lloc. Tots

els articles es tracten en el mateix formulari, tots els articles poden ser representats

amb una mateixa plantilla.


Drupal suporta tipus de continguts estructurats, però no proporciona mecanismes per

a gestionar directament la seva edició. Un mòdul opcional afegeix aquesta possibilitat i

permet crear simplement nous tipus de continguts amb l'ajuda de formularis integrats

en el back office.

El mòdul TemplaVoila de Typo3 permet definir noves estructures de continguts, amb

formularis d'entrada adaptats. Encara que la creació és encara una mica tècnica, es

veu el resultat. Podem crear nous tipus de continguts i utilitzar-los fàcilment en

qualsevol part en el lloc. Els continguts estructurats són emmagatzemats en Xml en un

nou camp de la taula de continguts.

Des de la versió 6, OpenCms permet definir tipus d'articles específics, basats en els

esquemes XSD. Les estructures possibles continuen sent simples i no utilitzen tot el

potencial d'Xml, però és possible simplement crear noves estructures de continguts.

Els continguts estructurats són després emmagatzemats en Xml, en un camp de la

base de dades.

eZ publish destaca en aquest àmbit respecte a la resta. És l'eina que permet definir

els tipus de continguts desitjats, simplement a través d'una interfície web. D'entrada,

els nous tipus de contingut tindran una plantilla estàndard que mostrarà tots els

atributs de contingut. Després, per a cada tipus de contingut, és possible definir una

plantilla de visualització prèvia en la interfície d'administració i una altra per a la

interfície pública.

Jahia permet definir nous tipus de contingut mitjançant els fitxers JSP en els quals

només n'hi ha prou amb definir l'estructura del contingut. No hi ha interfície gràfica per

a crear nous tipus de continguts, però la creació segueix sent senzilla.

InfoGlue permet crear noves estructures de contingut a través de la seva interfície,

sense cap coneixement tècnic necessari. InfoGlue va encara més enllà, és l'únic CMS

amb regles de validació per a cada camp, utilitzant expressions regulars. Una

expressió regular, ens permet per exemple imposar que la lletra inicial sigui en

majúscula, o que no hi hagi espais, o que un camp sencer aparegui amb un caràcter al

final …

Lenya , al estar completament basat en XML, permet definir estructures de contingut

complexes. Si bé la definició d'aquestes estructures es fa mitjançant un esquema XSD

o RNG, és a dir, per usuaris tècnics, la utilització d'aquests esquemes permet anar

més enllà en les estructures possibles. El format XML permet incloure llistes

d'elements estructurats en un contingut, cosa que no permet l'estructuració més simple

d'altres CMS.


3.5 PÀGINES I CONTINGUTS

Un CMS manipula els continguts , sovint anomenats articles. Aquests continguts estan publicats en pàgines.

Una pàgina pot contenir diferents articles, i un mateix article pot aparèixer en diferents pàgines.

Per a alguns CMS, un contingut és sempre creat en una pàgina específica, fins i tot, en una posició específica en

la pàgina. Per a altres, la creació d'un contingut, la seva validació, les seves versions, són independents del

concepte de pàgina. Una vegada que el contingut ha estat creat i validat es pot col·locar en una o diverses

pàgines. Aquest enfocament segueix el principi de separació de la gestió, prèvia i posterior a la publicació.

Tot i que un contingut està situat en primer lloc en una pàgina, és

important que pugui ser posicionat en altres pàgines sense

duplicar-lo Així, una actualització del contingut tindrà un impacte

automàtic en les diferents pàgines en què sigui publicat.

Aquesta publicació múltiple d'un mateix contingut, anomenada

també multi

posicionament

d'articles, pot ser

operada per seguir un comportament específic: el gestor posiciona

l'article en tal i tal pàgina, o bé el pot establir a través de regles que

regeixen la publicació.

Normalment la presentació de les cinc últimes notícies a la pàgina

principal, o en els marges d'algunes seccions és un exemple de la

publicació basada en normes. No cal que una nova notícia sigui

publicada en aquest o tal pàgina, per tal que aparegui en actualitat, el

simple fet de ser recent farà que aparegui automàticament.

S'observa una gran diferència entre els productes pel que fa al procés

de publicació. Si aquest procés es fa a nivell de cada contingut,

llavors el CMS estarà orientat al 'contingut'. Si aquest procediment es

fa a cada pàgina, aquesta mateixa incloent a la vegada un o diversos

continguts, llavors el CMS estarà orientat a 'pàgines', permetent en

general un millor domini gràfic de la pàgina.


Spip , Drupal i Joomla estan orientats als 'continguts', i cada contingut (article, resum,

secció, ...) forma una pàgina, amb la seva url. Després, les paraules clau permeten

mostrar els continguts de diverses pàgines relacionades

Typo3 està orientat a les 'pàgines'. Una pàgina conté una o diverses columnes, i cada

columna conté un o més continguts o mòduls, el que dóna una gran flexibilitat per a la

maquetació. La publicació i el seguiment de les versions es fan a nivell de la pàgina en

un conjunt.

Jahia està també orientat a 'pàgines', deixant veure així el seu aspecte més fàcilment.

La maquetació de les pàgines és flexible i depèn de les plantilles realitzades. La

categorització ben implantada - o l'anomenat 'mestre de continguts' - permet ubicar els

continguts en diverses pàgines. La validació i el seguiment de les versions són

realitzades a nivell de pàgina, però des de la versió 4.5 la validació es gestiona també

a nivell de cada contingut.

eZ publish és més orientat a 'continguts'. Els continguts segueixen el procés de

validació, s'emmagatzemen les seves versions, s'afegeixen a diferents contenidors,

que són a la vegada continguts. Un contingut té la seva pròpia URL. La gestió de les

pàgines es fa a través de plantilles, o d'una pestanya 'disseny', que permet inserir els

mòduls en espais específics de la pàgina.

InfoGlue està orientat als 'continguts'. Els continguts són validats, seguits en versions i

multi-posicionats. La gestió de pàgines correspon a la gestió de plantilles,

parametritzables en WYSIWYG.

Apache Lenya té una orientació només de 'continguts'. Aquesta és la seva funció, en

un model de 'gestió documental' o de 'producció documental', el contingut és

primordial i la presentació es considera secundària.

3.6 ORGANITZACIÓ DE CONTINGUTS

El model clàssic d'organització és per descomptat e l d'una estructura jeràrquica arborescent, semblant a

una estructura de directoris jerarquitzats d'un sistema d’arxius. Cada nivell de la jerarquia, té una classificació en

relació al significat de cada punt, per exemple, en referència als temes que tracta.

Así Així per exemple podrem organitzar el contingut d'un lloc de comunicació en esports, cultura, internacional, ... i

després tornar a dividir la secció esports a bàsquet, futbol,….

En aquest exemple, l'organització de continguts està en correspondència amb l'organització de la pròpia

publicació. No és obligatori, però entenem que aquesta correspondència entre organització interna i organització

externa simplifica considerablement el treball d'un redactor.


No obstant això, quan s'analitza la gestió de continguts a nivell d'empresa com la suma de diverses publicacions o

diversos llocs web, és molt possible que l'organització dels llocs web no es correspongui amb l'organització de

l'estructura de continguts del CMS. En aquest cas, hem de definir com els elements entren en l'estructura de

cadascuna de les publicacions, ja sigui explícitament , mitjançant la definició en cada contingut, ja sigui a través

de normes de gestió .

Aún Encara dins d'un mateix lloc, l'organització jeràrquica pura no sempre és satis factòria . Hi ha alternatives.

Podem per exemple, associar un article de diferents temes, cosa que crea una organització més racional, o de

conjunts, més que jeràrquica. Correspon al que de vegades anomenem categorització de continguts , que és

una funcionalitat important de la gestió de continguts.

L'article que tracta un partit de futbol de l'equip local es poden trobar a la secció 'esportiva' i en la secció

'd'informacions locals'. La possibilitat de trobar un article en diferents p unts de la jerarquia permet satisfer

als visitants que tenen lògiques diferents . Efectivament, aquest és un punt fonamental, no n'hi ha prou amb

presentar el seu contingut de manera lògica i organitzada, cal que aquesta lògica sigui també la del visitant .

No obstant això, no tots els visitants raonen de manera idèntica, per la qual cosa es necessita també permetre

trobar un contingut seguint diferents tipus de lògica.


Per Spip , un article pertany només a una secció. Però li podem associar diferents paraules

clau, i l'organització per paraules clau permet definir altres jerarquies, limitades a un sub-

nivell. L'estructuració del lloc és possible i prou flexible. No obstant això la qüestió de la

classificació (de seccions, d'articles) a la interfície d'administració, no s'aborda a excepció

de la classificació automàtica per data.

En Joomla , el lloc es descompon en seccions, que són possibles d'assolir mitjançant el

menú principal. Les seccions tenen cert nombre de categories, a les que un article pot ser

associat. No és possible multi posicionar un contingut ja que un article que posseeix una

sola categoria.

Drupal utilitza un sistema de categories per organitzar els continguts en el lloc. Aquestes

poden ser multi ubicades fent pertànyer el contingut a diverses categories al mateix temps.

Typo3 barreja una mica l'estructura de publicació i d'organització de continguts. Així un

article es defineix dins d'una pàgina. Per descomptat una pàgina pot contenir diversos

articles, i podrà associar-se eventualment a diversos punts del lloc, però un article, no pot

estar ubicat en diferents seccions. És possible mostrar un mateix article en una altra

pàgina, però sempre s'ha de definir explícitament, article per article. Per aquesta raó Smile

ha realitzat una extensió «Categorització», que enriqueix el producte en aquest punt.

Jahia disposa d'un sistema de classificació transversal, que permet definir tantes

estructures arborescents com es vulgui. Un contingut està associat a una o diverses

classificacions, que no tenen límit de profunditat..

eZ publish permet posar un contingut en diversos llocs d'un lloc, guardant una única

referència. Aquestes multiposicions són possibles per a tots els continguts, i per a totes les

seccions, el que permet posar una secció sencera i tota la sub-jerarquia en diferents llocs

d'un lloc.

InfoGlue proposa dos mètodes d'ordenació: o s'utilitza el multi posicionament, que permet

posar un contingut en diversos llocs, i fins i tot re utilitzar-lo en diferents llocs, o s'utilitza un

arbre de categorització que aplicat a continguts, permet definir noves formes de navegació

per el lloc..

Apache Lenya no proposa de base cap mètode de classificació. Per Lenya, tota la

informació està en el document Xml, igual que la seva categorització. Seguint la mateixa

lògica, un document Xml no pot estar en dos llocs simultàniament. Per organitzar, cal

definir la possible classificació en l'esquema XSD o RNG, el que després permetrà

classificar el document en el moment de l'entrada de dades, i reutilitzar aquestes

categories en les plantilles.


¿Dónde?

Crear una sección

Suprimir una sección

( . . . )

Proponer un contenido

Validar un contenido

Poner en línea un contenido

( . . . )

¿Qué?

3.7 EDICIÓ DE CONTINGUTS

Els llocs de petita o mitjana activitat tenen freqüentment un editor o redactor únic, el webmaster. Ell mateix redacta

els continguts, o més comunament, els recull dels diferents departaments de l'empresa, i és generalment l'únic a

introduir-los en el lloc. Per descomptat ell té permisos per entrar dades o modificar els continguts en qualsevol part

del lloc.

Per als llocs de grans empreses, no és possible que una sola persona tingui la responsabilitat de capturar tots els

continguts. A més quan els continguts es redacten fora del CMS, aquests han de ser corregits, revisats, o aplicats

mitjançant copiar/enganxar, pel mateix webmaster, el que representa una etapa inútil.

Per totes aquestes raons, pot ser útil fer interactuar directament a alguns p articipants en el CMS, oferint una

interfície per a la captura i la modificació dels s eus articles . A més, en el context d'una intranet, la contribució

dels col·laboradors és un factor clau per a la participació i adhesió: una intranet no és una eina de comunicació

'descendent', ha de ser una eina d'intercanvi.

En aquest context, és sovint necessari donar als

participants drets limitats a certes parts del lloc .

Aquests drets són per descomptat definits d'acord a

l'organització jeràrquica dels continguts.

Definim així per exemple, una secció 'Recursos

Humans', que pot ser el punt de partida d'una jerarquia

de continguts, i els donem a alguns participants el dret

d'afegir articles a l'àrea de Recursos Humans. Els

mateixos participants no podran entrar articles que

modifiquin la secció 'Productes i Serveis'.

Definim així per exemple, una secció 'Recursos

Humans', que pot ser el punt de partida d'una jerarquia

de continguts, i els donem a alguns participants el dret

d'afegir articles a l'àrea de Recursos Humans. Els mateixos participants no podran entrar articles que modifiquin la

secció 'Productes i Serveis'.

Els CMS han d'oferir una gestió de privilegis amb dos eixos: el primer eix és el dels continguts i la seva

organització, el segon és el de les operacions lligades a la gestió d'aquests continguts: consultar, actualitzar,

validar, publicar, etc …


Spip permet a diversos col·laboradors tenir drets diferents per treballar en un lloc. Per

Spip, es tracta d'<autors>, ja siguin redactors o administradors i que accedeixen a

totes les seccions o una de sola. Spip permet a qualsevol internauta participar a un

fòrum al voltant d'un article. Aquesta funcionalitat, sovint posada en marxa en els llocs

web "socials", permet fer viure un lloc a través dels internautes, i aporta un 'veritable

valor' a un lloc editorial. La moderació del fòrum es pot fer a priori o a posteriori.

Joomla proposa 3 grans nivells de contribució: "autor", "editor" i "publicador» que

permeten respectivament modificar, crear i publicar el contingut. Cada article pot estar

associat a un autor. En el cas d'un simple lloc a la xarxa, aquest sistema és suficient.

Drupal disposa d'una gestió molt detallada de drets. És possible crear un gran nombre

de rols i aplicar-lis drets per a cada funcionalitat de cada mòdul. Aquest model permet

a Drupal adaptar-se a qualsevol necessitat.

Typo3 té una gestió de drets més completa que Spip. Igual que OpenCms, està

inspirada en un model Unix, amb nocions de propietari, grup, altres. Spip i Typo3

ofereixen tant l'un com l'altre, una combinació de navegació com a visitant o com a

participant: a partir del moment en què un visitant s'identifica com a participant, pot

navegar en el lloc i cada pàgina s'acompanya d'enllaços que permeten la seva

actualització. És una manera molt amigable de fer servir l'actualització del lloc.

OpenCms proposa una gestió de drets inspirada en Unix: cada secció de la jerarquia

es veu com un dipòsit, i els drets de llegir, escriure esborrar s'atribueixen acord amb

paràmetres de forma acumulativa: propietari, grup, altres, és a dir el que va escriure el

article, els del seu grup i els altres.

eZ publish permet definir els rols, els grups i els usuaris. Els rols comprenen un

conjunt de drets autoritzats, per a cada mòdul, de lectura o escriptura. Aquest mateix

sistema permet restringir els drets de consulta en el lloc, o d'escriptura en el fòrum.

També permet la contribució «in-site», és a dir, integrada en el lloc, el que és

generalment valorat pels participants ocasionals.

Jahia permet definir els perfils i els drets necessaris per a una gestió descentralitzada,

amb nocions de grups i usuaris manipulables en tots els sentits. La gestió de drets

s'aplica també als mòduls de portada, el que permet tenir una identificació única per a

cada grup d'aplicacions posades en marxa.

InfoGlue permet definir els grups i els rols, associats als usuaris que poden només

tenir accés a certs mòduls, certs continguts i certes accions.

Lenya utilitza també de manera molt detallada els drets de contribució, amb un

avantatge a nivell del circuit de validació i dels rols dels usuaris.


3.8 WORKFLOW DE VALIDACIÓ

Sovint hi ha la necessitat de poder separar les etapes de redacció i de validació. Aquest és particularment el cas

en els contextos on la redacció és descentralitzada o delegada a un nombre important de persones. Si tot i això es

vol desar el control respecte als continguts, el que és fonamental, és que un article sigui primer redactat, en un

segon temps validat i eventualment posat en línia. Això és encara més important si els participants no són sempre

especialistes ni de la comunicació ni del món web.

En alguns contextos, hi ha fins i tot diversos graus de validació que són necessaris: un participant escriu, el seu

cap de servei valida al seu nivell i el responsable de comunicació vàlida una segona vegada.

La validació s'ha de posar en marxa per el CMS amb totes les característiques d'un veritable workflow: els

participants han de ser avisats per mail de les accions que els incumbeixen, i han de poder consultar amb un

simple clic la llista d'articles en espera de validació.

Però això no és tot, un cop creat el contingut, validat i publicat seguint el circuit de validació, ha de poder ser

modificat, després validat i publicat de nou,

mentre que el contingut en línia continua sent

el mateix. S'ha de poder associar a un circuit

de validació, una gestió avançada de versions,

permetent tenir diversos estats simultanis per a

un mateix contingut.


Amb Spip , un article pot estar en estat d'esborrany, validat, publicat, denegat i

suprimit. Segons el seu estatus de redactor o d'administrador, podrem o no posar en

línia un article. El workflow que es dugui a terme és limitat, però suficient en la majoria

dels casos. Podem modificar un article en línia, però serà necessari duplicar per a

passar de seguida al circuit de validació. Un contingut Spip no pot tenir més que un

estat a la vegada.

Per Joomla i Drupal , la gestió de la validació és molt simple. Un contingut està en un

estat "no publicat" o "publicat". Només un usuari que tingui els drets podrà passar un

document a un estat publicat. Drupal compta amb un mòdul que implementa un

workflow clàssic (esborrany, validació, publicació).

Typo3 integra des de la seva versió 4 la noció d'espais de treball que permet treballar

en diversos entorns (una "producció prèvia", una versió 2008, una recepta ,...) i

després passar una pàgina a producció o un sub-arbre de pàgines.

Per a cada espai de treball, definim tres grups: participants, revisors i validadors,

corresponents a un workflow de publicació a tres nivells específics a l'espai de treball.

Al final, el validador decideix la publicació en l'espai de treball "live".

OpenCms , per la seva banda, ofereix un dispositiu de workflow que és

extremadament genèric i pràcticament sense relació al procés de validació pròpiament

dit: permet construir qualsevol tipus de seqüència de tasques, però no hi ha cap

relació precisa entre aquestes tasques i la gestió del contingut. L'avantatge és que

podem construir un flux de treball en el qual demanem a un participant completar un

article, o arreglar el seu escriptori. L'inconvenient és que el valor afegit de l'eina és

baix en relació a un simple intercanvi de mails.

eZ publish permet definir workflows associats a seccions, aplicats o no segons els

usuaris i els grups. Aquesta funcionalitat permet posar en marxa workflows a un o

diversos nivells de validació. Un sistema de notificació envia automàticament

missatges d'alerta i demandes de validació als interessats. A més, eZ permet tenir

simultàniament tantes versions com es vulgui en un mateix contingut: 3 esborranys, 1

en curs de validació, 1 publicat, 5 arxivats ... el que evita qualsevol conflicte en les

actualitzacions per als diferents participants.

Jahia , des de la seva versió 5.0, permet posar en marxa workflows a diversos nivells i

aplicar-los als continguts segons una lògica d'herència. Un nou flux de treball pot

definir-se de manera interactiva en el back-office.

InfoGlue integra l'eina de workflow codi obert OpenSymphony, que permet definir

fluxos de treball complexos en Xml. Aquests fluxos de treball parametritzables poden

aplicar-se als continguts, però també poden associar-se a altres aplicacions de


l'empresa a través de Web Services. La gestió de versions està ben resolta d'una

banda, amb la possibilitat de modificar un contingut i continuar el flux de treball deixant

el contingut en línia sense canvis, i d'altra banda, la possibilitat de publicar els

continguts per paquets, el que permet obtenir versions coherents de llocs, publicables

o no en la seva totalitat

En Lenya , és possible definir un flux de treball en Xml, amb tantes etapes com es

desitgi, i que es pot enriquir amb etapes de transició condicionals. La sintaxi utilitzada

és relativament simple. Lenya servir dos espais: authoring i live, el que permet treballar

en la versió en authoring, sense modificar la versió en live, fins a la validació, que

actualitza el contingut en live.

3.9 WEBDAV

El protocol HTTP es va enriquir amb una subcapa que permet fer un servidor web, un servidor d'arxius. WebDAV

(Web-based Distributed Authoring and Versioning) permet als usuaris accedir i modificar arxius sobre els servidors

de xarxa remots.

Pel que fa al molt conegut FTP, WebDAV permet, a més de bloquejar els arxius quan són modificats per un

usuari, evita fer una còpia local de l'arxiu abans de modificar-lo. Els usuaris poden treballar en equip en els

arxius del servidor remot, com si es tractés d'un s imple dipòsit compartit en xarxa.

Els equips dels usuaris han d'estar equipats amb un client webdav que els permeti accedir. L'explorador d'arxius

de Windows en tingui, així com Microsoft Word, i hi ha diversos clients disponibles (i gratuïts) per a Linux o Mac.

La integració de webdav a les eines de gestió de continguts obre noves funcionalitats, particularment per a l'accés

als arxius publicats, així com al procés de publicació.

Observem que l'accés webdav a un CMS ha de disposar de la mateixa seguretat que l'accés d'interfície web, amb

els mateixos usuaris i drets.


Spip , Joomla i Drupal no disposen d'un accés webdav.

Typo3 inclou el suport webdav per la seva futura versió 5.0, per accedir al repositori

fileadmin. El suport de webdav està restringit ja que només els arxius de la mediateca

es faran servir a partir de webdav i sense gestió de versions.

OpenCms no integra ni preveu funcionalitats webdav.

eZ publish posa en marxa webdav de forma expressa. Efectivament, eZ publish dóna

accés a la jerarquia de continguts en webdav, amb una estructura de carpetes i de

fitxers reproduint la jerarquia dels continguts. Si un contingut és de tipus arxiu en eZ,

serà accessible directament com un arxiu a través d'un client webdav. Aquesta

representació webdav dels continguts, permet a més una manera simple d'incorporar o

extreure nombrosos continguts, per mitjà de la maniobra d'arrossegar-deixar un

subarbre complet d'arxius.

Jahia integra el protocol webdav per accedir als recursos d'arxius associats als

continguts, i permet gravar arxius simples en el repositori de recursos, per enllaçar

després als continguts.

InfoGlue no proposa cap funcionalitat lligada a webdav.

Lenya dóna accés als continguts en webdav, per a ser modificats amb un editor Xml o

XHTML local. Les operacions de publicació es fan sobre la interfície web.

3.10 GESTIÓ DE VERSIONS

La gestió d'una versió i la capacitat de conservar les versions anteriors d'un mateix article, formen part de les

prestacions mínimes d'un CMS. S'aplica tant per a les versions antigues com a versions futures. Un mateix article

pot així tenir una versió en línia, una versió N +1, validada però encara no publicada i una versió N +2 en estat

d'esborrany.

Com observem anteriorment, la possibilitat de tenir diferents versions simultànies d'un mateix contingut és

necessària per al funcionament de fluxos de treball de validació. És el que ens permetrà seguir els circuits de

validació per a cada modificació, i per tant assegurar sempre la qualitat de les publicacions a un responsable.

La gestió de versions es pot fer a nivell de cada contingut, però també a nivell de les pàgines - una pàgina amb un

o diversos continguts organitzats -, o a nivell d'un lloc complet. La gestió d'una versió d'un lloc sencer és complexa

de manipular, però és interessant per a enviar grups de continguts repartits per tot el lloc.

Qui parla de gestió de versions, parla també de gestió de conflictes. També, l'eina ha d'evitar tota pèrdua de

treball sobre els continguts, prohibint l'accés a dues persones simultàniament a un mateix document, o creant

dues versions diferents, una per cada persona.


Per garantir la traçabilitat, els participants necessiten saber qui va modificar què en el lloc, i també han de conèixer

les diferències entre dues versions, ja sigui a nivell de contingut, d'una pàgina, o d'un lloc complet.

Una diferència entre les eines, és la capacitat d’utilitzar les versions d'arxius adjunts, com els arxius PDF, però

també les imatges. Quan un participant modifica un comunicat de premsa amb un arxiu Pdf annex, substituint el

text però també l'arxiu Pdf, necessita que l'eina diferenciï les dues versions Pdf, per al circuit de validació i en cas

necessari que pugui fer marxa enrere.

Joomla i Drupal no integren un sistema de gestió de versions. Joomla tanca els

articles en curs per a l'edició per evitar conflictes.

Spip conserva les versions dels articles, i pot mostrar les diferències entre dues

versions. Spip tanca els articles fins que un usuari els modifiqui, el que evita qualsevol

conflicte. El punt feble de Spip és que no permet modificar un article independentment

de la versió en línia.

Typo3 és l'únic CMS que gestiona les gestions de sub-arbres complets. Des de la

versió 3.7, el mòdul de versionning permet crear noves versions de pàgines, però

també de sub-arbres complets, treballar-los, i després posar-los en línia. És en aquest

mòdul que es recolza el flux de treball desenvolupat per Smile i publicat en codi obert.

La diferència està a nivell de cada contingut..

OpenCms controla versions de continguts, i la separació d'espais de treball i de

publicació permet treballar una jerarquia o un contingut o un fitxer sense tenir impacte

sobre la versió en línia.

eZ publish sap utilitzar les versions de continguts, incloent-hi les versions de fitxers

associats als continguts. eZ publish associa una versió a un estat en el circuit de

validació, el que permet gestionar perfectament els continguts, la modificació i el

seguiment.

Jahia disposa d'un mòdul de seguiment de versions. La modificació d'una pàgina o

d'un dels seus continguts, i la seva validació es fan paral·lelament a la versió en línia

amb una visualització prèvia de tot el lloc, en la versió de treball.

InfoGlue utilitza versions a nivell de continguts, i permet tenir per a un mateix

contingut un estat publicat i un estat en forma d'esborrany.

Lenya utilitza jerarquies de continguts. Un sub-arbre 'live' i un 'authoring', que

permeten treballar un grup de continguts, visualitzar-los prèviament i posar-los en línia

seguint el flux de treball. S'integra un seguiment detallat de les versions i de les seves

modificacions.


3.11 CICLE DE VIDA DELS ARTICLES

Dins de la base de dades de continguts, els articles neixen, viuen i de vegades moren. Vegem com les eines CMS

manegen aquest cicle de vida.

Una de les necessitats clàssiques consisteix a preparar un article abans de la seva data de publicació, i programar

posar-lo en línia automàticament en una data concreta.

Un article pot també tenir una vigència coneguda amb anticipació: ja sigui en durada, o per una data concreta.

Podem crear un article que es digui "com omplir la seva declaració d'impostos?", i indicar des de la seva creació

que aquest article és vàlid durant un any, o bé fins al 31 de desembre de 2009.

Què passa llavors en aquesta data límit? L'article pot simplement ser retirat de la publicació de manera

automàtica. En alguns casos, el participant desitjarà saber per endavant la propera data de caducitat. El CMS pot

llavors des de la creació de l'article, definir aquesta data de caducitat, confirmar si el participant desitja saber-ho

per endavant, preguntar quants dies abans, i si el webmaster també vol saber-ho. Un cop advertit, el participant

pot actualitzar l'article si és necessari, o definir una nova data de caducitat.

Aquests són cicles de vida relativament simples. Podem desitjar coses més sofisticades, en particular que entre el

seu naixement i la seva mort, les modalitats d'aparició d'un article canviïn en uns terminis determinats. Pot així

quedar una setmana a la pàgina d'inici, després tres mesos a la secció d'actualitats, després un any a la secció

d'arxius, i finalment desaparèixer.

Pel que fa a aquest cicle de vida, Joomla permet la definició de dates d'inici i de fi de

vida dels articles.

Drupal compta amb un mòdul «Scheduler» que permet gestionar el cicle de vida dels

continguts.

Spip respon a la necessitat estàndard i permet publicar els articles, preparats per

endavant a partir d'una data definida, però sense data de fi de publicació. Una

modificació senzilla permet establir una data d'inici i una data de fi de publicació.

De la mateixa manera, Typo3 defineix opcionalment una data d'inici i una data de

finalització de visibilitat per a cada article, sense alertar en el moment de la fi. Typo3 fa

servir també la durada de vida per a una pàgina o per una estructura completa.

eZ publish no associa la durada de vida amb un contingut, però aquesta funcionalitat

és possible a través de la configuració de l'eina: cal afegir dues dates (o més) a cada

estructura de contingut, i configurar un esdeveniment del flux de treball per comparar

les dates d'inici i de fi.

Jahia permet definir una data d'inici i una data de finalització per a qualsevol contingut.

Per a les operacions més sofisticades, cal posar en marxa i parametritzar el motor de


flux de treball.

En les metadades d'un contingut, InfoGlue proposa una data d'inici i una de fi, el que

permet definir un cicle de vida per a cada un dels continguts.

Lenya no proposa dates d'inici ni de fi d'un contingut, però és possible integrar-les a

un contingut XML, ja sigui com a metadades, és a dir, un interval des de la seva

creació, o en el contingut mateix. El flux de treball està configurat per que prengui en

compte aquestes dates.

3.12 PUBLICACIÓ

El lliurament d'un contingut (content delivery) consisteix a produir les pàgines en un mitjà establert integrant el

contingut en un format específic.

El procés de publicació pot descompondre’s en

dues etapes: selecció dels continguts i muntatge de

pàgines, el que descriurem a continuació.

Internauta

Montatge de pàgines

Plantilles

Repositori de

contingut

Selecció d’articlesConfiguració

Publicació


3.13 SELECCIÓ DE CONTINGUTS

És important entendre la importància de l'etapa de selecció de continguts.

En un lloc simple, es pot concebre el fet de no generar més que dos tipus de pàgines: el sumari i les pàgines dels

articles. Cada pàgina de sumari farà aparèixer la totalitat de subseccions, i la totalitat d'articles associats a la

secció. Un enllaç a cada article donarà accés a la pàgina article.

En molts casos, aquest enfocament pot ser suficient. Però hi ha moltes necessitats que no

entren en aquest esquema. La clàssica és la generació d'últimes actualitats a la pàgina

d'inici. D'una banda la pàgina d'inici no és la pàgina del sumari de la secció d'actualitats,

d'altra banda, no accepta totes les actualitats.

Igualment, en un lloc de comunicació, els periodistes contribueixen escrivint articles que

alimenten la base de continguts poc a poc. Contràriament a la premsa en paper, no és

possible arreglar les pàgines manualment per a cada nou article, decidint la seva posició en

el lloc. Ha de ser possible definir les modalitats generals de la selecció d'articles: els tres

més recents, els que tenen menys d'un any, els articles redactats per un participant en

particular, etc ... Així, respecte a la selecció d'articles, la pertinença a una secció en

particular és un criteri obligatori, però no és l'únic.

Observem que aquestes possibilitats enriquides de selecció d'articles responen a altres

problemàtiques de publicació. Per exemple, poden contribuir a posar en pràctica un cicle de vida específic. O bé,

classificacions transversals que no depenen de l'organització principal del lloc.

Joomla permet d'una manera molt flexible i completament gràfica escollir els criteris

de selecció de contingut en cada part del lloc: número, classificació, numeració de

pàgines, tot pot regular-se sense cap programació.

Drupal permet seleccionar el contingut per categoria. Les plantilles PHP permeten

realitzar seleccions utilitzant criteris més complexos.

Spip té un sistema d'esquelets (plantilles) específics, amb les marques integrades com

a codi Html. Prou potent, permet definir noves marques i permet diferents operacions

com bucles niats o condicionals.

Typo3 separa una mica menys les nocions de base de continguts i de publicació: les

entitats manipulades en el back-office no són articles, sinó pàgines. És a dir, que estan

en referència directa a la generació del lloc. Contràriament, el mecanisme de plantilles

de Typo3 és particularment poderós: la plantilla HTML es completa per la programació

en TypoScript que permet tractar les necessitats més avançades, incloent els termes


de selecció de continguts.

Les plantilles eZ publish defineixen el format i la selecció de continguts. Hi ha

marques específiques que permeten incloure llistes filtrades sobre els elements que es

desitgen, per poder desplegar un menú o un altre. La definició de noves marques es fa

directament a les plantilles, en llenguatge php i utilitzant funcions de base d'eZ publish.

Cada tipus de contingut té a més una plantilla específica, que s'insereix a la plantilla

mateixa de la pàgina.

La maquetació de Jahia es realitza amb plantilles JSP, completament

parametritzables, ja sigui per un conjunt de funcionalitats, o directament en codi JSP a

través de les plantilles disponibles. El disseny de blocs en les pàgines, es realitza en

línia, en mode administració i podem organitzar els continguts de la pàgina de forma

simple.

3.14 PRESENTACIÓ I PLANTILLES

La maquetació de pàgines d'un lloc, per a una representació Html,

sempre es basa en un dispositiu de plantilles o templates, que

defineixen la manera en que els continguts han d'inserir-se en les

pàgines, i quines indicacions de format acompanyen aquests

continguts.

Per a una pàgina determinada, una plantilla o diverses seran utilitzades

per definir d'una banda, els continguts seleccionats, on seran posats a

la pàgina, i quins atributs de maquetació se'ls s'associaran. Podem per

exemple definir que una pàgina no presentarà més que els camps del

títol i que abordarà una llista d'articles, que aquests ítems seran

integrats en una taula a l'esquerra de la pàgina, i que finalment aquest

títol estarà en lletres negretes mentre que la llista estarà en lletres

itàliques.

Veiem en aquest petit exemple, la força de separació del contingut i la presentació: sempre es pot canviar d'opinió

i reacomodar una pàgina per posar ítems a la dreta, i en color blau, o per definir una altra pàgina, o que cada ítem

estigui acompanyat igualment d'una imatge.

Hi ha diverses tècniques per dur a terme aquestes plantilles:

La més simple consisteix a inserir a la pàgina Html unes marques particulars, (en anglès tags), que no són en

llenguatge Html, sinó definides pel CMS. El dispositiu d'elaboració de pàgines del CMS va a recórrer la plantilla,

analitzarà les marques, i deduirà els continguts a seleccionar i inserir en la posició de la marca, realitza la inserció,

déclaration des droits de l'homme

et du citoyen.

Horum omnium fortissimi sunt

Belgae, propterea quod a cultu

atque humanitate provinciae

longissime absunt, minimeque ad

eos mercatores saepe commeant

atque ea quae ad effeminandost.

formataje (templates)

Contenidos

Página publicada


Transformació XSLT

Content Repository

Extracció selecció de continguts

XML

XSL

HTML

i després l'enviament de la pàgina. Pel que fa a aquest tipus de plantilles, no existeix un únic estàndard pel que fa

a la sintaxi de les marques, i cada CMS definirà els seus propis estàndards.

L'avantatge d'aquestes primeres plantilles, anomenades plantilles Html, és que estan essencialment constituïdes

de codi Html, i per tant fàcils de manipular per un webmaster o un grafista.

Les pàgines JSP i PHP són també un tipus de plantilles. En el cas de pàgines JSP, les insercions del contingut

poden estar definides per codi en Java, o per marques que fan referència a objectes Java. En aquest últim cas,

parlem de biblioteques d'etiquetes, o taglibs. El gran avantatge de les plantilles JSP és la seva gran adopció per a

la programació web Java en general, independentment del CMS. En el cas de les pàgines PHP, el contingut és

obligatòriament inserit en codi PHP. No existeix un sistema d'taglibs en aquest llenguatge.

La tercera via és la dels formats XSL, a base d'Xml. En aquesta tècnica, el contingut primer s'extreu i es posa en

forma d'objecte Xml, que descriu cada ítem de contingut a presentar a la pàgina. El format es defineix a través

d'un altre objecte Xml, que fa referència als ítems del primer contingut, i defineix la manera en què seran barrejats

trossos de Html per a constituir la pàgina. Se utiliza una transformació Xsl, que es una eina estàndard, per a

realitzar la inserció de contingut i produir les pàgines.

La tècnica de fulles en estil XSL i de les

transformacions XSLT presenta avantatges importants:

• Es recolza en estàndards reconeguts, que

s'imposen més enllà de la gestió de continguts.

• Ofereix un mecanisme poderós i modulable per

a constituir les pàgines.

• No es limita als mitjans de comunicació Web, i

permet també elaborar pàgines destinades a

altres canals, particularment a l'elaboració de

pàgines Pdf amb l'eina Xml-FOP, que tendeix també a convertir-se en un estàndard.

No obstant això, aquesta tècnica és més complexa que les plantilles Html: el pas de la maqueta Html a la plantilla

Xsl corresponent, requereix certa experiència, i no podrà ser confiada a un grafista o a un webmaster. Podem

afegir també que l'operació de transformació és molt exigent en CPU, i és per tant lenta, però la majoria dels

dispositius de generació integren un mecanisme "d'amagatall", de manera que la transformació no s'executa cada

vegada que una pàgina es genera.


Joomla i Drupal utilitzen pàgines PHP que permeten crear plantilles, utilitzant totes

les funcionalitats d'aquests CMS.

Spip utilitza també les plantilles Html, amb marques específiques, però que en darrer

cas poden ser completades per la programació PHP.

Typo3 té igualment un sistema de plantilles Html, però completat de manera

interessant per una configuració interactiva, autoritzant certa flexibilitat per a tots dos

en una simple interfície d'administració: canvis de colors, de lletra, i altres

arranjaments que poden fer sense tocar una plantilla, només a través d'un simple

formulari Html en el back-office.

OpenCms defineix un sistema de plantilles en base de Xml, però que no utilitza fulls

d'estil XSL. La tècnica és potent i ben estructurada, però presenta l'inconvenient de no

ser estàndard, i per tant de no poder beneficiar-se d'eines genèriques que apareixen al

voltant d'aquests estàndards.

eZ publish utilitza plantilles en format tpl, que contenen codi Html i marques

específiques d'eZ publish. Les marques tenen una sintaxi Php, i el codi Php pot ser

directament inclòs per afegir funcionalitats externes.

Les plantilles de Jahia estan en JSP, el que aporta flexibilitat i rendiment. Cal remarcar

que són les mateixes plantilles que permeten la generació d'un lloc i l'administració de

continguts. La mateixa plantilla ha de tenir tres maneres diferents (visualització,

modificació i visualització prèvia) i la funcionalitat de workflow.

InfoGlue proposa realitzar les plantilles ja sigui en Velocity, un llenguatge del projecte

Apache, o directament en JSP, el que dóna més flexibilitat i facilitat d'interacció amb

altres programes.

Les plantilles de Lenya es basen en fulls d'estil XSL, permetent publicar els continguts

en format Html, però també en format PDF o RTF. El Xsl aporta complexitat en la

maquetació, sobretot a causa de la separació de les plantilles en el producte, fent la

feina d'integració més difícil.

Cal afegir també que, independentment del dispositiu de plantilles, hi ha una tècnica que és estrictament Html per

separar correctament el contingut del contenidor: els estils CSS. El principi és indicar només en el Html la

naturalesa d'un element, i de plasmar en les fulles d'estils, totes les informacions de la presentació. La pàgina

Html diu que «J. Hunter » és el nom de l'autor, i el full d'estils indica que el nom de l'autor s'ha d'escriure per tal i

tal format. Aquesta pràctica, que per descomptat ha de generalitzar-se, és independent d'una eina CMS en

particular.


3.15 PERSONALIZACIÓ DE LA PRESENTACIÓ

La majoria de llocs Internet presenten el mateix contingut als seus visitants. No obstant això, hi ha casos en que

un desitja diferenciar la presentació de la informació d'acord amb els visitants i presentar a cada un el que vol

veure, o el que està autoritzat a veure. Tot això a partir d'una base de dades de continguts única, administrada de

manera global.

Podem distingir una personalització sota demanda del visitant, i una personalització definida per les autoritzacions.

La primera és típicament la declinació del principi de portades a la manera de myYahoo o iGoogle, pel qual cada

internauta especifica els continguts que li interessen, i pot configurar la manera d'acomodar la pàgina que

presentarà aquests continguts. Una vegada definides les preferències, cada internauta serà reconegut, ja sigui per

una identificació explícita, o de manera transparent a través d'una cookie. Aquest tipus de personalització és

portada a terme per un mecanisme de generació de portades, que són tractades en el següent capítol.

La personalització per autoritzacions no es maneja a nivell individual, sinó creant grups de visitants, definits

segons el seu perfil. Aquesta personalització suposa una veritable identificació dels internautes, que permetrà

conèixer el perfil de cadascun d'ells.

És essencial per als llocs intranet, on l'accés a certes informacions ha de ser restringit.

Joomla proposa una personalització per autoritzacions en tres nivells d'accés: públic

(tot el món), membres (usuaris que disposen d'un compte), i particulars (usuaris que

disposen d'un dret d'edició).

Drupal no genera més que dos nivells d'accés: públic i membres. Hi ha mòduls

suplementaris que aporten més flexibilitat i permeten definir rols detallats per a cada

contingut.

Spip no preveu una generació personalitzada. De vegades aquesta limitació és

inacceptable.

Typo3 gestiona de manera molt completa les autoritzacions de lectura en un lloc i

permet una generació personalitzada. De fet, és el mateix dispositiu que s'aplica als

participants i als visitants d'un lloc. Cada pàgina del seu lloc pot ser destinada a un

grup de utilitzadors i en aquest cas no serà visible més que pels visitants pertanyents a

aquest grup.

eZ publish gestiona els drets d'accés i la gestió de comptes dels usuaris. El fòrum i

les subscripcions són funcions que es relacionen amb la personalització i que es duen

a terme de forma fàcil pel mateix sistema.

Jahia integra perfectament les nocions de personalització de la generació del lloc,


sobretot en funció dels drets dels usuaris connectats, i va a tenir o no certs mòduls i

certes presentacions d'aquests mòduls. Una vegada més, el mode "portal" exerceix

plenament el seu paper.

InfoGlue utilitza els drets de lectura dels continguts i les pàgines. Observem que

InfoGlue està connectat a CAS, una solució oberta de gestió d'identificacions (i de

Single Sign On).

Apache Lenya permet filtrar l'accés als continguts, en funció del perfil de l’ internauta.

3.16 INTERCANVI DE CONTINGUTS I SINDICACIÓ

És comú que un lloc hagi d’intercanviar continguts amb altres llocs, o que prengui informacions d'altres llocs

associats, o que posi a disposició una part del seu contingut.

La manera de fer aquests intercanvis consisteix a posar a disposició els continguts no en pàgines Html, sinó en

Xml, que permetran al lloc destinatari identificar sense ambigüitat cada camp d'informació.

Des del punt de vista legal, la recuperació, i sobretot la republicació

d'un contingut d'altres llocs no es pot fer sense autorització del lloc

original, que va a negociar cas per cas, o a través d'empreses

intermediàries de sindicació.

Des del punt de vista tècnic, el fet de posar a disposició la

informació en format Xml no és molt difícil, el mecanisme de

plantilles permet generar Xml tan fàcilment com Html.

No obstant això, la inserció de continguts externs requereix un

mecanisme específic per analitzar el flux Xml i requereix fer

insercions a la base de dades de continguts.

Perquè llocs diferents es puguin entendre, cal que descriguin els seus continguts en un mateix llenguatge. Hi ha

per a això un estàndard: RSS o Rich Site Summary / Really Simple Syndication, un format Xml, del qual tenim un

exemple en la imatge d'aquesta pàgina.

Veurem que la inserció de continguts externs a través d'una interfície RSS és una funcionalitat de llocs web a base

de portlets, com Jetspeed o de portals com NetVibes.


Spip és particularment eficaç pel que fa a la sindicació, ja que sap no només posar a

disposició un flux RSS, sinó també integrar un o diversos fluxos RSS externs: n'hi ha

prou amb oferir-li una url d'RSS. A més, Spip pot proposar un administrador la

validació d'un enllaç a través dels fluxos importats.

Joomla i Drupal permeten no només activar fàcilment fluxos RSS per al lloc i

configurar el seu comportament (autenticació, nombre d'elements ...), però també

permet afegir fluxos externs i publicar-los directament en les pàgines del lloc.

En l'entorn Typo3 , la importació RSS és més aviat una extensió disponible que permet

exportar i importar fluxos de sindicació.

eZ publish permet publicar informacions en diversos formats, dins dels quals, el

format RSS, és el que permet estar sindicat per a altres llocs. La importació de fluxos

RSS és possible, i la importació passarà, si es desitja, per un procés de workflow

abans de ser publicat. Cal observar que eZ publish importa els fluxos en els objectes

de continguts tipus enllaç, el que ens permet aplicar tots els mètodes disponibles

(multiubicación, traducció, workflow, ...) i sobretot barrejar els fluxos de diferents

emissors.

Jahia disposa d'un model d'importació RSS on els continguts s'importen separats de la

base de dades de continguts. L'exportació RSS es fa per mitjà de plantilles, en què cal

especificar els continguts a exportar.

InfoGlue no proposa d'entrada la importació o l'exportació RSS.

Apache Lenya sap exportar les creacions o modificacions de contingut en format

RSS. La importació RSS es porta a terme utilitzant una transformació XSLT, permeten

projectar en Html els enllaços dels fluxos. En realitat, el flux no és importat, és només

publicat.

3.17 MESURA I SEGUIMENT DE L’AUDIÈNCIA

Tot administrador d'un lloc, ha d'estar interessat per l'audiència, tant globalment com per a cada pàgina. És

possible que algunes pàgines pràcticament mai siguin visitades, o que no interessen a ningú, que estiguin poc

valorades, mal referenciades, etc.

El seguiment de l'audiència és fonamental.

Existeixen tres tècniques pel seguiment de l'audiència:

• L'anàlisi de registres del servidor.

• seguiment externalitzat, basat en marques integrades en el lloc.


• Una mesura integrada en el CMS mateix.

L'anàlisi de registres del servidor és la tècnica clàssica. El servidor Http (Apache, IIS) escriu en un fitxer de

registres, tots els URL que veu passar. Existeixen nombroses eines que saben analitzar aquest arxiu, i deduir una

gran quantitat d'informació: nombre de pàgines vistes, nombre de visites, dia per dia, hora per hora, origen dels

visitants, navegador que utilitzen, quines són les pàgines més vistes i moltes altres coses més.

Existeixen nombroses eines de codi obert de qualitat, com

Webalizer o AWStats. Cal tenir en compte que si es té allotjament

compartit, aquesta anàlisi és generalment atorgat per la companyia

de "hosting “.

El seguiment externalitzat és una tècnica més recent, proposada

per proveïdors especialitzats, com eStat o Xiti, i actualment Google

Analytics, que és gratuït i de qualitat. Consisteix en posar marques

específiques en les pàgines, invisibles als visitants, i que van a

registrar-se a un servidor extern, especialitzat per a mesurar

l'audiència. L'administrador pot connectar-se al lloc del proveïdor

per consultar taules d'anàlisi de la seva audiència. La forta concurrència entre proveïdors ha donat com a resultat

una gran riquesa en les solucions disponibles. Aquesta tècnica és poderosa, però part d'ella presenta un cost

recurrent a pagar el proveïdor, i d'altra banda implica l'etiquetatge de les pàgines, que es pot fer a través de les

plantilles, però requereix un treball específic.

Cal assenyalar que l'eina PHPMyVisites permet un servei similar a Xiti en els seus propis servidors.

Finalment, alguns CMS poden ells mateixos registrar l'audiència en el moment en què són sol licitats per servir les

pàgines. De manera general, aquesta tècnica és menys poderosa que les dues precedents: donarà menys

informació sobre els visitants i molt menys anàlisi. Presenta una sola avantatge, permet utilitzar el coneixement de

l'audiència en la generació mateixa, per exemple, presentant a la portada els articles més consultats del moment.

Spip , Joomla , Drupal i Typo3 registren ells mateixos les visites sobre les pàgines

servides. Les estadístiques (repartició de visites, i les informacions sobre els

navegadors o els sistemes d'explotació) són disponibles directament en el back office.

OpenCms, eZ publish , InfoGlue , Lenya i Jahia necessiten dispositius externs al

CMS. Però com hem indicat, aquestes solucions externes ofereixen bones anàlisis, i

són recomanables en tots els casos.


3.18 INDEXACIÓ I MOTOR DE RECERCA

Imaginem freqüentment que un motor de recerca es justifica principalment per les indexacions de documents en

text, o bé per la recerca a través de contingut poc organitzat, per exemple, en els missatges d'un fòrum.

Molts internautes fan servir la funció de recerca simplement per evitar la comprensió de l'organització del lloc.

Prefereixen escriure dos o tres paraules representatives del que van a cercar i prémer 'enter', després observar el

que se'ls proposa, en lloc de llegir el menú, reflexionar per trobar la categoria més apropiada, arribar a un nivell

inferior, reflexionar de nou, i finalment tornar per cerca en un altre costat.

Aquest comportament en la recerca és inculcat als internautes pels portals d'internet, que sovint són el punt de

partida per a la navegació.

Aquesta gestió, que va directa al contingut, sense travessar pàgines intermèdies i sense pensar, és contrària a

vegades al desig d'un webmaster, a qui li agradaria que un visitant es prengués el seu temps, recorregués el

major nombre de pàgines possibles, llegís tot el que es va preparar per a ell aquí i allà, i a més, que veiés la

publicitat.

Però el que vol el webmaster no és el que vol el visitant, i cal fer-se a la idea que el visitant té l'última paraula ja

que si no obté el que vol en tres clics, anirà a veure a un altre costat.

Un motor de recerca és una eina específica que no té pròpiament a veure amb un CMS. Els motors poden sempre

estar integrats en un lloc independentment de l'eina CMS escollida, en la mesura que indexen el lloc a través

d'http. Ofereixen totes les possibilitats per vestir les pàgines de resultats amb un mecanisme similar a les

plantilles. Alguns proposen també una API donant accés directe a funcions de recerca, el que permet integrar

millor dins d'aplicacions específiques.

La integració dels motors de cerca externa és difícil en el cas que l'accés és restringit a certs continguts que es

realitzen, ja que d'una banda, el motor ha d'indexar aquests continguts protegits, i per altra, el motor ha de verificar

les autoritzacions de l'internauta per mostrar els resultats de la recerca, incloent-hi o no els continguts protegits.

En el món de les solucions obertes, el producte far és per descomptat HtDig, que és a la vegada dinàmic i sòlid.

Des de fa poc un altre producte lluita pel lideratge. Es tracta de mNoGoSearch, un producte d'origen rus, amb una

programació molt activa, el que feia falta a htDig.

Anomenem també els productes Lucene i Nutch, que són solucions molt sòlides, en entorn Java.


Spip ofereix les funcions de recerca integrades però simplificades. És una recerca

superficial, que no tracta els operadors lògics, la indexació de documents, i la

categorització per pertinença. Per a una necessitat seriosa, la nostra recomanació és

recórrer a un motor extern.

Joomla permet les recerques segons tres modalitats: «AND», « OR », i « expressió

exacta ». Els resultats poden ser ordenats segons la data de publicació (més recent /

més antiga), la popularitat, l'ordre alfabètic o la secció/categoria.

Drupal ofereix una recerca amb operadors lògics i permet filtrar els resultats segons la

seva categoria i el seu tipus de contingut. Gràcies a «Search Attachments», Drupal pot

també fer recerques de textos complets en els documents annexos.

eZ publish ofereix una funció de recerca més avançada, sobretot amb la possibilitat

de cercar per cada camp de contingut (títol = ...), però també per una cerca de text

complet en els continguts i documents annexos. L'únic que no està integrat és

l'acabament de les paraules.

Typo3 integra un motor de recerca més que de continguts i documents adjunts, i la

llista de resultats és ordenada d'acord al càlcul d'un criteri de rellevància. Aquest

mòdul és inferior a htDig o mNoGoSearch en el sentit en què no permet una recerca

fonètica o propera, però és molt eficaç, i proposa resultats organitzats per arxiu. Per

necessitats més avançades, un motor de recerca externa és necessari.

Jahia integra el motor Lucene provinent del projecte Apache, que permet indexar el

conjunt de continguts d'un lloc, sense utilitzar el protocol http però amb connexions

específiques per a la lectura d'arxius i de la base de dades.

InfoGlue integra el motor de cerca Lucene, recorre les pàgines d'un lloc i les indexa,

proposant una recerca d'un text complet en tot un conjunt de continguts. La recerca

dels continguts protegits queda per desenvolupar.

Lenya integra Lucene, el motor de cerca de la mateixa fundació Apache, que indexa

els continguts en text complet i permet les recerques tenint en compte els drets de

lectura de l'internauta.

També hem d'esmentar el problema de la indexació a través de motors de recerca externs, com Google.

Les condicions de base per a que un lloc pugui ser indexat són (1) que totes les pàgines siguin accessibles sense

passar per un formulari - els motors d'indexació no creuen mai un formulari, tot i ser simple, i (2) que els URL

siguin estables . En particular aquells que no inclouen un token de sessió com ho fan algunes eines de

desenvolupament.


A més, cada pàgina del lloc pot definir les marques meta/keywords, que permeten anunciar explícitament les

paraules clau que caracteritzen la pàgina. Amb plantilles, és possible definir el contingut d'una marca a partir d'un

camp descrivint l'article.

3.19 GESTIÓ D’URL

Els CMS mostren continguts dinàmics als visitants. Com a tal, alguns CMS produeixen URLs plenes de

paràmetres que defineixen la pàgina. Tindrem per exemple un URL de tipus

www.misitio.es/article.php3?id_article=18.

Alguns CMS produeixen URL comprensibles, que donen una indicació respecte a la pàgina que es mostra. Les

URLs obtingudes són del tipus www.misitio.es/finanzas/resultados-financieros.htm per al contingut 'resultats

financers' de l'opció 'finances'.

El segon tipus d'URL, té un significat clar, presenta l'avantatge de ser comprensible per al visitant que sap que

està en l'opció 'finances' només veient la URL. Aquest tipus d'URL, presenta l'avantatge de ser interpretada pels

motors d'indexació com Google, que donarà més o menys punts a aquesta pàgina en funció de paraules presents

a la URL. Parlarem aleshores de URL 'amigables' o d’urls 'Search Engine Friendly'.

El primer tipus d'URL té l'avantatge de ser estable. Si l'article 18 es mou de l'opció 'finances' a 'resultats', el seu

URL seguirà sent la mateixa. Mentre que en el segon tipus, l'URL de l'article canviarà, el que pot provocar enllaços

trencats en alguns casos.

Tots els CMS s'orienten avui cap al segon tipus d'URL, tot i que uns van més lluny que altres.

Dos punts ens semblen importants en la realització d'URL amigables: Primer, la possibilitat del participant de

personalitzar la URL d'un contingut per a millorar la indexació a través de motors com Google. Segon, la gestió de

l'estabilitat de la url a través del CMS. El CMS ha d'evitar els enllaços trencats, emmagatzemant l'historial de les

urls d'un contingut, i mantenint operacionals encara després que el contingut hagi estat modificat.


Spip permet des de fa poc obtenir url pròpies. Les urls obtingudes no simulen una

jerarquia de continguts, però sobretot permeten una millor indexació.

Joomla i Drupal permeten realitzar url pròpies mitjançant una simple configuració a la

interfície de l'administració.

eZ publish simula a la url tota la jerarquia del contingut, i permet modificar per a cada

contingut, la seva url. A més, eZ publish manté operatives les urls antigues d'un

contingut, evitant els enllaços trencats.

Typo3 permet realitzar URL pròpies, gràcies a un mòdul que s'integra, dins del propi

producte. El mòdul permet tenir una url pròpia per cada idioma de contingut.

Jahia permet definir un àlies per a cada pàgina, permetent crear url pròpies simulant

una jerarquia. Es fa pàgina per pàgina.

InfoGlue defineix les url pròpies per a les pàgines, que són reagrupaments de

continguts.

Lenya permet per defecte obtenir url pròpies, però no gestiona l'historial de versions

d'aquestes urls.


4 SÍNTESI

Abans de concloure, subratllem que el nostre anàlisi va ser construït al voltant dels conceptes fonamentals de la

gestió de continguts, i no al voltant dels criteris d'elecció. El nostre objectiu no era construir una taula comparant

cada un dels CMS en cada un dels seus criteris. El nostre objectiu, com ho indiquem en el preàmbul, era proposar

la nostra visió de la problemàtica de la gestió de continguts.

Pel que fa als criteris d'elecció, és lògic que fan referència als conceptes fonamentals, però també inclouen altres

factors: dinamisme de la comunitat, referències, rendiment, documentació, etc.

No hi ha una eina que resulti guanyadora en aquest estudi: la selecció s'ha realitzat prèviament, aquí presentem

eines de qualitat, que formen part de les millors opcions que existeixen avui en dia per construir un lloc, o per

utilitzar en sentit més ampli, els seus continguts.

Les solucions obertes corresponen en informàtica al que els medicaments genèrics són per a la indústria

farmacèutica: una vegada que un camp madura, que els conceptes s'estabilitzen, les bones pràctiques i solucions

cauen en el domini públic. És el que progressivament està passant en el camp de la gestió de continguts. A la

gamma mitjana, les solucions obertes s'han estès i les propostes de productes tancats són gairebé inexistents.

Dins de la gamma alta, alguns productes ofereixen una alternativa completament competitiu respecte a les

propostes propietàries.

Cometa i Smile han realitzat solucions de gestió de

continguts en centenars i centenars de llocs, Inter net o

Intranet, i pot posar la seva experiència al servei dels

seus projectes.

Llibre Blanc CMS

Technology

Transcript of Llibre Blanc CMS