cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: Anyone using XMLForm?
Date Thu, 11 May 2000 09:28:48 GMT
Donald Ball wrote:
> Now you're poking holes at the underlying premise of XMLForm. It's not
> very easy to construct an arbitrary tree from a collection of XPath-like
> expressions. Maybe you and Jeremy should get together to work on the next
> iteration of this concept - he had the good thought of generating the form
> from a skeletal XML fragment so that it would be easier to map form
> elements to XML result nodes. If y'all want to take over maintenance of
> XMLForm, let me know.

I am a little uncomfortable with the concept as a whole, probably
because I am too dumb to understand it. Anyway, I think we should adhere
more to the principles of KIGS and KISS (G for Generic).

So, the big question, that I have been asking myself, is how to make a
"generic" XMLForm application. I want to have something that will work
with any XML-file, regardless of its structure. I don't want to write
new XSPs and XSLTs every time I have another XML document with a new
structure, I want one generic application that can edit any XML file. A
tall order, perhaps?

I am sure with XML Schemas or the XML skeleton idea the whole thing
becomes doable in a nice fashion, but I was thinking of a quick XSP/XSLT
only solution. Probably it's too dirty to be useful for anyone but me,
but anyway here are my thoughts:

First I have a central XML file called "defs.xml". It contains
definitions that describe the other XML documents, that should be edited
with XMLForm. This defs.xml is the only file I have to edit, once I
introduce new XML files into my XMLForm workflow. Of course, editing of
defs.xml should be done via XMLForm, too. My defs.xml could contain
something like:

<def name="product" text="Product" type="text" sort="0"/>
<def name="price" text="Our Price today" type="text" sort="1"/>
<def name="description" text="Product Description" type="html"

This basically defines that I can have XML files like:

<description>This <b>super-cool</b> Camcorder blah blah</description>

Now I write a stylesheet to display the Camcorder info. What I do is I
select every child of <item> and compare its name() with the @name of
any of my defs. If I find something, then I know three things: The text
to display, whether the field should be HTML, XML or plain text and how
to sort this line. (The latter is important, because due to parameter
passing XMLForm changes the order of the elements within <item> after

The good part of this idea is that there is only one central defs.xml
file and wherever I need its data I can <util:include-file> it. The bad
part is that I currently can't get the util taglib to work ;-)

So, to summarize, with this approach we can:

1) add new <item> objects and remove old ones
2) change the value in <item><*>value</*></item>, regardless of the
actual names of the <*>...</*> tags
3) change the names of any <*>...</*> tags
4) add new <*>...</*> tags
5) define the order in which the <*>...</*> tags are supposed to occur,
their type and whatever else

The only thing that is still fixed and not editable with this approach
is the structure of the XML documents up to and including the <item>
object. I think I could live with that and also believe that this
problem is solvable, should the need arise.

The last step would be to freeze the structure of the defs.xml file and
create a metadefs.xml file for it, so we can edit defs.xml with XMLForm
as well.

Well, so far my ad-hoc ramblings,



Ulrich Mayring
DENIC eG, Systementwicklung

View raw message