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