cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: Cocoon, XForms, ExFormula, Chiba, Struts, etc
Date Fri, 15 Feb 2002 17:18:26 GMT
>
> 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: kpiroumian@flagship.ru
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:peter@softline.kiev.ua]
> Sent: Friday, February 15, 2002 6:38 AM
> To: cocoon-dev@xml.apache.org
> 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:tcurdt@dff.st]
> Sent: Friday, February 15, 2002 1:49 PM
> To: cocoon-dev@xml.apache.org
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


Mime
View raw message