Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <85BCB1287CF1D41197570090279A6A0D03952D5E@ES02-AUS.bmc.com>
From: "Ivanov, Ivelin" <Ivelin_Ivanov@bmc.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: Cocoon, XForms, ExFormula, Chiba, Struts, etc
Date: Fri, 15 Feb 2002 13:05:50 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


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: 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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org