Re: Building a DOM Model with XMLForms

[Ivelin Ivanov]

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
> (  ), 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

[Robert Ellis Parrott]

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

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Building a DOM Model with XMLForms

[Ivelin Ivanov]

- 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
> > > (  ), 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]>

Re: Building a DOM Model with XMLForms

[Robert Ellis Parrott]

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
> > (  ), 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

[Ivelin Ivanov]

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.

Re: Building a DOM Model with XMLForms

[Scott Schram]

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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Building a DOM Model with XMLForms

[Ivelin Ivanov]

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

[Hunsberger, Peter]

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

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Building a DOM Model with XMLForms

[Robert Ellis Parrott]

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). 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
(  ), 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.


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.


thanx for your input,


rob




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>