Re: Building a DOM Model with XMLForms
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]
Re: Building a DOM Model with XMLForms
On Sat, 12 Oct 2002, Ivelin Ivanov wrote: Robert, Sorry for the delayed reply. - Original Message - From: Robert Ellis Parrott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 11, 2002 10:35 AM Subject: Building a DOM Model with XMLForms Hi folks, I'm working on a project prototype where I'm trying to implement a kind of wizard using XMLForms. The difference is that I'd like the XML docs written by the content people to define the resulting XML doc, without specifying it ahead of time. In other words, I'd like the elements attributes to be built by the XPath commands that originate from the XForm ref attributes. I'm using 2.1-dev, a fairly fresh snapshot. The design of the Form class in Cocoon at this point is that all the elements must be present ahead of time, or one get silent failures (Invalid data format could be a little more descriptive when the failure is because there is no matching path). Actually there is a matching path. Try the demo and type a random string in a numeric field. The Ivalid data message will appear right next to the bad field. My only point here is that the message is somewhat misleading. The response from the Form class is Invalid data format, while the actual error from JXPath is actually Cannot set property /somelement[0], the target object is null, which is really a different error, not format of data but the actual path itself. However, don't think that the JXPath Exceptions are fine-grained enough so that one can differentiate the two errors without doing some sort of string matching of the JXPath error message. This design makes sense when working with Beans as your Model, but could (should?) be more flexible with DOM; for example, if there is an either/or construct in your DTD ( !ELEMENT myelement (sub1 | sub2) ), and each sub element complex, you can't ahead of time know how to generate a DOM object that will have a given element available to XPath. Would it make sense within the scope of XMLForms in Cocoon to add the ability within the the Form class to add new elements to the DOM object when they are missing? It seems that this should be fairly simple: just define an AbstractFactory for the DOM, and use it within the Form class whenenver an access to an element fails for a DOM. Where the AbstractFactory would come from etc is a good question, though. I think that it makes sense to add the extra logic in the Form class. It should be relatively lightweight operation. As you suggestion in the Bugzilla entry, you can use the JXPath API for this. Right. I think the simplest approach would be a getJXContext() method. No big change. Maybe the same with other private vars? The reason I ask is that alternatively I could use something like Castor to rebuild a Bean for the expected XML document, biting the bullet that I can't hand over full control of the XML creation to the content creators. If people think that it's a good idea and doable to allow XMLForms to build a DOM based on the XForms elements, then I would strongly consider working on these modifications; otherwise I would probably take the path of least resistance go with a basic Bean approach. I think this is a good idea and I know that other people requested it before. It was actually a matter of resources until now. While working on this, please evaluate the DynaBeans in Struts 1.1 and see if we can borrow ideas from them. 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. rob - 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]
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]
Re: Building a DOM Model with XMLForms
Robert, Sorry for the delayed reply. - Original Message - From: Robert Ellis Parrott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 11, 2002 10:35 AM Subject: Building a DOM Model with XMLForms Hi folks, I'm working on a project prototype where I'm trying to implement a kind of wizard using XMLForms. The difference is that I'd like the XML docs written by the content people to define the resulting XML doc, without specifying it ahead of time. In other words, I'd like the elements attributes to be built by the XPath commands that originate from the XForm ref attributes. I'm using 2.1-dev, a fairly fresh snapshot. The design of the Form class in Cocoon at this point is that all the elements must be present ahead of time, or one get silent failures (Invalid data format could be a little more descriptive when the failure is because there is no matching path). Actually there is a matching path. Try the demo and type a random string in a numeric field. The Ivalid data message will appear right next to the bad field. This design makes sense when working with Beans as your Model, but could (should?) be more flexible with DOM; for example, if there is an either/or construct in your DTD ( !ELEMENT myelement (sub1 | sub2) ), and each sub element complex, you can't ahead of time know how to generate a DOM object that will have a given element available to XPath. Would it make sense within the scope of XMLForms in Cocoon to add the ability within the the Form class to add new elements to the DOM object when they are missing? It seems that this should be fairly simple: just define an AbstractFactory for the DOM, and use it within the Form class whenenver an access to an element fails for a DOM. Where the AbstractFactory would come from etc is a good question, though. I think that it makes sense to add the extra logic in the Form class. It should be relatively lightweight operation. As you suggestion in the Bugzilla entry, you can use the JXPath API for this. The reason I ask is that alternatively I could use something like Castor to rebuild a Bean for the expected XML document, biting the bullet that I can't hand over full control of the XML creation to the content creators. If people think that it's a good idea and doable to allow XMLForms to build a DOM based on the XForms elements, then I would strongly consider working on these modifications; otherwise I would probably take the path of least resistance go with a basic Bean approach. I think this is a good idea and I know that other people requested it before. It was actually a matter of resources until now. While working on this, please evaluate the DynaBeans in Struts 1.1 and see if we can borrow ideas from them. Thank you, Ivelin thanx for your input, rob - 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]
RE: Building a DOM Model with XMLForms
I'm working on a project prototype where I'm trying to implement a kind of wizard using XMLForms. The difference is that I'd like the XML docs written by the content people to define the resulting XML doc, without specifying it ahead of time. In other words, I'd like the elements attributes to be built by the XPath commands that originate from the XForm ref attributes. I'm using 2.1-dev, a fairly fresh snapshot. We've got a similar problem. I'm not using XForms/XMLForms due to the fact that I've got a historical code base and 2.1 isn't yet ready for production. However, let me describe what we're doing, a similar approach might be useful for you... In our case new forms are added daily. We have one group of people that define the meta-data for the forms (from which a DTD can be generated). We have another group of people who utilize this metadata to generate the actual forms (most screens/forms utilize only a subset of the possible fields). Given that this stuff changes daily we keep all metadata in a database. We're currently working on a GUI generator that will let the forms builder people build a skeleton XML description of a form using a (essentially) dynamically created DTD (from the metadata in the database). This XML is again stored in the database (as essentially form instance specific metadata specified as XML). At run time we generate the complete metadata for a given form back from the metadata and aggregate this with the stored XML form description to completely describe the form. In addition, at run we generate all relevant data from the database (in the same pass as the metadata generation), so that a complete metadata and data XML tree is available for each form element used by the form designers. An XSLT then merges these two trees to generate a new set of nodes which is used by a separate presentation XSLT pass to actually generate the form. I think, in your case something similar would be possible: aggregate the GUI designers XML description with a (possibly transformed) XForms DTD (which you may have to create?) via an XSLT, then feed this to the actual XForm transformer? - 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]
