On Wed, 2004-09-08 at 23:41, Sylvain Wallez wrote:
> Eric van der Vlist wrote:
>
> >On Tue, 2004-09-07 at 16:11, Frédéric Glorieux wrote:
> >>Je laisse notre expert cocoon nous en parler autrement, mais j'ai
> >>l'impression que ses applis sont elles aussi très personnalisées.
> >>
> >>
> >
> >Oui, j'attends sa réponse avec impatience!
> >
> >
>
> J'arrive, pas très promptement cette fois-ci, mais j'arrive :-)
>
> Il y a bien évidemment plusieurs solutions (ça ne serait pas drôle sinon).
>
> Solution la plus simple, le "montage" du site dans le Cocoon standard.
> Pour cela, la sitemap racine de la distribution contient un match */**
> qui appelle une "mount table", permettant de monter un répertoire
> quelconque du filesystem sur un "répertoire" de l'espace d'URLs.
> Solution très simple, à condition qu'on n'ait pas besoin de toucher au
> cocoon.xconf. Pour plus d'infos, voir "mount-table.xml.sample" à la
> racine de la distrib Cocoon.
>
> Autre solution, au cas où des modifs du cocoon.xconf sont nécessaires.
> Cocoon vient avec une nouvelle tâche Ant "xpatch" qui permet d'aller
> insérer un fragment XML à l'emplacement indiqué par un chemin XPath. On
> peut donc avoir un script Ant qui augmente la distrib avec les
> composants spécifiques à une appli.
>
> Enfin, pour des modifications plus lourde des fichiers de conf, on peut
> passer une XSL sur les fichiers à modifier.
>
> J'espère que ça apportera des éléments de réponse...
Oui, mais à tors ou à raison, je préférerais procéder différemment et
faire en sorte que les installations de Cocoon et de mon application
soient le plus indépendantes possible : je voudrais par exemple pouvoir
faire tourner l'installation standard de Cocoon et ses exemples et mon
application en parallèle sur des ports différents au lieu de les
"mélanger" ou encore pouvoir tester mon application sur une nouvelle
version en ne modifiant que quelques variables d'environnement.
Ce que j'avais imaginé et documenté sur http://dev.xmlfr.org/CoCoon (et
cela marchait bien en 2.1.3) c'est la chose suivante :
* Une installation Cocoon en "standalone-demo".
* Indépendamment de cette installation (sous une autre racine),
l'installation de l'application.
* Sous la racine de l'application, un script "cocoon.sh"
légèrement modifié (je n'ai pas trouvé comment éviter cette
modification) permettant de lancer une instance de Cocoon
faisant appel aux librairies et classes de Cocoon (identifiées
par une variable d'environnement) mais utilisant pour le reste
l'environnement de l'application.
Est-ce une démarche qui a déjà été tentée? que vous encourageriez?
En théorie, si cela marche, je dois pouvoir installer une nouvelle
version de Cocoon dans un autre répertoire, modifier mes variables
d'environnement pour pointer sur cette nouvelle installation, relancer
Cocoon et utiliser cette nouvelle installation.
Le problème lorsque je passe de 2.1.3 à 2.5.1.1 avec cette méthode c'est
que plus Cocoon ne démarre plus. Je n'ai pas eu le temps de trouver
pourquoi, mais je pense qu'il doit y avoir trop d'adhérences entre le
script cocoon.sh, les fichiers de configuration et les classes et
librairies pour pouvoir facilement faire ce type de chose.
Peut-être devrais-je comme tu le dis constituer certains fichiers de
configuration en patchant les fichiers Cocoon?
Eric
> Sylvain
--
Carnet web :
http://eric.van-der-vlist.com/blog?t=category&a=Fran%C3%A7ais
Upcoming XML schema languages tutorial:
- Portland -half day- (27/07/2004) http://masl.to/?E6ED13728
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Received on Thu Sep 9 09:08:44 2004
