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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: <[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]> > --------------------------------------------------------------------- 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]>
