Scott, Your thoughts are quite logical. The initial implementation of XMLForm looked very similar to what you describe. If you go back in CVS to February-March this year, you will see that version.
Over time I was convinced by Torsten and Konstantin, that form processing can involve a lot of business logic and access to multiple resources. This usually involves non-trivial code which is expected to be secure, high performing and readable. Implementing validation with a Transformer and then deciding on the next step with another transformer is applicable but for the most simple form handling scenarios. It can easily stretch the limits of a sitemap's responsibility, which is to organize content, not script business logic. I suggest that you think of a way to implement the wizard demo with the approach you suggest. If you can come up with a solution which will be acceptable to the group, then you can go ahead with the implementation. I'd be happy to apply the patch. Otherwise you should partner with Robert, who is already down the path of extending the currently implemented mechanism to support dynamic creation of DOM models. See his posts in the last few days. Thank you, Ivelin ----- Original Message ----- From: "Scott Schram" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 11:50 PM Subject: Re: Building a DOM Model with XMLForms > 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]>
