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]>

Reply via email to