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: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- 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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
