Bonjour, Je me réponds :-) au cas où ça puisse aider quelqu'un qui rencontrerait le même cas. Dans mon formulaire, j'avais un input name="action". Pour cette raison CFormsForm.js ne retrouvait plus l'attribut "action" du formulaire et renvoyait [object HTMLInputElement]. Il semble en effet qu'il fait un confusion entre cet attribut de formulaire et l'input qui s'appelle "action"... En renommant cet input, le problème est résolu. Un grand merci à Johan Cwiklinski. André Davignon Le 15/05/2008 10:40, > Marc Salvetti (par Internet, dépôt users-fr-return-2062-andre.davignon=equipement.gouv.fr@cocoon.apache.org) a écrit : > ca n'est probablement pas le probleme mais il me semble que le > submitonchange="true" n'est pas necessaire pour les input de type submit, > c'est plus pour les listes de selection ou les champs texte. > > Pour ton probleme, je pense qu'il faut passer au debugger javascript pour > arriver a voir ce qui se passe. > > Il y a une extention firefox venkmark qui est pas mal pour ça > > Marc > --------------------------------------------------------------------- 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
ca n'est probablement pas le probleme mais il me semble que le
submitonchange="true" n'est pas necessaire pour les input de type submit,
c'est plus pour les listes de selection ou les champs texte.
Pour ton probleme, je pense qu'il faut passer au debugger javascript pour
arriver a voir ce qui se passe.
Il y a une extention firefox venkmark qui est pas mal pour ça
Marc
2008/5/15 <andre.davignon@free.fr>:
>
>
> > Si mon souvenir est bon, normalement dans le html tu devrais voir sur tes
> > actions ajax qqchose du genre onclick="submit_form(this)" (ajouté
> > automatiquement par le block forms sur les widgets) qui va envoyer une
> > requete xmlhttprequest, laquelle doit etre ensuite traitee au niveau de
> la
> > sitemap de facon a renvoyer uniquement les elements a mettre a jour (les
> > bu:replace)
>
> Oui.
>
> >
> > en gros, dans ton pipe final il faut qq chose comme
> >
> > ...
> > <map:transform type="browser-update"/>
> > ...
> > <map:select type="ajax-request">
> > <map:when test="true">
> > <map:serialize type="xml"/>
> > </map:when>
> > <map:otherwise>
> > <map:serialize type="html"/>
> > </map:otherwise>
> > </map:select>
>
> C'est ce qui figure. Le transformer browser-update envoie bien les <bu>
> dans ma
> configuration précédente avec le pipe
>
> <map:match type="request" pattern="continuation-id">
> <map:call continuation="{request-param:continuation-id}"/>
> </map:match>
>
> > il faut aussi preciser au niveau des widgets qu'ils doivent envoyer le
> form
> > sur le onchange ce qui doit creer les onclick=form_submit :
> >
> > <ft:widget id="****">
> > <fi:styling submit-on-change="true"/>
> > </ft:widget>
> >
>
> Bien vu. Je viens de le faire et en HTML, je me retrouve donc avec des
> input de
> ce genre :
>
> <input id="addCHAMP" type="submit" name="addCHAMP" title="" value="+"
> class="forms action active" onchange="forms_submitForm(this)"/>
>
> Hélas, les actions Ajax déclenchent toujours des POST de ce type :
>
> http://serveur/appli/5Bobject%20HTMLInputElement%5D
>
> Et donc n'appellent pas l'action du formulaire.
> Je ne vois pas pourquoi....
>
> Que peut-il se passer ?
>
> André Davignon
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
> Si mon souvenir est bon, normalement dans le html tu devrais voir sur tes
> actions ajax qqchose du genre onclick="submit_form(this)" (ajouté
> automatiquement par le block forms sur les widgets) qui va envoyer une
> requete xmlhttprequest, laquelle doit etre ensuite traitee au niveau de la
> sitemap de facon a renvoyer uniquement les elements a mettre a jour (les
> bu:replace)
Oui.
>
> en gros, dans ton pipe final il faut qq chose comme
>
> ...
> <map:transform type="browser-update"/>
> ...
> <map:select type="ajax-request">
> <map:when test="true">
> <map:serialize type="xml"/>
> </map:when>
> <map:otherwise>
> <map:serialize type="html"/>
> </map:otherwise>
> </map:select>
C'est ce qui figure. Le transformer browser-update envoie bien les <bu> dans ma
configuration précédente avec le pipe
<map:match type="request" pattern="continuation-id">
<map:call continuation="{request-param:continuation-id}"/>
</map:match>
> il faut aussi preciser au niveau des widgets qu'ils doivent envoyer le form
> sur le onchange ce qui doit creer les onclick=form_submit :
>
> <ft:widget id="****">
> <fi:styling submit-on-change="true"/>
> </ft:widget>
>
Bien vu. Je viens de le faire et en HTML, je me retrouve donc avec des input de
ce genre :
<input id="addCHAMP" type="submit" name="addCHAMP" title="" value="+"
class="forms action active" onchange="forms_submitForm(this)"/>
Hélas, les actions Ajax déclenchent toujours des POST de ce type :
http://serveur/appli/5Bobject%20HTMLInputElement%5D
Et donc n'appellent pas l'action du formulaire.
Je ne vois pas pourquoi....
Que peut-il se passer ?
André Davignon
---------------------------------------------------------------------
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
Si mon souvenir est bon, normalement dans le html tu devrais voir sur tes
actions ajax qqchose du genre onclick="submit_form(this)" (ajouté
automatiquement par le block forms sur les widgets) qui va envoyer une
requete xmlhttprequest, laquelle doit etre ensuite traitee au niveau de la
sitemap de facon a renvoyer uniquement les elements a mettre a jour (les
bu:replace)
en gros, dans ton pipe final il faut qq chose comme
...
<map:transform type="browser-update"/>
...
<map:select type="ajax-request">
<map:when test="true">
<map:serialize type="xml"/>
</map:when>
<map:otherwise>
<map:serialize type="html"/>
</map:otherwise>
</map:select>
il faut aussi preciser au niveau des widgets qu'ils doivent envoyer le form
sur le onchange ce qui doit creer les onclick=form_submit :
<ft:widget id="****">
<fi:styling submit-on-change="true"/>
</ft:widget>
Le 15 mai 2008 14:12, <andre.davignon@free.fr> a écrit :
> Bonjour,
>
> Merci pour la réponse.
> Oui, j'ai bien un pipe qui traite ça :
>
> <map:match type="request" pattern="continuation-id">
> <map:call continuation="{request-param:continuation-id}"/>
> </map:match>
>
> J'ai essayé celui que tu me conseilles et là, les actions Ajax ne
> fonctionnent
> plus. je crois comprendre :
>
> Mes actions Ajax déclenchent des POST du genre :
> http://serveur/appli/%5Bobject%20HTMLInputElement%5D
>
> Cela ne pose pas de problème pour les actions Ajax (ajout de ligne de
> repeater,
> qui fonctionne), mais en pose lors de la validation globale du formulaire.
>
> Après m'être renseigné sur ce type de problème, il semblerait que l'action
> du
> formulaire ne soit pas appelée, car non "reconnue". Et je ne sais pas
> pourquoi.
> Et donc, ton pipe n'est pas exécuté...
>
> Par contre les POST "manuels" continue.html fonctionnent bien, ce qui veut
> dire
> que ton pipe est efficace, le formulaire est validé et le sendPage bien
> exécuté.
>
> Reste à faire en sorte que les POST appellent bien l'action associée au
> formulaire.
>
> Une idée ?
>
> André Davignon
>
>
>
> Le 15/05/2008 06:20, > Marc Salvetti (par Internet, dépôt
> users-fr-return-2058-andre.davignon=equipement.gouv.fr@cocoon.apache.org)
> a
> écrit :
> > Bonjour André,
> >
> > est-ce que tu as bien un pipe pour la continuation.
> >
> > Dans mon appli j'ai plutot qq chose comme ca et ca marche bien :
> >
> > <ft:form-template action="continue.html" method="post" ajax="true">
> > <ft:widget id="continuation-id"><fi:styling
> type="hidden"/><fi:styling
> > value="#{$cocoon/continuation/id}"/></ft:widget>
> >
> > et dans la sitemap
> >
> > <map:match pattern="**continue.html">
> > <map:call
> > continuation="{request-param:continuation-id}"/>
> > </map:match>
> >
> > Marc
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
Bonjour,
Merci pour la réponse.
Oui, j'ai bien un pipe qui traite ça :
<map:match type="request" pattern="continuation-id">
<map:call continuation="{request-param:continuation-id}"/>
</map:match>
J'ai essayé celui que tu me conseilles et là, les actions Ajax ne fonctionnent
plus. je crois comprendre :
Mes actions Ajax déclenchent des POST du genre :
http://serveur/appli/%5Bobject%20HTMLInputElement%5D
Cela ne pose pas de problème pour les actions Ajax (ajout de ligne de repeater,
qui fonctionne), mais en pose lors de la validation globale du formulaire.
Après m'être renseigné sur ce type de problème, il semblerait que l'action du
formulaire ne soit pas appelée, car non "reconnue". Et je ne sais pas pourquoi.
Et donc, ton pipe n'est pas exécuté...
Par contre les POST "manuels" continue.html fonctionnent bien, ce qui veut dire
que ton pipe est efficace, le formulaire est validé et le sendPage bien exécuté.
Reste à faire en sorte que les POST appellent bien l'action associée au
formulaire.
Une idée ?
André Davignon
Le 15/05/2008 06:20, > Marc Salvetti (par Internet, dépôt
users-fr-return-2058-andre.davignon=equipement.gouv.fr@cocoon.apache.org) a
écrit :
> Bonjour André,
>
> est-ce que tu as bien un pipe pour la continuation.
>
> Dans mon appli j'ai plutot qq chose comme ca et ca marche bien :
>
> <ft:form-template action="continue.html" method="post" ajax="true">
> <ft:widget id="continuation-id"><fi:styling type="hidden"/><fi:styling
> value="#{$cocoon/continuation/id}"/></ft:widget>
>
> et dans la sitemap
>
> <map:match pattern="**continue.html">
> <map:call
> continuation="{request-param:continuation-id}"/>
> </map:match>
>
> Marc
>
>
---------------------------------------------------------------------
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
Bonjour André,
est-ce que tu as bien un pipe pour la continuation.
Dans mon appli j'ai plutot qq chose comme ca et ca marche bien :
<ft:form-template action="continue.html" method="post" ajax="true">
<ft:widget id="continuation-id"><fi:styling type="hidden"/><fi:styling
value="#{$cocoon/continuation/id}"/></ft:widget>
et dans la sitemap
<map:match pattern="**continue.html">
<map:call
continuation="{request-param:continuation-id}"/>
</map:match>
Marc
2008/5/14 <andre.davignon@free.fr>:
> Bonjour,
>
> J'ai un formulaire Ajax (<ft:form-template method="POST" ajax="true"
> action="#{$cocoon/continuation/id}"> avec le flowscript suivant :
>
> var form = new Form(cocoon.parameters.form);
> form.createBinding(cocoon.parameters.binding);
> ...
> form.load(document);
> form.showForm(cocoon.parameters.show);
> cocoon.sendPage(cocoon.parameters.redirect);
>
> Les actions Ajax fonctionnent bien (ajout et suppression de ligne de
> repeater,
> etc...) mais la validation globale du formulaire avec le widget fd:submit
> n'a
> pas d'effet.
>
> Le formulaire "reste" dans form.showForm(cocoon.parameters.show) et le
> sendPage
> n'est pas exécuté.
>
> Y aurait-il quelque chose que j'aie oublié ?
>
> André Davignon
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
Bonjour,
J'ai un formulaire Ajax (<ft:form-template method="POST" ajax="true"
action="#{$cocoon/continuation/id}"> avec le flowscript suivant :
var form = new Form(cocoon.parameters.form);
form.createBinding(cocoon.parameters.binding);
...
form.load(document);
form.showForm(cocoon.parameters.show);
cocoon.sendPage(cocoon.parameters.redirect);
Les actions Ajax fonctionnent bien (ajout et suppression de ligne de repeater,
etc...) mais la validation globale du formulaire avec le widget fd:submit n'a
pas d'effet.
Le formulaire "reste" dans form.showForm(cocoon.parameters.show) et le sendPage
n'est pas exécuté.
Y aurait-il quelque chose que j'aie oublié ?
André Davignon
---------------------------------------------------------------------
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
Bonjour,
J'ai des instances XML qui sont stockées dans une base de données et qui
comportent des caractères comme le tiret insécable (–). Lorsque
je requête la base à l'aide de la taglib esql, j'obtiens
systématiquement l'erreur suivante :
Caused by: org.xml.sax.SAXParseException: An invalid XML character
(Unicode: 0x13) was found in the element content of the document.
at
org.apache.excalibur.xml.impl.JaxpParser.fatalError(JaxpParser.java:463)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source)
at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315)
at
org.apache.cocoon.components.language.markup.xsp.XSPUtil.includeInputSource(XSPUtil.java:275)
... 65 more
Caused by: org.xml.sax.SAXParseException: An invalid XML character
(Unicode: 0x13) was found in the element content of the document.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
... 78 more
Pourtant lorsque j'utilise des parsers XML en dehors du framework
cocoon, je n'obtiens pas d'erreurs sur ces instances XML.
Quelqu'un aurait une solution ?
Cordialement,
--
4Dconcept au Salon du Livre
Au Parc des Expositions, Porte de Versailles, du 14 au 19 mars 2008
Rendez-vous sur notre stand n°A072 (Hall 1, espace lectures de dem@in).
Sébastien KLIMA
DIS
41- 43 Avenue du Centre 78180 Montigny Le Bretonneux
Tél : 01.61.08.50.24 - Standard : 01.61.08.50.20 - Fax : 01.61.38.24.41
www.4dconcept.fr <http://www.4dconcept.fr>
---------------------------------------------------------------------
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
Bonjour, Dans une application Coccoon 2.1.10, j'essaie de reproduire le fonctionnement de l'exemple http://serveur:8080/cocoon/samples/blocks/forms/do-dynaRepeater.flow. Avec le même pipeline, en suivant http://cocoon.apache.org/2.1/userdocs/ajax.html. En regardant la source de cette page (do-dynaRepeater.flow), je vois que les javascripts dojo.js et cocoon.js sont chargés. Mais je n'arrive pas à reproduire cela dans mon application. Donc, le script cocoon.forms.ajax = true ne passe pas. Y a-t-il quelque chose d'évident qui m'échappe ? André Davignon --------------------------------------------------------------------- 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
Je plussoie très largement Sylvain, étant bien placé pour en parler puisqu'un des plus gros utilisateurs de Cocoon à Anyware. Evidemment, Cocoon 2.1.x étant très stable Cocoon 2.2 pas encore assez, il y a moins d'activité le concernant de notre côté, mais c'est toujours la brique de base inamovible de notre CMS. Et ce pour un certain temps je pense... :-) A noter, même si ce n'est pas le lieu, qu'Anyware propose toujours des formations et de l'expertise sur le sujet, en dehors de ses activités logicielles autour des applis CMS/GED. Cédric Sylvain Wallez a écrit : > Sébastien Geindre wrote: >> bjr à tous, >> >> Je ne souhaite en aucun cas lancer un troll sur anyware et >> coocon...Sylvain et Anyware ont apporté tellement à la communauté >> cocoon qu'il serait stupide de jeter la pierre à quiconque. >> >> Par contre, j'aimerais bien connaître les raisons qui ont poussé >> Anyware a délaissé Cocoon et à investir dans d'autres framework web >> (Wicket,...) >> >> D'ou le sujet... > > Vaste sujet ! > > Anyware Technologies n'a pas vraiment délaissé Cocoon, mais a évolué > d'une mono-culture cocoonesque à la reconnaissance qu'à différents > besoins correspondent différents outils, encouragé dans cette voie par > l'évolution de la technologie, aussi bien côté browser que côté > frameworks. > > Concrètement, Anyware utilise Cocoon là où son utilisation est > justifiée, c'est à dire dans les applications de type CMS et chaînes > de publication documentaires, là où on a besoin de pipelines de > transformations. Cocoon est encore sans équivalent dans ce domaine (à > part Orbeon). > > Dans le domaine des applications web (gros formulaires, écrans très > interactifs avec Ajax) auquel Cocoon s'était "attaqué" et où j'avais > personnellement été très actif, Cocoon a pu être précurseur et > novateur, mais il a été rapidement dépassé par des nouveaux venus > dédiés à ce domaine tels que Wicket ou GWT, mais aussi des approches > plus "client-side" comme DWR où la composante serveur est purement > applicative. > > Ces nouveaux arrivants dans les applications web, en poussant la barre > du côté "tout en Java/Javascript" là où Cocoon était "un max en XML" > ont aussi apporté de l'air frais à une époque ou nombreux étaient ceux > qui avaient une saturation des "crochet ouvrant, crochet fermant". La > programmation déclarative a ses limites. > > Au final, le constat a été qu'utiliser Cocoon dans des applications > constituées essentiellement de formulaires n'avait pas vraiment de > sens, et que les nouveaux frameworks spécialisés dans ce domaine > apportaient plus de productivité. Wicket est de ceux-là, et nous > l'avons utilisé avec succès et satisfaction pour ce type d'application. > > En conclusion, il n'y a pas d'outil magique, et il ne faut pas essayer > de vouloir tout faire avec Cocoon. Il a par contre ses domaines > d'application privilégiés, qui sans hasard correspondent à sa mission > initiale : les chaînes de transformations XML, très adaptées pour les > applications de type CMS. Anyware a d'ailleurs une grosse activité CMS > utilisant le produit maison Ametys bâti sur Cocoon, qui a été mis en > opensource [1]. > > D'un point de vue plus personnel, j'ai aussi évolué en prenant il y a > 2 ans d'importantes responsabilités dans le projet Joost [2] où Cocoon > n'avait pas vraiment sa place. Ce changement coïncidant avec une > saturation du tout XML et des gros framework, revenir à du tout-Java > avec des servlets (presque) de base en frontal de grosse logique > métier, et utiliser Wicket sur des applications de type back-office a > été un renouvellement presque salutaire. > > Dans l'étape suivante se mon évolution professionnelle (teasing > teasing, à suivre sur mon blog dans les prochaines semaines), je vais > à nouveau avoir besoin de transformations XML. Mais je ne crois pas > que je reviendrai à Cocoon, au moins sous sa forme actuelle. J'ai > besoin de quelque chose de plus "léger", plus agile, qu'on puisse > utiliser directement depuis Java ou Javascript côté serveur. C'est une > tendance qu'on sent depuis longtemps au sein du groupe des > développeurs de Cocoon, et il est possible qu'un "mini-Cocoon" > apparaisse dans le futur. > > Au final, la conclusion est que Cocoon est un produit mature et > éprouvé, très adapté à certains problèmes, mais pas à tous. > > Voilà. Merci à ceux qui ont lu jusqu'ici, j'espère que ça clarifie les > choses. > > Sylvain > > [1] http://www.ametys.org/ > [2] http://bluxte.net/blog/2006-11/15-28-34.html > -- Cédric Damioli Solutions GED/CMS Ametys ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com http://www.ametys.fr / http://www.ametys.org --------------------------------------------------------------------- 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
>> Et ce serait quoi ? Encore un secret, ou un projet public ? > > Prochain épisode dans 2 semaines. Patience, patience :-P Depuis le temps que je cherche un Cocoon light, 2 semaines ne seront plus grand chose. -- Frédéric Glorieux --------------------------------------------------------------------- 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
Frédéric Glorieux wrote: >> Dans l'étape suivante se mon évolution professionnelle (teasing >> teasing, à suivre sur mon blog dans les prochaines semaines), je vais >> à nouveau avoir besoin de transformations XML. Mais je ne crois pas >> que je reviendrai à Cocoon, > > Et ce serait quoi ? Encore un secret, ou un projet public ? Prochain épisode dans 2 semaines. Patience, patience :-P Sylvain -- Sylvain Wallez - http://bluxte.net --------------------------------------------------------------------- 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
> Dans l'étape suivante se mon évolution professionnelle (teasing teasing, > à suivre sur mon blog dans les prochaines semaines), je vais à nouveau > avoir besoin de transformations XML. Mais je ne crois pas que je > reviendrai à Cocoon, Et ce serait quoi ? Encore un secret, ou un projet public ? -- Frédéric Glorieux --------------------------------------------------------------------- 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
Sébastien Geindre wrote: > bjr à tous, > > Je ne souhaite en aucun cas lancer un troll sur anyware et > coocon...Sylvain et Anyware ont apporté tellement à la communauté > cocoon qu'il serait stupide de jeter la pierre à quiconque. > > Par contre, j'aimerais bien connaître les raisons qui ont poussé > Anyware a délaissé Cocoon et à investir dans d'autres framework web > (Wicket,...) > > D'ou le sujet... Vaste sujet ! Anyware Technologies n'a pas vraiment délaissé Cocoon, mais a évolué d'une mono-culture cocoonesque à la reconnaissance qu'à différents besoins correspondent différents outils, encouragé dans cette voie par l'évolution de la technologie, aussi bien côté browser que côté frameworks. Concrètement, Anyware utilise Cocoon là où son utilisation est justifiée, c'est à dire dans les applications de type CMS et chaînes de publication documentaires, là où on a besoin de pipelines de transformations. Cocoon est encore sans équivalent dans ce domaine (à part Orbeon). Dans le domaine des applications web (gros formulaires, écrans très interactifs avec Ajax) auquel Cocoon s'était "attaqué" et où j'avais personnellement été très actif, Cocoon a pu être précurseur et novateur, mais il a été rapidement dépassé par des nouveaux venus dédiés à ce domaine tels que Wicket ou GWT, mais aussi des approches plus "client-side" comme DWR où la composante serveur est purement applicative. Ces nouveaux arrivants dans les applications web, en poussant la barre du côté "tout en Java/Javascript" là où Cocoon était "un max en XML" ont aussi apporté de l'air frais à une époque ou nombreux étaient ceux qui avaient une saturation des "crochet ouvrant, crochet fermant". La programmation déclarative a ses limites. Au final, le constat a été qu'utiliser Cocoon dans des applications constituées essentiellement de formulaires n'avait pas vraiment de sens, et que les nouveaux frameworks spécialisés dans ce domaine apportaient plus de productivité. Wicket est de ceux-là, et nous l'avons utilisé avec succès et satisfaction pour ce type d'application. En conclusion, il n'y a pas d'outil magique, et il ne faut pas essayer de vouloir tout faire avec Cocoon. Il a par contre ses domaines d'application privilégiés, qui sans hasard correspondent à sa mission initiale : les chaînes de transformations XML, très adaptées pour les applications de type CMS. Anyware a d'ailleurs une grosse activité CMS utilisant le produit maison Ametys bâti sur Cocoon, qui a été mis en opensource [1]. D'un point de vue plus personnel, j'ai aussi évolué en prenant il y a 2 ans d'importantes responsabilités dans le projet Joost [2] où Cocoon n'avait pas vraiment sa place. Ce changement coïncidant avec une saturation du tout XML et des gros framework, revenir à du tout-Java avec des servlets (presque) de base en frontal de grosse logique métier, et utiliser Wicket sur des applications de type back-office a été un renouvellement presque salutaire. Dans l'étape suivante se mon évolution professionnelle (teasing teasing, à suivre sur mon blog dans les prochaines semaines), je vais à nouveau avoir besoin de transformations XML. Mais je ne crois pas que je reviendrai à Cocoon, au moins sous sa forme actuelle. J'ai besoin de quelque chose de plus "léger", plus agile, qu'on puisse utiliser directement depuis Java ou Javascript côté serveur. C'est une tendance qu'on sent depuis longtemps au sein du groupe des développeurs de Cocoon, et il est possible qu'un "mini-Cocoon" apparaisse dans le futur. Au final, la conclusion est que Cocoon est un produit mature et éprouvé, très adapté à certains problèmes, mais pas à tous. Voilà. Merci à ceux qui ont lu jusqu'ici, j'espère que ça clarifie les choses. Sylvain [1] http://www.ametys.org/ [2] http://bluxte.net/blog/2006-11/15-28-34.html -- Sylvain Wallez - http://bluxte.net --------------------------------------------------------------------- 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
bjr à tous, Je ne souhaite en aucun cas lancer un troll sur anyware et coocon...Sylvain et Anyware ont apporté tellement à la communauté cocoon qu'il serait stupide de jeter la pierre à quiconque. Par contre, j'aimerais bien connaître les raisons qui ont poussé Anyware a délaissé Cocoon et à investir dans d'autres framework web (Wicket,...) D'ou le sujet... Bonne journée à tous. --------------------------------------------------------------------- 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
Bonjour,
Je me réponds au cas où cela pourrait servir à d'autres :
> J'utilise Cocoon 2.1.10 et le "nouveau" block d'authentification
> "auth" (non pas le block déprécié "authentication-fw").
> Je voudrais maintenir à jour une liste des utilisateurs identifiés et
> actifs à un temps T. Mon but est simplement de contrôler, lors d'une
> demande d'identification, s'il n'existe pas déjà un utilisateur actif
> correspondant au même identifiant à ce moment là.
>
> Cocoon possède-t-il des outils pour faire cela ?
Apparemment, non, mais on peut s'en sortir en utilisant un "Session
Listener" :
1- Ecrire une classe Java implémentant l'interface
javax.servlet.http.HttpSessionListener
Cette interface propose des méthodes telles que sessionCreated(),
sessionDestroyed, etc. Le moteur de servlet (Tomcat testé uniquement)
appelle ces méthodes à chaque fois qu'il intervient sur une session.
Tout ce qu'il faut pour maintenir à jour une liste des sessions actives.
Il suffit alors d'implémenter une méthode statique retournant la dite liste.
Il est également possible d'implémenter l'interface
HttpSessionAttributeListener pour "écouter" tout
ajout/modification/suppression sur des attributs de session. L'interface
ServletContextListener permet d'être tenu au courant de
l'initialisation de la servlet, ainsi que sa destruction.
2- Déclarer le Listener dans le fichier WEB-INF/web.xml
<listener>
<listener-class>my.SessionListener</listener-class>
</listener>
"Listener" est un élément de premier niveau. Il doit être écrit
entre les éléments "web-app" et "servlet".
Voilà, tout ceci a été beaucoup plus rapide à mettre en place que de
chercher comment s'y prendre :-)
--
Malo
---------------------------------------------------------------------
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
Bonjour, Peut être que le problème que je vais décrire à été traiter mille fois mais je suis désolé j'ai regardé partout j'ai tout essayé mais j'arrive pas à le résoudre. Mon problème: Je dispose de : *1 application nommée A qui tourne sur jetty avec cocoon 2.1. *1 autre application nommée B qui tourne sur un autre jetty avec un autre cocoon 2.1. Je lance A, la vie est belle, je navigue ... et ensuite je ferme A (et eteint le serveur de A). Je lance B, et là je retrouve la page de démarrage de A. C'est ça mon problème. Pour retrouver la page de B quand je lance B, il faut que je vide le cache de mon browser. et je ne veux pas que mes utilisateurs est à faire cette manipulation à chaque fois. J'AI TOUT ESSAYE: *toutes les métas possible au début et à la fin de mes html. *type="noncaching" sur tout les pipelines. quelqu'un aurait-il une solution pour ce problème? Cordialement, Alexandre _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Bonjour,
Est il possible de configurer le mapTransformer pour aller chercher les messages non pas dans
un fichier Xml (attr. Location) mais dans une table de base de donnée ?
Est-ce que quelqu’un l’a fait ? Peut-on avoir des informations sur le sujet ?
<map:transformer name="i18n" src="org.apache.cocoon.transformation.I18nTransformer">
<catalogues default="messages">
<catalogue id="messages" name="messages" location="translations"/>
</catalogues>
Le but : partager les message dans un ‘repository’ partagé en mode cluster pour pouvoir modifier
les valeurs des messages et cela sans avoir à le redispatcher sur chaque nœud du cluster.
Merci,
Stephane
This message contains information that may be privileged or confidential and is the property
of the Capgemini Group. It is intended only for the person to whom it is addressed. If you
are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
Bonjour, J'utilise Cocoon 2.1.10 et le "nouveau" block d'authentification "auth" (non pas le block déprécié "authentication-fw"). Je voudrais maintenir à jour une liste des utilisateurs identifiés et actifs à un temps T. Mon but est simplement de contrôler, lors d'une demande d'identification, s'il n'existe pas déjà un utilisateur actif correspondant au même identifiant à ce moment là. Cocoon possède-t-il des outils pour faire cela ? -- Malo --------------------------------------------------------------------- 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
On Dec 3, 2007 12:03 PM, "DAVIGNON Andre - CETE NP/DIODé/PANDOC" > ...J'ai bien vu la javadoc de cette classe mais je ne vois pas les sources : C'est dans le bloc html: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/proxy/java/org/apache/cocoon/generation/WebServiceProxyGenerator.java?view=markup La modif que nous avons fait est que la méthode getHttpClient() retourne un nouvel object HttpClient pour chaque requête, au lieu de le stocker dans la session. Cela ne semble faire aucune différence de performance dans notre cas. -Bertrand
> Non, pour les requêtes sur Solr nous utilisons le > WebServiceProxyGenerator, légèrement modifié pour éviter la création > de sessions HTTP. J'ai bien vu la javadoc de cette classe mais je ne vois pas les sources : http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/ Où est-il possible de les trouver ? Merci par avance. André Davignon --------------------------------------------------------------------- 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
> Non, pour les requêtes sur Solr nous utilisons le > WebServiceProxyGenerator, légèrement modifié pour éviter la création > de sessions HTTP. Bien vu, merci. André Davignon --------------------------------------------------------------------- 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
On Dec 3, 2007 10:51 AM, "DAVIGNON Andre - CETE NP/DIODé/PANDOC" > ...Avez-vous utilisé SolrForrest (http://wiki.apache.org/solr/SolrForrest), je pense en particulier à > la pagination... Non, pour les requêtes sur Solr nous utilisons le WebServiceProxyGenerator, légèrement modifié pour éviter la création de sessions HTTP. Pour POSTer des documents dans Solr, un générateur simple utilise HttpClient pour faire le POST (avec Content-type=text/xml; charset=UTF-8) d'une source Cocoon quelconque, et retourne la réponse de Solr. La pagination est gérée directement avec les paramètres de requête de Solr. -Bertrand
Bonjour, > http://www.sortir.ch/ est basé sur Cocoon et utilise Solr pour gérer > l'index des événements culturels. Merci pour cette information. > Comme l'interface Solr est basée entièrement sur HTTP/XML, > l'intégration a été relativement facile. Avez-vous utilisé SolrForrest (http://wiki.apache.org/solr/SolrForrest), je pense en particulier à la pagination ? André Davignon --------------------------------------------------------------------- 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
Bonjour, On Dec 1, 2007 3:44 PM, André Davignon <andre.davignon@free.fr> wrote: > ...existe-t-il des personnes ayant mis au point des > applications Cocoon/Solr ?... http://www.sortir.ch/ est basé sur Cocoon et utilise Solr pour gérer l'index des événements culturels. Cela fonctionne très bien, Solr est installé à partir d'un war installé dans la même instance de Jetty que Cocoon. Comme l'interface Solr est basée entièrement sur HTTP/XML, l'intégration a été relativement facile. -Bertrand
> je pense qu'elle est là http://cocoon.apache.org/fr/index.html Merci. --------------------------------------------------------------------- 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
Bonjour, Dans la liste francophone des utilisateurs et développeurs d'applications Cocoon, existe-t-il des personnes ayant mis au point des applications Cocoon/Solr ? Tout retour d'expérience est bienvenu. André Davignon --------------------------------------------------------------------- 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
je pense qu'elle est là http://cocoon.apache.org/fr/index.html Le 01/12/07, Frédéric Glorieux <fred@fictif.org> a écrit : > > Bonjour, > > Connaissant Cocoon depuis quelques années maintenant, je reviens à cette > liste, et je me suis aperçu que la Zone fr, annoncée sur cette page > <http://cocoon.apache.org/2.1/1175.html> est devenue un lien mort > <http://cocoon.apache.org/fr/welcome>. L'espace est parti ailleurs ? > > > -- > Frédéric Glorieux > > --------------------------------------------------------------------- > 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 > >
Bonjour, Connaissant Cocoon depuis quelques années maintenant, je reviens à cette liste, et je me suis aperçu que la Zone fr, annoncée sur cette page <http://cocoon.apache.org/2.1/1175.html> est devenue un lien mort <http://cocoon.apache.org/fr/welcome>. L'espace est parti ailleurs ? -- Frédéric Glorieux --------------------------------------------------------------------- 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
Bonjour,
Dans une sitemap j'ai ça:
...
<map:match pattern="*/*.xhtml">
<map:when test="editer">
<map:call function="notixForm">
<!-- URL qui génère la définition du formulaire -->
<map:parameter name="form" value="cocoon://{../1}/cforms/form.xml"/>
<!-- URL qui génère les liens au formulaire -->
<map:parameter name="binding" value="cocoon://{../1}/cforms/binding.xml"/>
</map:call>
</map:when>
</map:match>
...
Dans notix.js, on trouve la fonction notixForm() qui contient :
var form = new Form(cocoon.parameters.form);
Tout ceci fonctionnait bien en 2.1.8 mais en 2.1.10, j'ai une "java.lang.NoSuchFieldError:
instance" exception sur cette ligne.Ci-dessous, un bout de la stacktrace.
Je ne vois pas de trace modification dans le block forms sur le sujet mais je me trompe peut-être.
En y en a-t-il eu ?
André Davignon
java.lang.NoSuchFieldError: instance
at org.apache.cocoon.forms.flow.javascript.ScriptableWidget.unwrap(ScriptableWidget.java:56)
at org.apache.cocoon.forms.flow.javascript.ScriptableWidget.<init>(ScriptableWidget.java:52)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:438)
at org.mozilla.javascript.FunctionObject.construct(FunctionObject.java:477)
at org.mozilla.javascript.ScriptRuntime.newObject(ScriptRuntime.java:1318)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1201)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190)
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138)
at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:758)
at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:138
---------------------------------------------------------------------
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
Helo, Haaaaa les encodings .... Pour les histoires d'encoding tout est question de cohérence entre les déclarations (dans l'entête HTML, fichier de conf etc etc) et l'encoding utilisé par ton éditeur de fichier ... C'est bien beau de dire UTF-8, mais si ton éditeur sauve les fichiers en ISO-88XX on obtient le résultat que tu décris. Dans éclipse, tu peux définir une fois pour toutes les encodings en fonction des type de fichier, c une bonne pratique de fixer ce paramètre dans les propriétés du projet (comme cela, cela ne dépend pas de la conf d'eclipse). J'espère avoir été clair. a++; On 10/16/07, "DAVIGNON Andre - CETE NP/DIODé/PANDOC" < Andre.Davignon@equipement.gouv.fr> wrote: > > Bonjour, > > Dans une appli en UTF-8,jJ'ai un formulaire avec un widget répétable de > type upload. Lorsque je sélectionne un fichier les caractères accentués sont > altérés, par exmple le "é" devient "Â(c)". Cela ne se produit pas avec les > autres champs de saisie du formulaire. > > Dans web.xml, j'ai essayé ceci : > > <init-param> > <param-name>container-encoding</param-name> > <param-value>utf-8</param-value> > </init-param> > > et ça résoud le problème pour le champ de type upload mais entraîne un > problème d'encodage pour les autres champs :-( > > Existe-t-il une manipulation particulière qui pourrait m'aider ? > > André Davignon > > > --------------------------------------------------------------------- > 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 > > -- "Ability is nothing without opportunity." Napoleon Bonaparte
Bonjour, Dans une appli en UTF-8,jJ'ai un formulaire avec un widget répétable de type upload. Lorsque je sélectionne un fichier les caractères accentués sont altérés, par exmple le "é" devient "©". Cela ne se produit pas avec les autres champs de saisie du formulaire. Dans web.xml, j'ai essayé ceci : <init-param> <param-name>container-encoding</param-name> <param-value>utf-8</param-value> </init-param> et ça résoud le problème pour le champ de type upload mais entraîne un problème d'encodage pour les autres champs :-( Existe-t-il une manipulation particulière qui pourrait m'aider ? André Davignon --------------------------------------------------------------------- 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
Jean-Baptiste Quenot a écrit : > Pourquoi ne pas écrire un Transformer? > http://cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/org/apache/cocoon/transformation/Transformer.html > et oui pourquoi pas ? à ce propos, entre un transformer dédié et une feuille de style + appel à une fonction java (qui utilise une librairie), quel est le bon choix ? quels sont les implications coté perf ? cache ? mémoire utilisée ?....? à + -- Sébastien Geindre DPREVI/AERO/DEV sebastien.geindre __at__ meteo.fr --------------------------------------------------------------------- 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
Pourquoi ne pas écrire un Transformer?
http://cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/org/apache/cocoon/transformation/Transformer.html
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
---------------------------------------------------------------------
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
Content-type: multipart/alternative;
Boundary="1__=4EBBF9FCDFD3AE7A8f9e8a93df938690918c4EBBF9FCDFD3AE7A"
--1__=4EBBF9FCDFD3AE7A8f9e8a93df938690918c4EBBF9FCDFD3AE7A
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
Bonjour,
J'utilise cocoon et j'ai toujours le m=EAme soucis au niveau des logs d=
e
tomcat (catalina.out). Il est indiqu=E9 que tomcat ne peut trouver le f=
ichier
SysConfig.tbl ou le chemin vers la db.
A quel endroit puis-je ajouter ou modifier le propri=E9t=E9 xindice.db.=
home
pour ne plus avoir ces probl=E8mes ?
Merci pour votre aide
|--------------+---------------------------------+---------------------=
-------------|
| | S=E9bastien BARATHIEU | sebastien.barath=
ieu@urssaf.fr |
| | EDI CFE | =
|
| | Etudes | Groupe CFE : 04 91 =
74.96.12 |
| | CIPAM Marseille | Personnel : 04.91.74=
.97.11 |
| | | Fax : 04.91.74.97.12=
|
|--------------+---------------------------------+---------------------=
-------------|
=
PQ=FC Afin de contribuer au respect de l'environnement, merci de n'imp=
rimer ce
courrier qu'en cas de n=E9cessit=E9 et d'avoir le r=E9flexe recto-vers=
o.
=
=
--1__=4EBBF9FCDFD3AE7A8f9e8a93df938690918c4EBBF9FCDFD3AE7A
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>Bonjour,<br>
<br>
J'utilise cocoon et j'ai toujours le m=EAme soucis au niveau des logs d=
e tomcat (catalina.out). Il est indiqu=E9 que tomcat ne peut trouver le=
fichier SysConfig.tbl ou le chemin vers la db.<br>
A quel endroit puis-je ajouter ou modifier le propri=E9t=E9 xindice.db.=
home pour ne plus avoir ces probl=E8mes ?<br>
<br>
Merci pour votre aide<br>
<br>
<table border=3D"1">
<tr valign=3D"top"><td width=3D"116" bgcolor=3D"#FFFFFF" valign=3D"midd=
le"><div align=3D"center"><img src=3D"cid:10__=3D4EBBF9FCDFD3AE7A8f9e8a=
93df9386@urssaf.fr" width=3D"100" height=3D"60" alt=3D""></div></td><td=
width=3D"264" bgcolor=3D"#FFFFFF" valign=3D"middle"><b><font size=3D"4=
" face=3D"Arial">S=E9bastien BARATHIEU</font></b><font size=3D"4"> </fo=
nt><font size=3D"2" color=3D"#0000FF" face=3D"Arial"><br>
EDI CFE</font><font size=3D"4" face=3D"Arial"> </font><font size=3D"2"
=
face=3D"Arial"><br>
Etudes<br>
CIPAM Marseille</font></td><td width=3D"270" bgcolor=3D"#FFFFFF" valign=
=3D"middle"><img src=3D"cid:20__=3D4EBBF9FCDFD3AE7A8f9e8a93df9386@urssa=
f.fr" width=3D"16" height=3D"16" alt=3D""><font size=3D"2" face=3D"Aria=
l"> sebastien.barathieu@urssaf.fr<br>
</font><img src=3D"cid:30__=3D4EBBF9FCDFD3AE7A8f9e8a93df9386@urssaf.fr"=
width=3D"16" height=3D"16" alt=3D""><font size=3D"2" face=3D"Arial"><b=
r>
Groupe CFE : 04 91 74.</font><b><font size=3D"2" face=3D"Arial">96.12<=
/font></b><font size=3D"2" face=3D"Arial"><br>
Personnel : 04.91.74.</font><b><font size=3D"2" face=3D"Arial">97.11</f=
ont></b><font size=3D"2" face=3D"Arial"> <br>
Fax : 04.91.74.</font><b><font size=3D"2" face=3D"Arial">97.12 </font><=
/b></td></tr>
</table>
<p>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tr valign=3D"top"><td width=3D"662" bgcolor=3D"#FFFFFF" valign=3D"midd=
le"><font size=3D"5" color=3D"#009900" face=3D"Webdings">PQ=FC</font><f=
ont size=3D"4"> </font><font size=3D"2" color=3D"#009900" face=3D"Arial=
">Afin de contribuer au respect de l'environnement, merci de n'imprimer=
ce courrier qu'en cas de n=E9cessit=E9 et d'avoir le r=E9flexe recto-v=
erso.</font><font size=3D"4"> </font></td></tr>
</table>
<br>
</body></html>=
--1__=4EBBF9FCDFD3AE7A8f9e8a93df938690918c4EBBF9FCDFD3AE7A--
Merci olivier pour ta réponse. flowscript....ou javaflow ? => streamGenerator => xml data request => flowScript : comment lui passer le noeud qui va bien, incluant les données dont il a besoin ? => ds le flowscript, appel java, utilisation librairie java JTS, intersection spatial,... comment ? un example ? => retour de flowscript : cocoon.sendPage() : y a moyen de lui passer en paramètre le résultat de l'intersection, mais comment faire en sorte qu'il ait tout le flux d'origine (xml data request) afin de continuer le traitement du flux. merci. olivier nouguier a écrit : > On 10/8/07, Sébastien Geindre <sebastien.geindre@meteo.fr> wrote: > >> Bjr à tous, >> >> La boite outil cocoon est suffisamment vaste pour que l'on s'y perde >> dans certains cas non nominal... >> >> Et comme il n'y a pas de question stupides, je me lance... >> >> Je récupère un flux xml de données (streamGenerator) >> Je dois ensuite faire des traitements différents en fonction de certains >> paramètres issus de mon flux xml en entrée. Il me faut donc appeler une >> fonction java en lui passant en paramètres un bout du flux xml d'entrée >> et des variables locales. >> >> D'où les question de design propre à cocoon: >> >> 1/ implémentable au niveau de la sitemap (action, ... ???) ?? >> > > > Non les actions sont 'actionnées" à la création du pipeline et non durant > son exécution. > > - récupérer des données spatiales (gml:polygon) d'un partie de ce flux, > > > ==> flux == sax ==> transformer (IMHO) > > - faire une opération java (intersection zone avec JTS) > >> - aiguiller le pipeline en fonction du résultat, avec le flux XML recu >> en entrée. >> >> 2/ faire le test dans une XSL ?? >> - mais bof la SoC.. >> >> 3/ ?? >> > > > flowScript ??? > > > -- > >> Sébastien Geindre >> DPREVI/AERO/DEV >> sebastien.geindre __at__ meteo.fr >> >> >> >> >> --------------------------------------------------------------------- >> 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 >> >> >> > > > -- Sébastien Geindre DPREVI/AERO/DEV sebastien.geindre __at__ meteo.fr --------------------------------------------------------------------- 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
On 10/8/07, Sébastien Geindre <sebastien.geindre@meteo.fr> wrote: > > Bjr à tous, > > La boite outil cocoon est suffisamment vaste pour que l'on s'y perde > dans certains cas non nominal... > > Et comme il n'y a pas de question stupides, je me lance... > > Je récupère un flux xml de données (streamGenerator) > Je dois ensuite faire des traitements différents en fonction de certains > paramètres issus de mon flux xml en entrée. Il me faut donc appeler une > fonction java en lui passant en paramètres un bout du flux xml d'entrée > et des variables locales. > > D'où les question de design propre à cocoon: > > 1/ implémentable au niveau de la sitemap (action, ... ???) ?? Non les actions sont 'actionnées" à la création du pipeline et non durant son exécution. - récupérer des données spatiales (gml:polygon) d'un partie de ce flux, ==> flux == sax ==> transformer (IMHO) - faire une opération java (intersection zone avec JTS) > - aiguiller le pipeline en fonction du résultat, avec le flux XML recu > en entrée. > > 2/ faire le test dans une XSL ?? > - mais bof la SoC.. > > 3/ ?? flowScript ??? -- > Sébastien Geindre > DPREVI/AERO/DEV > sebastien.geindre __at__ meteo.fr > > > > > --------------------------------------------------------------------- > 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 > > -- "Ability is nothing without opportunity." Napoleon Bonaparte
Bjr à tous, La boite outil cocoon est suffisamment vaste pour que l'on s'y perde dans certains cas non nominal... Et comme il n'y a pas de question stupides, je me lance... Je récupère un flux xml de données (streamGenerator) Je dois ensuite faire des traitements différents en fonction de certains paramètres issus de mon flux xml en entrée. Il me faut donc appeler une fonction java en lui passant en paramètres un bout du flux xml d'entrée et des variables locales. D'où les question de design propre à cocoon: 1/ implémentable au niveau de la sitemap (action, ... ???) ?? - récupérer des données spatiales (gml:polygon) d'un partie de ce flux, - faire une opération java (intersection zone avec JTS) - aiguiller le pipeline en fonction du résultat, avec le flux XML recu en entrée. 2/ faire le test dans une XSL ?? - mais bof la SoC.. 3/ ?? -- Sébastien Geindre DPREVI/AERO/DEV sebastien.geindre __at__ meteo.fr --------------------------------------------------------------------- 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
Hi,
I'm using spring to manage the transactions in my cocoon transformers
and generators.
Here is the problem: with the generators, everything is ok (my Hibernate
beans are stored in the database) but when I use Transformers, it looks
like there is no "commit" done --> no exception and the persist on the
beans are done!
Here are my files:
application-context:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:configurator="http://cocoon.apache.org/schema/configurator"
xmlns:avalon="http://cocoon.apache.org/schema/avalon"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.0.xsd
http://cocoon.apache.org/schema/configurator
http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.xsd
http://cocoon.apache.org/schema/avalon
http://cocoon.apache.org/schema/avalon/cocoon-avalon-1.0.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">
<bean id="maTransactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory">
<ref bean="sessionFactory" />
</property>
</bean>
<bean
name="org.apache.cocoon.transformation.Transformer/importTestTransformer"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref bean="maTransactionManager" />
</property>
<property name="target">
<bean id="importTestGeneratorWithoutTransaction"
class="com.mycompany.transform.ImportTestGenerator">
<property name="colorHelper">
<ref bean="ColorHelper" />
</property>
<property name="sessionFactory">
<ref bean="sessionFactory" />
</property>
</bean>
</property>
<property name="transactionAttributes">
<props>
<prop key="write*">
PROPAGATION_REQUIRED
</prop>
</props>
</property>
</bean>
</beans>
sitemap:xmap:
<?xml version="1.0" encoding="UTF-8"?>
<map:sitemap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://apache.org/cocoon/sitemap/1.0
http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd"
xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:flow language="javascript"/>
<map:components>
<map:generators default="file">
<map:generator name="file"
src="org.apache.cocoon.generation.FileGenerator"/>
<map:generator name="stream"
src="org.apache.cocoon.generation.StreamGenerator"/>
</map:generators>
</map:components>
<map:pipelines>
<map:pipeline> <!-- Used for test only -->
<map:match pattern="importTestGenerator">
<map:generate type="stream">
<map:parameter name="defaultContentType"
value="text/xml"/>
</map:generate>
<map:transform type="importTestGenerator"/>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
</map:pipelines>
---------------------------------------------------------------------
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
Bonjour, j'ai problème avec l'utilisation de BetwixtTransformer et cocoon. A partir d'un fichier xml, je veux créer des javabeans. Pour ce faire, j'ai besoin de deux fichiers ".betwixt" afin de correctement mapper le xml avec mes javabeans. Mon problème est le suivant: Lors de tests JUnit, tout se passe à merveilles et les éléments de l'xml mappés grace aux fichiers ".betwixt" sont correctement parsés et instanciés. Par contre, lorsque je passe par cocoon, Ces éléments ne sont pas parsés (aucune instance de ces javabeans n'est trouvée dans le fichier xml). Faut-il préciser à cocoon où aller chercher ces fichiers ".betwixt"? Faut'il préciser dans le rcl.properties l'inclusion de ces fichiers (j'utilise maven)? merci de vos réponses, tugdual --------------------------------------------------------------------- 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