You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-fr@cocoon.apache.org by Frédéric Glorieux <fr...@ajlsm.com> on 2005/12/22 13:45:33 UTC
XMLDBSource, cacheable + questions
Bonjour,
Je cherche à avoir un générateur xmldb cacheable.
J'utilise Exist.
Dans certains cas, Exist sait donner une date de modification (quand on
demande une ressource précise). Il est possible que ceci puisse
s'étendre aux collections, et donc aux requêtes effectuées sur une
collection.
Je fais marcher, mais je ne sais pas si c'est optimal.
Comme je vois que Sylvain à toucher à XMLDBSource il y a moins de 3 semaines
http://svn.apache.org/viewcvs.cgi/cocoon/blocks/xmldb/trunk/java/org/apache/cocoon/components/source/impl/
Mes questions ont peut être un peu d'actualité.
(Je m'en suis d'ailleurs aperçu un peu tard. Je travaillais sur une
vieille version de la classe, beaucoup moins bien factorisée)
J'ai surchargé
XMLDBSource.getValidity()
pour qu'il renvoit un TimeStampValidity(lastModified) quand il est
possible de récupérer un long lastModified.
ça marche.
(Je le vérifie avec une xsl qui me tagge le xml généré avec une date.
Tant que je n'ai pas touché à la ressource Exist (ou à une xsl du tuyau)
la date ne change pas, et si je modifie la ressource exist, tout est
regénéré )
Maintenant, les questions que je me pose
* Faut il fabriquer un TimeStampValidity à chaque fois que
getValidity() est appelé ?
* 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
* J'imagine que tant que l'api xmldb ne proposera pas un équivalent de
getLastModified() ce ne serait pas une bonne pratique de mettre ce genre
de choses selon chaque implémentation xmldb ?
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
Bertrand Delacretaz wrote:
> Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit :
>
>> ...Bravo à Anyware pour la réactivité !..
>
> A propos, il se passe des choses sympa sur cocoon-dev:
> http://marc.theaimsgroup.com/?t=113525903600002&r=1&w=2
Désolé, je ne suis plus inscrit côté anglais, mais je vote
OUI !
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Expliquer ce qu'est un committer (était Re: XMLDBSource, cacheable + questions)
Posted by Sylvain Wallez <sy...@apache.org>.
Jean-Baptiste Quenot wrote:
> Merci à tous,
>
> Voilà un beau cadeau de Noël. Par contre je ne sais pas trop
> comment je vais expliquer ça à mon entourage, j'ai bien envie de
> leur annoncer la nouvelle mais je ne sais pas comment m'y prendre,
> vous avez des idées? « Ca y est, je suis committer Cocoon » je
> pense qu'on risque de me regarder avec des gros yeux et de me
> répondre: « tu es Quoi? »...
>
> Bertrand as-tu une explication simple pour des non-informaticiens?
>
Héhé, THE question :-)
Tu peux dire "je bosse à travers Internet avec des gens que je n'ai
jamais vus, répartis sur toute la planète, sur un logiciel qui est
disponible gratuitement pour qui en a envie. Je n'ai d'ailleurs aucun
moyen de savoir qui sont ses utilisateurs. J'écris des parties de ce
logiciel, et je viens d'obtenir le droit d'enregistrer ces parties sur
des machines qui sont... à Los Angeles... à Amsterdam... je sais pas
trop où en fait. Et je suis super-content".
Et après, tu regardes leur tête ! Bon courage :-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Expliquer ce qu'est un committer (était Re: XMLDBSource, cacheable + questions)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 22 déc. 05, à 18:45, Jean-Baptiste Quenot a écrit :
> Bertrand as-tu une explication simple pour des non-informaticiens?
Euh...l'explication de Sylvain est bonne!
Si on voulait imager plus, c'est un peu comme si on construisait une
cathédrale (ouais, je sais c'est plutôt un bazar ;-) et que les
committers sont ceux qui ont le droit de poser les pierres directement
au bon endroit, au lieu de préparer les pierres que les autres vont
poser. Et si le bon endroit ne plaît pas aux autres, ils retirent les
pierres...et il faut discuter un peu pour se mettre d'accord ;-)
-Bertrand
Re: XMLDBSource, cacheable + questions
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
Merci à tous,
Voilà un beau cadeau de Noël. Par contre je ne sais pas trop
comment je vais expliquer ça à mon entourage, j'ai bien envie de
leur annoncer la nouvelle mais je ne sais pas comment m'y prendre,
vous avez des idées? « Ca y est, je suis committer Cocoon » je
pense qu'on risque de me regarder avec des gros yeux et de me
répondre: « tu es Quoi? »...
Bertrand as-tu une explication simple pour des non-informaticiens?
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
[OT] 33% de committers francophones en plus ;-)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 22 déc. 05, à 15:08, Sylvain Wallez a écrit :
> ...Le contingent de committers francophones va grossir de 50% !
> Terrible :-)
33%! Tu oublies Alfred Nathaniel qui travaille à Genève, il parle
parfaitement le français aussi, bien que franchement polyglotte.
Mais bon, que Jean-Baptiste représente 50% ou 33%, on est de toutes
façons très contents ;-)
-Bertrand
Re: XMLDBSource, cacheable + questions
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit :
>
>> ...Bravo à Anyware pour la réactivité !..
>
> A propos, il se passe des choses sympa sur cocoon-dev:
> http://marc.theaimsgroup.com/?t=113525903600002&r=1&w=2
Le contingent de committers francophones va grossir de 50% ! Terrible :-)
Bravo Jean-Baptiste... et joyeux Noël ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 22 déc. 05, à 14:41, Frédéric Glorieux a écrit :
> ...Bravo à Anyware pour la réactivité !..
A propos, il se passe des choses sympa sur cocoon-dev:
http://marc.theaimsgroup.com/?t=113525903600002&r=1&w=2
-Bertrand
Re: XMLDBSource, cacheable + questions
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Frédéric Glorieux:
> > Pour les requêtes effectuées en XQuery, tu peux utiliser
> > XQueryGenerator qui est cacheable avec un paramètre optionnel
> > de durée de validité.
> Je le cherchais dans les sources Cocoon... Donc, dans Exist,
> c'est déjà ça, new ExpiresValidity().
En effet, XQueryGenerator est dans les sources d'eXist, désolé de
ne pas l'avoir mentionné. C'est dommage que le bloc XMLDB de
Cocoon soit si éloigné d'eXist, cela est probablement du à la
stagnation de l'API XMLDB.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
>> Tu as une idée des risques encourus ?
>
> Des configs non prises en compte : un cas *très* particulier (hélas,
> sinon le problème aurait été reglé depuis longtemps). Un problème
> potentiel de verrouillage également, rencontré de façon *très*
> épisodique (mais qui pourrait flinguer la db) : il faudra bien le régler
> un jour.
>
> Non, le plus gros problème de ce cache... c'est quand il a beaucoup
> d'entrées (i.e. de collections),
J'ai vu :o)
> surtout quand il faut les partager à
> plusieurs :-)
OK, donc globalement, la date est bonne, au pire, c'est Exist qui est
flingué, mais en ce cas, la cache cocoon peut faire illusion et sauver
la réponse au public ?
> > Le genre d'opérations qu'il
>> faudrait faire suivre d'un nettoyage du cache pour avoir plus
>> d'assurance ?
>
> Le cache n'est pas disponible de l'extérieur.
Je veux dire la cache Cocoon, quand elle commence à garder des mauvaises
entrées ?
>> Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir,
>> mais cela ne fait pas des millions de lignes.
>
> Dépose le sur la mailing-list ou,mieux sur la page Sourceforge du projet.
Pour le peu de lignes que cela représente, j'ai honte d'en faire un
pataques. Poster les lignes me coûtent peu, les garantir et les tester
dans le contexte de votre appli Cocoon, c'est plus long.
> Comme dans tout projet, tout est bon à prendre : doc, traductions,
> reviewing, support technique, test cases (du Java assez simple en
> général)... Sinon, il y a toujours l'appli Armageddon à réaliser :
> monter la XQueryTestSuite sur eXist :-)
Que les cocooneux utilisateurs d'Exist t'entendent.
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Pierrick Brihaye <pi...@free.fr>.
Frédéric Glorieux wrote:
> http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp()
>
> Oops, pas vu, je cherchais le symétrique à
> Resource.getLastModificationTime()
Comme expliqué précédemment, la granularité est différente, mais c'est
vraisemblablment de peu d'importance.
> > De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il
> > faut et, plus souvent, que son rafraîchissement n'est pas toujours
> > correctement répercuté comme il se doit.
>
> Tu as une idée des risques encourus ?
Des configs non prises en compte : un cas *très* particulier (hélas,
sinon le problème aurait été reglé depuis longtemps). Un problème
potentiel de verrouillage également, rencontré de façon *très*
épisodique (mais qui pourrait flinguer la db) : il faudra bien le régler
un jour.
Non, le plus gros problème de ce cache... c'est quand il a beaucoup
d'entrées (i.e. de collections), surtout quand il faut les partager à
plusieurs :-)
> Le genre d'opérations qu'il
> faudrait faire suivre d'un nettoyage du cache pour avoir plus d'assurance ?
Le cache n'est pas disponible de l'extérieur.
> > En ce qui concerne la source Cocoon et sans vouloir rallumer la
> > polémique sur les licences qui a meublé les premiers jours de cette
> > liste, vous savez où il faut envoyer les patches :-)
>
> Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir, mais
> cela ne fait pas des millions de lignes.
Dépose le sur la mailing-list ou,mieux sur la page Sourceforge du projet.
> En ce qui concerne les autres aspects de développements d'Exist, je
> comprends cet appel aux bonnes volontés, mais le défi est dur à relever.
> Il faut non seulement du temps, mais aussi pas mal de compétence !
Comme dans tout projet, tout est bon à prendre : doc, traductions,
reviewing, support technique, test cases (du Java assez simple en
général)... Sinon, il y a toujours l'appli Armageddon à réaliser :
monter la XQueryTestSuite sur eXist :-)
A+
p.b.
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Le timestamp existe sur les collections et est même documenté dans les
> antiques Javadoc :
>
http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp()
Oops, pas vu, je cherchais le symétrique à
Resource.getLastModificationTime()
Super !
> La façon dont il est généré est un peu particulière car c'est une info
> fournie par le cache de collections, le truc bancal mais relativement
> efficace trouvé par eXist pour centraliser les opérations de lecture,
> écriture (et donc de verrouillage) et quelques autres goodies.
>
> De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il
> faut et, plus souvent, que son rafraîchissement n'est pas toujours
> correctement répercuté comme il se doit.
Tu as une idée des risques encourus ? Le genre d'opérations qu'il
faudrait faire suivre d'un nettoyage du cache pour avoir plus d'assurance ?
> tout un
> chacun, y compris Frédéric Glorieux ;-), peut s'y coller.
Là dessus il ne vaut mieux pas me laisser faire.
> En ce qui concerne la source Cocoon et sans vouloir rallumer la
> polémique sur les licences qui a meublé les premiers jours de cette
> liste, vous savez où il faut envoyer les patches :-)
Pour ça, pas de problème. Je n'ai pas d'url publique à te fournir, mais
cela ne fait pas des millions de lignes.
<snip/>
En ce qui concerne les autres aspects de développements d'Exist, je
comprends cet appel aux bonnes volontés, mais le défi est dur à relever.
Il faut non seulement du temps, mais aussi pas mal de compétence !
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Pierrick Brihaye <pi...@free.fr>.
Bonsoir,
Frédéric Glorieux wrote:
> Vu la quantité d'informations qu'ils maintiennent, il peuvent
> probablement faire mieux. J'ai poussé sur la liste Exist en espérant un
> commit pour avoir un getLastModified() au niveau d'une collection.
Plus tard :
> En ce cas, c'est à Exist de proposer son implémentation d'un cocoon Source plus complet ?
Puis après :
> Je sais un commiter Exist qui écoute aussi ici.
Pensant être le dit commiter, je ne sais pas quoi répondre si ce n'est
que ni la première fonctionnalité, ni la seconde ne font partie de mes
priorités. Bien sûr, comme dans tout bon projet open source, tout un
chacun, y compris Frédéric Glorieux ;-), peut s'y coller.
Je puis comme d'habitude, et dans la mesure de mes moyens, donner des
conseils. En attendant, voici mon avis :
Le timestamp existe sur les collections et est même documenté dans les
antiques Javadoc :
http://exist.sourceforge.net/api/org/exist/collections/Collection.html#getTimestamp()
La façon dont il est généré est un peu particulière car c'est une info
fournie par le cache de collections, le truc bancal mais relativement
efficace trouvé par eXist pour centraliser les opérations de lecture,
écriture (et donc de verrouillage) et quelques autres goodies.
De plus, je sais pertinement que ce cache n'est pas rafraîchi comme il
faut et, plus souvent, que son rafraîchissement n'est pas toujours
correctement répercuté comme il se doit.
Il y a pas mal de refactorings à faire là-dedans, avec des pincettes
évidemment (je viens de me faire flamer pour avoir stabilisé une
non-feature :-)
En ce qui concerne la source Cocoon et sans vouloir rallumer la
polémique sur les licences qui a meublé les premiers jours de cette
liste, vous savez où il faut envoyer les patches :-)
Je tiens seulement à indiquer que les URI eXist sont, hum, bancales et
que j'ai écrit une classe XmldbURI pour essayer de mettre de l'ordre
dans tous ça. Bien sûr, ça aurait été plus simple avec des specs xmldb
blindées... mais, dans ce cas précis, je pense que l'implémentation fera
la spec et non l'inverse : avis aux amateurs !
Je n'accapare pas plus la bande passante car on est assez loin de
Cocoon. Il faut simplement se rendre compte que eXist c'était jusqu'à il
y a peu un développeur et un "conseiller scientifique". Même si la
situation s'est améliorée, les contributeurs manquent cruellement et les
efforts sont très difficiles à coordonner...
J'ajoute que pas mal de dév se décident sur le Chat (auquel je n'ai
accès que depuis chez moi :-( ).
A+
p.b.
M'enfin, ça sera mieux en 2006 :-)
A+
p.b.
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Bonjour Frédéric,
Bonjour,
Bravo à Anyware pour la réactivité !
> Pour les requêtes effectuées en XQuery, tu peux utiliser
> XQueryGenerator qui est cacheable avec un paramètre optionnel de
> durée de validité.
Je le cherchais dans les sources Cocoon...
Donc, dans Exist, c'est déjà ça, new ExpiresValidity().
> Attention à getLastModified(), cela n'est pas satisfaisant pour
> une XQuery car pour calculer la date de modification on est obligé
> de rééxecuter la XQuery.
Vu la quantité d'informations qu'ils maintiennent, il peuvent
probablement faire mieux. J'ai poussé sur la liste Exist en espérant un
commit pour avoir un getLastModified() au niveau d'une collection.
En ce cas, si la collection de contexte d'une xquery n'a pas changé, les
résultats seront les mêmes ?
> Là je n'ai pas trop compris, pourquoi as-tu besoin
> de récupérer user et password alors qu'ils sont déjà
> configurés correctement dans cocoon.xconf sur <driver
> class="org.exist.xmldb.DatabaseImpl"...>?
Dans le contexte Sitemap, inutile, tout fonctionnne.
Cependant, pour certaines opérations, il est nécessaire de pouvoir
récupérer en JAVA une Collection xmldb (pour par exemple un service
UserManagement)
Comme XMLDBSource à tout le nécessaire pour récupérer une collection,
selon les informations qu'aura autorisé un administrateur dans un
cocoon.xconf, et ne sachant pas lire en JAVA un cocoon.xconf, j'ai
trouvé cette solution pratique (pour être franc, j'ai seulement
recompilé avec "public" au lieu de "protected")
> Attention aussi quand l'application
> accède à eXist par le réseau, getLastModified() a alors le coût de
> transport et le coût de consultation de la base de données XML, y
> compris quand tu accèdes simplement à un document sans requête
> XQuery ou XPath.
En effet, je n'y avais pas pensé. Je fonctionnne en local, mais s'il
fallait être générique, il faudrait alors un truc du genre aller voir le
lastModified toutes les secondes s'il s'agit d'une "RemoteCollection".
>> * Faut il fabriquer un TimeStampValidity à chaque fois que
>> getValidity() est appelé ?
>
> Oui, cette méthode n'est appellée à nouveau que quand la source
> n'est plus valide.
OK, donc pour ça c'est bon.
> En effet difficile de l'intégrer à Cocoon si ça n'est pas dans
> l'interface.
Normal.
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
Bonjour Frédéric,
Pour les requêtes effectuées en XQuery, tu peux utiliser
XQueryGenerator qui est cacheable avec un paramètre optionnel de
durée de validité.
En ce qui concerne XMLDBSource, voici quelques réponses à tes
questions:
> * Faut il fabriquer un TimeStampValidity à chaque fois que
> getValidity() est appelé ?
Oui, cette méthode n'est appellée à nouveau que quand la source
n'est plus valide.
> * 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
Là je n'ai pas trop compris, pourquoi as-tu besoin
de récupérer user et password alors qu'ils sont déjà
configurés correctement dans cocoon.xconf sur <driver
class="org.exist.xmldb.DatabaseImpl"...>?
> * J'imagine que tant que l'api xmldb ne proposera pas
> un équivalent de getLastModified() ce ne serait pas une
> bonne pratique de mettre ce genre de choses selon chaque
> implémentation xmldb ?
En effet difficile de l'intégrer à Cocoon si ça n'est pas dans
l'interface.
Attention à getLastModified(), cela n'est pas satisfaisant pour
une XQuery car pour calculer la date de modification on est obligé
de rééxecuter la XQuery. Attention aussi quand l'application
accède à eXist par le réseau, getLastModified() a alors le coût de
transport et le coût de consultation de la base de données XML, y
compris quand tu accèdes simplement à un document sans requête
XQuery ou XPath.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
>> En ce cas, c'est à Exist de proposer son implémentation d'un cocoon
>> Source plus complet ?
>
> Effectivement, je pense que ça serait une très bonne solution. Exist
> vient avec un certain nombre de composants Cocoon, alors pourquoi pas
> une "source amélioriée"?
Je sais un commiter Exist qui écoute aussi ici.
>> 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ù.
>
> Ouaip :-)
En y réfléchissant, je vois d'autres mauvaises raisons de rendre le
user:pass public.
Quand l'instance Exist est crée de neuf par
DatabaseManager.registerDatabase(db) contre un fichier de conf,
l'utilisateur souhaité en cocoon.xconf peut ne pas encore exister.
Pour Exist, avec l'utilisateur défaut "admin:null", je crée
l'utilisateur demandé en cocoon.xconf. Est-ce bon à mettre en
XMLDBSourceFactory ?
Pour les backups (hors API xmldb), Exist demande aussi un user:pass.
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
>> 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 ?
Effectivement, je pense que ça serait une très bonne solution. Exist
vient avec un certain nombre de composants Cocoon, alors pourquoi pas
une "source amélioriée"?
>> 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 vrai. Mais plus que l'objet validité, c'est l'objet Resource qui
est coûteux. Et ce dernier est conservé dans la Source.
>>> * 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ù.
Ouaip :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> 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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org
Re: XMLDBSource, cacheable + questions
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
> Bonjour,
>
> Je cherche à avoir un générateur xmldb cacheable.
> J'utilise Exist.
> Dans certains cas, Exist sait donner une date de modification (quand
> on demande une ressource précise). Il est possible que ceci puisse
> s'étendre aux collections, et donc aux requêtes effectuées sur une
> collection.
>
> Je fais marcher, mais je ne sais pas si c'est optimal.
>
> Comme je vois que Sylvain à toucher à XMLDBSource il y a moins de 3
> semaines
> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/xmldb/trunk/java/org/apache/cocoon/components/source/impl/
>
> Mes questions ont peut être un peu d'actualité.
>
> (Je m'en suis d'ailleurs aperçu un peu tard. Je travaillais sur une
> vieille version de la classe, beaucoup moins bien factorisée)
>
> J'ai surchargé
> XMLDBSource.getValidity()
> pour qu'il renvoit un TimeStampValidity(lastModified) quand il est
> possible de récupérer un long lastModified.
> ça marche.
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...
> (Je le vérifie avec une xsl qui me tagge le xml généré avec une date.
> Tant que je n'ai pas touché à la ressource Exist (ou à une xsl du
> tuyau) la date ne change pas, et si je modifie la ressource exist,
> tout est regénéré )
>
> Maintenant, les questions que je me pose
>
> * Faut il fabriquer un TimeStampValidity à chaque fois que
> getValidity() est appelé ?
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.
> * 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. Je pensais d'ailleurs mettre un accès
public à la ressource et la collection dans XMLDBSource. Ca pourrait aider?
> * J'imagine que tant que l'api xmldb ne proposera pas un équivalent
> de getLastModified() ce ne serait pas une bonne pratique de mettre ce
> genre de choses selon chaque implémentation xmldb ?
C'est plus une question de licence que de bonne pratique...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org