cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: Cocoon2 Design
Date Thu, 01 Jun 2000 19:15:33 GMT
At 14:22 +0200 01/06/00, Stefano Mazzocchi wrote:
>The XML model (and Cocoon follows that) is _trying_ to remove all
>hacking from web design.
>
>As we done? no, there are missing pieces in the puzzle. XForm is
>probably the single most important missing piece in this direction....
>Until XForm is shaped, there is no way to make a XML web application
>look "coherent" with the XML model... you simply go from hack to hack.

Well said that man!

[snip]

>Let's make a possible example:
>
>1) you request "GET /employee/add" from your HTML browser
>2) Cocoon returns you an HTML form with the proper pre-commit validation
>logic (implemented as ECMAScript, for example)
>3) you submit "POST /employee/add" from the above form
>4) Cocoon returns you with the response from the above action (which
>might redirect you to another resource).

The GET and POST handlers will also often need to read and write Post Data
via some existing and some not existing Producers and TagLibs.

>How would you achieve this on the server side?
>
>I have no idea!!! That's the point!

This is what I've been trying to deal with.
Glad to have your comments.

>But I have some vision:
>
>1) there must be XSP taglibs for "get" and "post" handling to allow you
>to place both views inside the same page, since they mostly have the
>same concerns

Exactly.

But what I don't understand here, is if we are expecting to be able to use
form data to create or modify existing data; using TagLibs from other
namespaces to do the job, File, SQL, Email, etc.; GET and POST need to
perform different I/O, can we conditionally control the "expression" of
custom tags even though order is defined by the namespace declaration?

Is serialising post data a valid reason for reinstating xsl:export?

Is there another way to leverage this framework's built in ability to
create modified XML, towards modifying files and database records?

>2) XForm markup should be used to render forms

You mean an existing standard, or one to be defined anew?

>3) XSLT stylesheets should render XForm into HTML+ECMAScript for
>client-side validation

There is also a desire from some people to have server-side
validation/transformation as well.

>4) in XSP there should be ways to simplify the creation of the "model",
>either using beans or XML-ized POST.

I've been trying to define a workable "map" between form fields and
structured XML elements. XSchema is possibly the way to go, and could
provide a solution to defining data validation constraints.

>These are VRT (very random thoughts). Use with caution.

As always :)
Ta for the Blah

The way I feel about this is, once we have sorted out some kind of XForm,
we can all make whatever kind of "Bugoons" we want, utilising whatever kind
of storage and retrieval system is appropriate. Ah yes, we also need to
make it semant(ha)ic.


regards Jeremy
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

Mime
View raw message