cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Re: XMLForms Versus Traditional HTML forms.
Date Wed, 29 Jan 2003 05:01:47 GMT
Theoretically, but if you were trying to deliver an action driven system,
this would be difficult. You would have to validate inside the pipeline and
that would be problematic for a number of reasons. You would have to write
some sort of custom validator. The problem here is that configuration is
being done at the sitemap level and that is resource intensive. IT would be
much more efficient if you could drop in a set of beans, have a Java class
read them via introspection and then generate forms based upon the needs of
that command. Then you would have a command driven architecture that would be
quickly adaptable. all you have to do is drop in another command (a bean
object) and viola, a new form gets spit out the far end. I will screw with
this and see if I can get it to work. Call it "reflexive form generation" =)

-- Robert

----- Original Message -----
From: "Geoff Howard" <cocoon@leverageweb.com>
To: <cocoon-users@xml.apache.org>
Sent: Wednesday, January 29, 2003 6:06 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


> also there's supposed to be support for validation, error handling, and
> persistence across calls, right?
>
> > -----Original Message-----
> > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > Sent: Tuesday, January 28, 2003 11:59 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: XMLForms Versus Traditional HTML forms.
> >
> >
> > > -----Original Message-----
> > > From: Robert Simmons [mailto:derisor@arcor.de]
> > >
> > > As for multi-content, I could easily write a transform that
> > > converts things
> > > to WML based forms. Its a matter of taste. Its also a matter of
> > > necessity. I
> > > have already spent too long working on the presentation layer to
> > > my project
> > > and I don't care to invest another month. I am not merely a
> > learner but a
> > > professional with tight deadlines. I'm not sure its worth the
> > > extra effort.
> > > But the "not sure" is why I posted the question. If I was sure,
> > I wouldn't
> > > have posted.
> >
> > One potential upside is the fact that XMLForms uses beans for the
> > datamodel
> > (I think).  that being the case, I have assumed there'd be a way to let
> > ejb's fill that role (which based on past discussions I assume
> > you're using
> > here) and you'd get the binding to/from the form for free as you
> > can in jsp.
> >
> > >
> > > Another thing is if it is in draft than that would be one reason
> > > for me to do
> > > it the old way. Real business applications require something that
> > > works. That
> > > isn't always the same thing as something that is "cool".
> >
> > I've not used xmlform yet because of the draft status and the time to
> > learn - same issues you raise.  Looks quite promising though,
> > especially if
> > the bean hunch pans out.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Please check that your question  has not already been answered in the
> > FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> > For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message