J'ai vu ces méthodes complémentaires sur l'interface EXistResource qu'il
serait bien pratique d'utiliser pour avoir une implémentation plus
complète de l'interface Source. Malheureusement, la license d'Exist
interdit ces extensions spécifiques d'être utilisées dans le code
disponible chez Apache...
> C'est plus une question de licence que de bonne pratique...
:o(
En ce cas, c'est à Exist de proposer son implémentation d'un cocoon
Source plus complet ?
Oui. La création d'un petit objet n'est pas coûteuse, et si on le
gardait dans l'objet Source, cela complexifierait inutilement le code
pour la gestion d'état.
Oui, à part le cas relevé par Jean-Baptiste Quenot, cela peut coûter
d'aller voir à chaque fois, si l'instance xmldb est distante.
* C'est certainement une mauvaise pratique, mais j'ai eu besoin d'un
getter sur user:password, cela me permet de reprendre la connexion
configurée en cocoon.xconf depuis ailleurs
Ca n'est pas forcément une mauvaise pratique. Lorsqu'on est sûr de
l'implémentation concrète de Source qu'on utilise, des méthodes
supplémentaires peuvent faciliter la vie. FileSource par exemple, permet
d'accéder au File sous-jacent.
Voilà, c'est ce genre de choses.
Je pensais d'ailleurs mettre un accès
public à la ressource et la collection dans XMLDBSource. Ca pourrait aider?
Beaucoup plus propre !
J'avais mis user:pass à public sur une vieille version de XMLDBSource,
la collection et la ressource n'était pas factorisée, mais en effet, un
mot de passe ne se ballade pas comme ça n'importe où.
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
