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.
To address Chris' well put concise requirements:
c1) Shouldn't be as hard if we reuse Struts knowledge.
- In struts-config.xml you describe a list of ActionForm names along with
their corresponding Java classes, e.g.
<form-bean name = "subscribe" type =
"com.xyz.ui.model.subscribe.SubscribeForm"/>
- To use this form in a JSP page, you'd write something like:
<html:form action="subscribeAction.do">
Enter Account id here:
<html:text property="accountId" size="25" maxlength="25"/>
<html:submit property="action">
</html:form>
- Very similar to C2, the "subscribeAction" string is a name mapped to an
Action class which has a perform method that takes (HttpRequest,
HttpResponse, SubscribeForm)
Struts takes it from here and generates the following HTML from the JSP:
<form name="subscribe" method="POST" action="/subscribeAction.do">
Enter Account id here:
<input type="text" name="accountId" maxlength="25" size="25" value="">
<input type="submit" name="action" value="button.ok"/>
</form>
How does use that? Smart. Reflection. The names of the input tags are
simply pointers to JavaBean properties of the SubscribeForm. For each name
"someproperty", Struts will expect "getSomeproperty" and "setSomeproperty"
methods to be present in the Form. So all the SubscribeForm is:
public class SubscribeForm
{
public String getAccountId() { return accountId_ };
public void setAccountId(String aid) { accountId_ = aid};
// ... so on
}
The name field can be not just simple property expression, but almost any
type of JavaBeans property you may want to access. For example:
name="user.address[2].country" translates to:
getUser().getAddress().elementAt(2).getCountry() for populating the original
value in the HTML, and
getUser().getAddress().elementAt(2).setCountry() for populating the JavaBean
when the form is submitted.
Of course the two lines above are simplified, but anyone with some
reflection experience will get the point.
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/
So, using a similar descriptor concept to struts-config.xml, one could
describe:
a) a form name that maps to a Java Bean class
b) using JAXB (or Castor) one can map the JavaBeans class to XML
representation
c) with Jaxen/SaxPath one can acomplish automated population/serialization
of (name=XpathExpression, value=String) to and from HTML POST <-> JavaBean
d) Xerces2 can validate the resulting JavaBean through JAXB SAX parsing
agains an XML Schema.
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:
<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.
--
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]
