cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: Building a DOM Model with XMLForms
Date Sat, 12 Oct 2002 15:58:25 GMT
Robert,

Sorry for the delayed reply.

----- Original Message -----
From: "Robert Ellis Parrott" <parrott@fas.harvard.edu>
To: <cocoon-users@xml.apache.org>
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:     <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
>


---------------------------------------------------------------------
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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message