> > Thanks for the response fellows. I'm glad this is still considered a > feasible subject. > > Yes, I've looked at XForms and: > 1) It is what I believe we should be shooting for instead of full XForms > support. > Believe me, Struts is extremely useful when you need HTML Forms/Java > binding. > 2) We could use plenty of Struts architecture to add the extra XML layer: > HTML Forms <-> XML/SAX <-> JavaBeans. Excellent tools are already available > for that: Castor (or JAXB), Xerces2 (XML Schema validation) and again Strut' > source base. > 3) I've customized Struts for our project's needs quite a bit and have grown > to understand that it's a very well written tool, which demonstrates lots of > best practices.
I've been using Struts for our project, but after using Cocoon some parts of Struts seemed to me a little limiting. 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. Another thing is that you can't have dynamic forms. <skipped content="Struts Overview" /> > > XPath is obviously a more standard and powerful tool one could use to achive > similar effect. > Two excelent tools are available to do the reflection job for free: > http://jaxen.org/ and http://saxpath.org/ 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. > > So, using a similar descriptor concept to struts-config.xml, one could > describe: > > a) a form name that maps to a Java Bean class 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. > b) using JAXB (or Castor) one can map the JavaBeans class to XML > representation Agree. For not default mapping you should create a special mapping file. > 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. > 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? > > 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. > <input name="xpath1" value="123" onMouseOver="do1()" > onFocus="doSomethingElse"/> > > Without the customization part, translating: > <cocoonform:input name="xpath1" value="123"> > to > <input name="xpath1" value="123"> > using a generic cocoonform2html.xsl seems trivial. I think that we will need several transformations until the user will get his page. 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] >
XData.java
Description: Binary data
XDataInterface.java
Description: Binary data
XDataException.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
