I am happy we've got someone else on the list with Struts background.
Impressive first steps, Konstantin ! see below: >I've been using Struts for our project, but after using Cocoon some parts of Struts seemed to me a little limiting. Glad we're on the same page. As I said, I want but can't reuse existing code for population, validation, action handling with SOAP. >From the other point of view, it's perfect for any JavaBean/JSP project. One problem can be that you have to create special FormBean classes for every form or a group of forms. Yes. An ActionForm is just a JavaBean, and I don't have problems creating custom JavaBeans for some Web pages, where a domain JavaBean is not sufficient. After all that's what JavaBeans are for and that's how they're used in Swing. On the other hand you're right that extending from ActionForm shouldn't be enforced. All that's needed is xml mapping descriptor. >Another thing is that you can't have dynamic forms. What do you mean by this? > I've created a simple class to test the get and set possibilities by Xpath. You'll find it in the attached files (it requires Xalan and Xerces). The main problem were the perfomance - it takes about 20ms to select a value and a couple of hunderd of ms to set a value with node creation. Good point. Isn't this just the first step though. Does it not have a better potential? Without much real life experience, I will ask: - Can XPath based setters and getters be precompiled using apache's XSLTC? For example <c2form:input name="/person/first_name[2]" value="Joe"> could result in xslt code which modifies the original xml form. XSLTC can convert the xslt into quick bytecode. - From my humble XSLT experience I understand that maybe xsl:key() can be efficiently used for static xpath expressions like that which are known at build time. > One-to-one relationship between a form and JavaBean is not enough. Very often, I have to use multiple value objects in my forms. So it will be many-to-many, cause you can have also multiple forms on a page. Appology for repeating myself. An ActionForm is a JavaBean. I feel comfortable with creating UI specific beans as long as I don't need to worry about HTML/Java conversion. >> c) with Jaxen/SaxPath one can acomplish automated population/serialization >> of (name=XpathExpression, value=String) to and from HTML POST <-> JavaBean > But notice, that you should have created that JavaBean objects before populating them with values. True. Struts does it with grace, we could use the same mechanism. >> d) Xerces2 can validate the resulting JavaBean through JAXB SAX parsing >> agains an XML Schema. >What if the user entered data in incorrect format, e.g. incorrect date and >you have a Date field in your bean? Maybe it's better to perform validation >before mapping it to JavaBeans? JAXB/Castor come into play again, because they do the conversion and throw errors which can be trated as validation violation. Performing validation before populating the beans requires the extra text XML layer. I'm hoping that this layer can be skipped through sax events between xpath and JAXB. >> At the end the only hard part would seem to be the xsl sheet which converts >> an XML form into a client specific format, that will allow customization >> like: >This part seems to me the less complicated. It can be a set of standart XSL >stylesheets, that can be used as is or be included/imported to user >stylesheets that can override some templates to add customization. Glad to know you have a solution. I will ask more quesionts in this regard after we resolve the more fundamental ones above. Cheers, Ivelin Best regards, Konstantin Piroumian Leading Software Developer Protek Flagship LLC Phone: + 7 095 795 0520 (add. 1288) Fax: + 7 095 795 0525 E-mail: [EMAIL PROTECTED] http://www.protek.com > > > -- > > Sorry for yet another long message. As Steffano cited Pascal, didn't have > time to make it shorter :) > > > Am I dreaming too much? > > > > -= Ivelin =- > > -----Original Message----- > From: Peter Velichko [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 6:38 AM > To: [EMAIL PROTECTED] > Subject: RE: Cocoon, XForms, ExFormula, Chiba, Struts, etc > > > Did anyone look at http://xform.nanoworks.org? > It is client-side and server-side form validator. > XForm uses Xerces XML Parser and have LGPL license. > > > -----Original Message----- > From: Torsten Curdt [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 1:49 PM > To: [EMAIL PROTECTED] > Subject: Re: Cocoon, XForms, ExFormula, Chiba, Struts, etc > > > > <snip/> > > > > Can we try to unify and finish the job started, so that Cocoon moves to > the > > > next level. > > Would be cool... > > > There isn't anything on the architecture of chiba available so I have > > no idea how closely related chiba to XForms support in Cocoon would > > be. > > I've also tried to find some information about chiba... didn't yet have > the time to install and try it out. > > Although I guess XForm is about to become a RC sooner or later it doesn't > yet go well with the current technologies available. > > Looking into XUL from mozilla could be an interesting alternative... > (although they do not aim completely into the same direction!!) > > http://www.mozilla.org/xpfe/xulref/ > > I haven't had a look into the XForm spec since the exformula stuff. I hope > they fixed some stuff. That days it still felt somehow immature. They spec > didn't say anything how selected options in a multi select optionbox was > supposed to look like in the instance e.g. :-/ > > I am back again a bit sceptic... > > > For Cocoon, I see two different and in part unrelated areas: > > a) populate the form > > b) Given that the client does support XForms, migrate the existing > > actions to be XForms based i.e. make them aware of the changed > > communication protocol. > > c) For clients that do not support XForms > > c1) have XForms output translated to XHTML > > c2) have the returned results transformed to an XML representation > > like an XForms aware client would generate. > > c3) validate the input > > ok > > > I'm currently working on decoupling sitemap components from the input > > layer, making that plugable. I think it could help with b) > > Sounds interesting... could already post some more information. We've > maybe implemented something similar... > > > I think c2) would be easy. I'm not quite sure if suitable components > > exist already. I believe I came across some that looked quite > > promising but didn't investigate it any further. > > > > For c3 it looked like that could be done by e.g. Xerces like you said > > above. > > > > Probably c1 is the most complicated part. > > As I remember c1) isn't yet possible with the current XSLT > spec/implementation. It's only possible with extension functions :-(ugly) > -- > Torsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
