----- Original Message ----- From: "Robert Ellis Parrott" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 12, 2002 11:14 AM Subject: Re: Building a DOM Model with XMLForms > > 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.
Yes. I thought about this and decided to go with the least harmful message. For an end user JXPath messagas might be misleading. Hopefully in future there will be a mechanism for a finer grained differentiation between problems. Maybe an exception tree of some sort. > > > > > >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? I think that exposing JXContext directly makes the XMLForm API unclear... On the other hand a protected method wouldn't be such a bad idea, at least until we come up with a better extension to the public API. 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. > > > > > > > > > > > > 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]> > --------------------------------------------------------------------- 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]>
