cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject RE: Cocoon2 Design
Date Fri, 02 Jun 2000 08:46:45 GMT
At 22:32 +0200 01/06/00, Neeme Praks wrote:
>What is actually the status of your work? Any draft examples?
>There were some examples in a thread some time ago, but they were very
>vague... Anything more concrete? Concrete examples, like the one Stefano
>presented for sitemap?

Nothing more concrete yet. I feel like I am chasing my tail :)

Unfortunately, I am still trying to work out what is and what is not
possible to do with TagLibs, specifically, when tags from two or more
TagLibs are used on the same page.

IE. how stored information is fed to forms and built/modified from forms.

IMHO an XForm TagLib (or the XSP the Tags are in) would want to use other
TagLibs for reading and writing to whatever datasource is required.

For example:

Stefano's "GET /employee/add" and "POST /employee/add"

What I assume he means, is that there is a single XSP that can handle both
a POST and a GET request. ie. The single XSP "knows" how to handle a
particular DTD, and provides the ability to create a new Record or File to
hold that information.

The XSP that did this would have to do different reads and writes to the
datasource for GET and POST, meaning the Tags that dealt with storage would
have to be expressed conditionally. I don't know if this is possible.

Another example: "GET /employee/edit" and "POST /employee/edit"

In this situation we might have a separate XSP that only knew how to
"edit", or maybe there is just one that knows how to both "edit" and "add",
whatever ....

I assume we would not want to have one Edit XSP for every employee (or
editable page on your site!!!). The XSP will need an identifier (specific
to the storage method) to locate which particular File/Record/File#Fragment
(whatever) to modify.

It would need to do a different set of reads and writes to perform it's

The next big issue I see, is how to encode into XForm, what I call the
"glue" and the "constraints" and whether we should use XSchema to do this.

The "glue" is what defines which form field maps to which element in your
XML, it allows the author to define which elements can be edited etc.

The "constraints" define how data is verified, both on the server and the

Then we can start deling with some of the other issues like, what happens
after a form has been successfully POSTed and the data saved. We might need
to contact the Bank, or update the XLink-Map RDF etc. etc.

So, there you go, I am still in a large vat of slow setting concrete,
chasing my tail :)

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
    <phone:+44.[0].20.7737.6831>        <>

View raw message