cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: Building a DOM Model with XMLForms
Date Sun, 13 Oct 2002 13:29:59 GMT

Congrats Robert.

I think you're on the right track.

Fortunately, as was the case before, JXPath is powerful enough to do most of
the mapping and creation work for us;)

Please submit a few sitemap examples about your intended result,
so we can iron out any potential issues.


Thanks,

Ivelin




----- Original Message -----
From: "Robert Ellis Parrott" <parrott@fas.harvard.edu>
To: <cocoon-users@xml.apache.org>
Sent: Sunday, October 13, 2002 12:35 AM
Subject: Re: Building a DOM Model with XMLForms


>
> I believe that XMLForms are accessed by the pipeline via an Action
> Component, based on AbstractXMLFormAction. This is the Component that can
> & would handle most of what you are saying below. The Action taken by the
> Action will depend on the command encoded in the request; one could, at
> the end of many pages, have a submit command that will tell the Action to
> validate, serialize, write to DB, email, etc.
>
>
> The only problem I've found is that the data Model, into which info
> entered into the form is written, must already be specified. This is
> particularly a problem with the DOM object, since it may not be possible
> to specify this ahead of time.
>
>
> As for DynaBeans (which are now part of the Commons & not Struts, btw ),
> it seems that support for them will happen as soon as JXPath has support
> for them (which apparently is planned for v1.1). But I've just looked
> quickly at DynaBeans; I don't know how easily, with a JXPath that supports
> them, it would be to implement a dynamically built DynaBean with XMLForms.
> I guess that that would depend on how the createPathAndSetValue() routines
> work.
>
>
> rob
>
> On Sat, 12 Oct 2002, Scott Schram wrote:
>
> > I've just begun looking at XMLForms, and I wonder if this makes any
sense:
> >
> > When the client posts the XForm, we can start with a completely empty
DOM
> > which is filled in according to the XPath expressions in the XForm.
> >
> > This DOM starts a pipeline as, say, a PostedXFormGenerator.
> >
> > Then, there could be a basic validation component in this pipeline,
which
> > could include validation against a DTD or Schema.  If there's an error
in
> > this phase, it redisplays the form page with errors.
> >
> > The user can write custom validation components as well, and they would
> > report errors in the same way.
> >
> > Any Cocoon component could be inserted here..., XSLT transform,
Emailing,
> > whatever.
> >
> > There would be at some point in the pipeline would be a component that
does
> > the business logic with the posted data.  This component would be also
be
> > able to test for errors and send the form back for client redisplay with
> > the errors in a similar fashion to that of the basic validator.
> >
> > Assuming everything was successful, it could create some output and
> > serialize it, or transfer control to another pipeline which would make
some
> > output.
> >
> > So, it would be XML pipelines both ways...  no beans at all, unless you
> > want to make some using, say, the digester in the Apache commons, or
grab
> > the data out of the DOM with an XPath -> bean property map.
> >
> > This might be immensely helpful in systems with hundreds of forms, or
where
> > the information to be taken in on the form was dynamically generated by
the
> > business logic, and the fields might not even be known until runtime.
(For
> > example, a bugzilla or scarab application that has user configurable
forms
> > for reporting bugs on different projects.)
> >
> > It also picks up the advantages of all existing Cocoon components.
> >
> > What do you think?
> >
> > I'd be happy to help with this effort, as best I can given
> > cocoon-beginner-status.
> >
> > ---
> >
> > With respect to DynaBeans in Struts, they're dynamic hash maps of
property
> > -> value, but you still have to define all of the properties in the
struts
> > configuration file.  They act like beans, but only if you use the
routines
> > in the BeanUtils in the commons that were written to support them.
> >
> > There's a nice summary of DynaBeans here:
> >
> > http://www2.theserverside.com/resources/article.jsp?l=Struts1_1
> >
> > Scott
> >
> > >A Form subclass (say DynaForm) which creates DOM nodes when not
existant
> > >will be a good addition, but we have to document clearly that there is
a
> > >danger in using it. If the document author mistypes an element name
> > >reference, it will be created automatically even if it weren't desired.
The
> > >current Form class is type safe in this regard.
> > >
> > > >
> > > > Well, I'm happy to spend a little time on this, especially if it
might
> > > > benefit others. I'll look into DynaBeans. Thanx for the pointer.
> > > >
> > > >
> >
> >
> >
> > ------------------------
> > http://schram.net
> >
> >
> > ---------------------------------------------------------------------
> > 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