> > I am happy we've got someone else on the list with Struts background.
Me too ;) Cocoon people has a very little knowledge on Struts. Btw, do you speak Russian? > > Impressive first steps, Konstantin ! Not much - it's mainly a theory. > > 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. Yes, agree. > > >Another thing is that you can't have dynamic forms. > > What do you mean by this? Forms, that change their field set at runtime, maybe depending on business rules. In my case, I am thinking of receiving the form (maybe simplified XForm) description from the EJB layer where business logic is implemented. In this case form JavaBean will look like a hierarchical Map of simple types, Maps and Collections - so it'll be more natural to use XML for that. > > > 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? Never used XSLTC, but I know that XPath expressions can be prepared and reused next time without parsing. This should improve perfomance a little. > 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. That would be fine. > > > 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. But your UI specific beans duplicate your value objects, don't they? > > >> 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. Again, it's possible if we use special JavaBeans for UI. Sometimes it's not possible, e.g. when business value objects are created at the business logic layer and to be populated with default values and maybe some other operations are performed - I should call EJB to get a value object. Of course, this is a specific case, and it can be implemented with a special form specific bean, but I am trying to avoid that by other means. > > >> 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. Yes, agree again. > > >> 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. It's not a complete solution, only my experience with Cocoon 1, where I had implemented something like a form description format with data binding that were processed by a special logicsheet and then an XSL stylesheet where applied to present the form in HTML. Konstantin P.S. Seems that not much people is interested in this, so maybe it'll be better to continue this discussion off list? > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
