MySQL date conversion with modular database action
Any pointers on how to convert a date before it's inserted into MySQL database while using cocoon's Modular Database Action? I tried value name="start_date"type="date" mode name="attribute" parameter="org.apache.cocoon.components.modules.input.DateMetaInputModule:start_date[0]" type="attrib"//value It seems this "mode" parameter is being ignored. Any suggestions? Thank you!
Re: extending XMLForms for different kinds of models...opinions?
On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote: Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. snip/ Would it not be best to discuss this on Cocoon-Dev? Very nice idea, BTW! regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[plug] German book on Apache Frameworks (inl. Cocoon)
A new German book was released yesterday that focusses on the different
Apache frameworks such as Cocoon, Turbine, Velocity etc. The chapter on
Cocoon contains a detailed description of the portal and authentication
frameworks as they are in Cocoon 2.1-dev.
More information here:
http://radio.weblogs.com/0103021/2003/02/15.html#a738
Enjoy.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
http://radio.weblogs.com/0103021/
http://www.oreillynet.com/weblogs/author/1014
=
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForm Wizard alternative?
Kudos Robert. Several people have asked about this. Please publish the link on the wiki site. -=Ivelin=- - Original Message - From: Robert Sösemann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 14, 2003 9:12 AM Subject: Re: XMLForm Wizard alternative? That would be great. Could you send the file to this adress [EMAIL PROTECTED] Thanks a lot, Robert - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 14, 2003 1:47 PM Subject: Re: XMLForm Wizard alternative? Hi there I do not know if anyone else has done it - but I was so impressed with xmlform that I took the 2.1 code and hacked it a bit to compile and run on cocoon 2.0.4 - it's working for me - and I can create a source jar file and such for creating a cocoon-xmlform-2.0.4.jar file to put into WEB-INF/lib for cocoon-2.0.4 users that would like to play around with xmlform. If it has your interest send me a mail. Regards Jakob Jakob Dalsgaard Udvikler e-mail: [EMAIL PROTECTED] Vesterbrogade 149 1620 København V Tlf.: 70 25 80 30 Fax.: 70 25 80 31 Konstantin Piroumian [EMAIL PROTECTED] 12/18/02 01:39 PM Please respond to cocoon-users To: [EMAIL PROTECTED] cc: Subject:Re: XMLForm Wizard alternative? From: Robert Sösemann [EMAIL PROTECTED] Hy, in our project (CMS) we want to easily generate input fields in a wizard-like interface. It is later used by authors to put different types of articles into a database. As different types of articles have other information needs, we want to provide the user with form field that represent that needs of the specific article. So we need a mechanism to generate steps of our wizard (namely page with form fields) from centralized information (great would be the db) As this XMLWizard mechanism is only available from a cocoon beta, we are not allowed to use it. Can you imagine an alternative way to solve this? You can simply use the XMLForm's syntax for form representation and use a custom action to generate the next step for you. To customize the forms you can either use XSP or a special transformer. Konstantin Thanks in advance, Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extending XMLForms for different kinds of models...opinions?
This sounds good. As you suggest the java: prefix can be used for instantiating JavaBeans. For all other cases though, I was hoping to reuse the standard SourceResolver. This will immediately allow support for a lot of different sources. Here is a snippet from the Sitemap document. http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (I wish there was one discussing just SourceResolvers.) a.. Use http://foo/bar to merge in xml content via http protocol, received from machine foo. a.. Use context://servlet-context-path/foo/bar to merge in xml content from the servlet context. a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content from the current sitemap. The appropriate pipeline is selected matching current-sitemap-pipeline. a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from the root sitemap. The appropriate pipeline is selected matching root-sitemap-pipeline. a.. Use resource://class-path-context/foo/bar to merge in xml content from the classpath. a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml content coming from a jar via http connection. a.. Use file:///foo/bar to merge in xml content from the filesystem. a.. Use xmldb:your driver here://your.xmldb.host/db/foo/bar to merge in xml content from a XML:DB compliant database. a.. Depending on your setup you may use nfs:, jndi: protocols, too. -=Ivelin=- - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Friday, February 14, 2003 7:07 AM Subject: extending XMLForms for different kinds of models...opinions? Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. Some days ago, and with some ideas I exchanged with Ivelin, I made a how-to that should help users on using XMLForm with Xindice for storing XML models. It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice) and made its way into the CVS a few days ago. In this how-to I explored new ways of storing the form model. This new way the XML model is stored in a file in the system with an empty structure. Then it is loaded into a JXPath Container and manipulated from there. The getFormModel() is overriden so you don't need a Bean, but just the file. Ivelin thought this could be a great addition to the framework, so we were discussing how to make this available for the end user. We exchanged some ideas and they led us to incorporating some mechanism to the sitemap. We were thinking about a prefix. This way, passing the model parameter to the form would be like this: map:parameter name=xmlform-model value=java:MyBean/ The 'java:' prefix would be used for java models. If you would like to use the pure XML model approach you could do something like: map:parameter name=xmlform-model value=xml:MyDocument/ Of course, one of the approaches could be made the default one so this could make life easier for most used models declaring them implicit: map:parameter name=xmlform-model value=MyModel/ I hope I explained it clearly. Now I need your feedback. I'd like to know if this make sense to you and if so, we should decide which of the two approaches should be the implicit one, so the AbstractXMLFormAction would be modified accordingly. Maybe some of you would prefer to see it implemented but having the java models as the implicit ones, so you won't need to change your working xmlforms in order to use it in the future 2.1. If you feel that way, please say so. Best, Josema. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extending XMLForms for different kinds of models...opinions?
Jeremy, I posted here cause I wanted to know if the users would like that feature to be added. I thought the dev list would be more suitable in case of discussing the way of implementing it. Since I'm not currently subscribed to the dev list, feel free to cc the message there if you want to. Btw, glad you like it. Thanks. - Original Message - From: Jeremy Quinn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 11:24 AM Subject: Re: extending XMLForms for different kinds of models...opinions? On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote: Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. snip/ Would it not be best to discuss this on Cocoon-Dev? Very nice idea, BTW! regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extending XMLForms for different kinds of models...opinions?
Ivelin, That sounds very very good. I was not sure about all the possibilities when using the SourceResolver. If all of that can be accomplished using the SourceResolver, it's more powerful than I expected and we should take the java: as the only way for Javabeans. But... Since I started with Cocoon, one of the features I don't like is this kind of abruptly changes. If we go for the prefix way, forms currently working should be coded again (at least their sitemap snippets). I think the best solution would be: - Go with the java: prefix for beans - Any other prefix - solved by the SourceResolver - Implicitly assume java, so no prefix means model bean (only by now) At a later stage (maybe for 2.1beta), we could change it so the java models should be called only explicitly and all of the other resources would be solved by the SourceResolver. This way, the transition would be easier to accomplish for users with working xmlforms. Ivelin, I think we talked about something like this? Hope all of you like this approach. I'd like to go ahead and try to patch the AbstractXMLFormAction. Best. - Original Message - From: ivelin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 5:53 PM Subject: Re: extending XMLForms for different kinds of models...opinions? This sounds good. As you suggest the java: prefix can be used for instantiating JavaBeans. For all other cases though, I was hoping to reuse the standard SourceResolver. This will immediately allow support for a lot of different sources. Here is a snippet from the Sitemap document. http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (I wish there was one discussing just SourceResolvers.) a.. Use http://foo/bar to merge in xml content via http protocol, received from machine foo. a.. Use context://servlet-context-path/foo/bar to merge in xml content from the servlet context. a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content from the current sitemap. The appropriate pipeline is selected matching current-sitemap-pipeline. a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from the root sitemap. The appropriate pipeline is selected matching root-sitemap-pipeline. a.. Use resource://class-path-context/foo/bar to merge in xml content from the classpath. a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml content coming from a jar via http connection. a.. Use file:///foo/bar to merge in xml content from the filesystem. a.. Use xmldb:your driver here://your.xmldb.host/db/foo/bar to merge in xml content from a XML:DB compliant database. a.. Depending on your setup you may use nfs:, jndi: protocols, too. -=Ivelin=- - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Friday, February 14, 2003 7:07 AM Subject: extending XMLForms for different kinds of models...opinions? Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. Some days ago, and with some ideas I exchanged with Ivelin, I made a how-to that should help users on using XMLForm with Xindice for storing XML models. It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice) and made its way into the CVS a few days ago. In this how-to I explored new ways of storing the form model. This new way the XML model is stored in a file in the system with an empty structure. Then it is loaded into a JXPath Container and manipulated from there. The getFormModel() is overriden so you don't need a Bean, but just the file. Ivelin thought this could be a great addition to the framework, so we were discussing how to make this available for the end user. We exchanged some ideas and they led us to incorporating some mechanism to the sitemap. We were thinking about a prefix. This way, passing the model parameter to the form would be like this: map:parameter name=xmlform-model value=java:MyBean/ The 'java:' prefix would be used for java models. If you would like to use the pure XML model approach you could do something like: map:parameter name=xmlform-model value=xml:MyDocument/ Of course, one of the approaches could be made the default one so this could make life easier for most used models declaring them implicit: map:parameter name=xmlform-model value=MyModel/ I hope I explained it clearly. Now I need your feedback. I'd like to know if this make sense to you and if so, we should decide which of the two approaches should be the implicit one, so the AbstractXMLFormAction would be modified accordingly. Maybe some of you would prefer to see it implemented but having the java models as the implicit ones, so you won't need to
RE: extending XMLForms for different kinds of models...opinions?
Title: RE: extending XMLForms for different kinds of models...opinions? As a user of cocoon, I see this as a very advantageous feature. I am currently using cocoon/xmlform and have been developing with it for about five months now. Your suggestion matches some of the thoughts I was having at the start of my project while I was becoming accustomed to using the framework. I have taken advantage of the javabean architecture in the sense that I can dynamically grab data from different data sources, but I agree in the simple cases an xml model would be well-suited. Another suggestion I would have is to allow for multiple models. The W3C spec for xforms has been designed around multiple models; if a second revision of xmlforms is in the works, I would suggest investigating this feature. Jon -Original Message- From: Josema Alonso To: Cocoon-Users Sent: 2/15/03 11:39 AM Subject: Re: extending XMLForms for different kinds of models...opinions? Jeremy, I posted here cause I wanted to know if the users would like that feature to be added. I thought the dev list would be more suitable in case of discussing the way of implementing it. Since I'm not currently subscribed to the dev list, feel free to cc the message there if you want to. Btw, glad you like it. Thanks. - Original Message - From: Jeremy Quinn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 11:24 AM Subject: Re: extending XMLForms for different kinds of models...opinions? On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote: Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. snip/ Would it not be best to discuss this on Cocoon-Dev? Very nice idea, BTW! regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sendmail.xsl logicsheet with attachments
Sometime back, there has been some discussion about sending attachments with the sendmail.xsl logicsheet on this list. Since I now also wanted this features, I've fiddled with sendmail.xsl and extended it with a sendmail:attachment [delete=yes] tags. Please see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15005 for details. The attached patch with bugzilla id 4879 is the right one. Since I was at, I also created some documentation, which could be integrated with the other documentation of XSP logicsheets. Please see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17090 for details. -- MfG/Regards Frank Ridderbusch Since I have taken all the Gates out of my computer, it finally works!! - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extending XMLForms for different kinds of models...opinions?
Title: RE: extending XMLForms for different kinds of models...opinions? Jonathan, please elaborate on the multiple models requirement. I think that Josema's idea is a significant step forward. It does not prohibit future extensions, so I definitely support it, but in the meanwhile I am interested to hear what else can we do in the future. -=Ivelin=- - Original Message - From: Jonathan Spaeth To: 'Josema Alonso ' ; 'Cocoon-Users ' Sent: Saturday, February 15, 2003 1:00 PM Subject: RE: extending XMLForms for different kinds of models...opinions? As a user of cocoon, I see this as a very advantageous feature. I am currently using cocoon/xmlform and have been developing with it for about five months now. Your suggestion matches some of the thoughts I was having at the start of my project while I was becoming accustomed to using the framework. I have taken advantage of the javabean architecture in the sense that I can dynamically grab data from different data sources, but I agree in the simple cases an xml model would be well-suited. Another suggestion I would have is to allow for multiple models. The W3C spec for xforms has been designed around multiple models; if a second revision of xmlforms is in the works, I would suggest investigating this feature. Jon -Original Message- From: Josema Alonso To: Cocoon-Users Sent: 2/15/03 11:39 AM Subject: Re: extending XMLForms for different kinds of models...opinions? Jeremy, I posted here cause I wanted to know if the users would like that feature to be added. I thought the dev list would be more suitable in case of discussing the way of implementing it. Since I'm not currently subscribed to the dev list, feel free to cc the message there if you want to. Btw, glad you like it. Thanks. - Original Message - From: "Jeremy Quinn" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 11:24 AM Subject: Re: extending XMLForms for different kinds of models...opinions? On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote: Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. snip/ Would it not be best to discuss this on Cocoon-Dev? Very nice idea, BTW! regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extending XMLForms for different kinds of models...opinions?
Ditto. -=Ivelin=- - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 11:41 AM Subject: Re: extending XMLForms for different kinds of models...opinions? Ivelin, That sounds very very good. I was not sure about all the possibilities when using the SourceResolver. If all of that can be accomplished using the SourceResolver, it's more powerful than I expected and we should take the java: as the only way for Javabeans. But... Since I started with Cocoon, one of the features I don't like is this kind of abruptly changes. If we go for the prefix way, forms currently working should be coded again (at least their sitemap snippets). I think the best solution would be: - Go with the java: prefix for beans - Any other prefix - solved by the SourceResolver - Implicitly assume java, so no prefix means model bean (only by now) At a later stage (maybe for 2.1beta), we could change it so the java models should be called only explicitly and all of the other resources would be solved by the SourceResolver. This way, the transition would be easier to accomplish for users with working xmlforms. Ivelin, I think we talked about something like this? Hope all of you like this approach. I'd like to go ahead and try to patch the AbstractXMLFormAction. Best. - Original Message - From: ivelin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 5:53 PM Subject: Re: extending XMLForms for different kinds of models...opinions? This sounds good. As you suggest the java: prefix can be used for instantiating JavaBeans. For all other cases though, I was hoping to reuse the standard SourceResolver. This will immediately allow support for a lot of different sources. Here is a snippet from the Sitemap document. http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html (I wish there was one discussing just SourceResolvers.) a.. Use http://foo/bar to merge in xml content via http protocol, received from machine foo. a.. Use context://servlet-context-path/foo/bar to merge in xml content from the servlet context. a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content from the current sitemap. The appropriate pipeline is selected matching current-sitemap-pipeline. a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from the root sitemap. The appropriate pipeline is selected matching root-sitemap-pipeline. a.. Use resource://class-path-context/foo/bar to merge in xml content from the classpath. a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml content coming from a jar via http connection. a.. Use file:///foo/bar to merge in xml content from the filesystem. a.. Use xmldb:your driver here://your.xmldb.host/db/foo/bar to merge in xml content from a XML:DB compliant database. a.. Depending on your setup you may use nfs:, jndi: protocols, too. -=Ivelin=- - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Friday, February 14, 2003 7:07 AM Subject: extending XMLForms for different kinds of models...opinions? Dear all, I need your suggestions and opinions in extending the current XMLForm model approach. If you use XMLForm or are thinking about using it soon, I'd suggest youy to read this message and send some feedback to the list. Some days ago, and with some ideas I exchanged with Ivelin, I made a how-to that should help users on using XMLForm with Xindice for storing XML models. It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice) and made its way into the CVS a few days ago. In this how-to I explored new ways of storing the form model. This new way the XML model is stored in a file in the system with an empty structure. Then it is loaded into a JXPath Container and manipulated from there. The getFormModel() is overriden so you don't need a Bean, but just the file. Ivelin thought this could be a great addition to the framework, so we were discussing how to make this available for the end user. We exchanged some ideas and they led us to incorporating some mechanism to the sitemap. We were thinking about a prefix. This way, passing the model parameter to the form would be like this: map:parameter name=xmlform-model value=java:MyBean/ The 'java:' prefix would be used for java models. If you would like to use the pure XML model approach you could do something like: map:parameter name=xmlform-model value=xml:MyDocument/ Of course, one of the approaches could be made the default one so this could make life easier for most used models declaring them implicit: map:parameter name=xmlform-model value=MyModel/ I hope I explained it clearly. Now I
Re: extending XMLForms for different kinds of models...opinions?
I also think that the average user is a relative term. All users of Cocoon that I have talked to, have been evaluating it as another J2EE tool, instead of an all XML server. Most often in my experience it has been compared against JSP/Struts. -=Ivelin=- - Original Message - From: Christopher Oliver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 1:49 PM Subject: Re: extending XMLForms for different kinds of models...opinions? Just wondering, why isn't the average cocoon user reluctant to write complex xpath or xslt code as well as Java? Regards, Chris Sylvain Wallez wrote: This is a good idea when you need to use the JavaBean for some business logic. But there are many cases where you just want to populate a database after successful validation, and the average Cocoon user quickly becomes reluctant to writing Java code, even for storing data in a database ;-) Sylvain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
