cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon2 Design
Date Thu, 01 Jun 2000 12:22:56 GMT
Neeme Praks wrote:

> what I like about Turbine and what I would like also to see in Cocoon,
> is the ability to specify the action(s) to be performed separately from
> the screen to be displayed.

Yeah, separate the "view" from the "controller". Again, separation of
concerns.
 
> Ideally, I would like to change the HTTP protocol to allow me to send
> more than one URL within an request. Something like this:
> EXEC /myAction
> GET /myScreen

AAAAAHHHHHHHHH!!!!!!!

In case you didn't know, modifying the HTTP protocol is _not_ an option
we have.
 
> Why? In the case of form handling people usually want to do some
> post-processing of the form data as a final step in the form submission
> process. If something is wrong with the data, I want to show some page
> where the user can fix the problem with the data. If everything is ok,
> then the action will be executed (myAction) and the original page
> requested (myScreen) would be rendered.

I strongly believe we can do MVC separation on the server side without
requiring protocol changes. 

> However, as HTTP allows only one URL at a time to be passed to the
> server, Turbine introduces a way to include more than one URL to be
> encoded in a single URL...

You are "misinterpreting" URIs.

URIs are simple "resource" locators. A resource is something that is
connected to that URI, just like your house with your address. When you
say "Send a mail at Neeme's house", you don't encode information about
"how" that mail should be processed or "who" should deliver it to you.
That's simply not your concern.

An HTML/HTTP based web application is a hack: the web was _not_ designed
for that. Otherwise, state would be added directly to the HTTP protocol.
The web was designed stateless. URIs were designed to indicate resources
and HTTP actions were designed to indicate "how" to use that resource.

Period.

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.

Also, what the model is missing, Cocoon will add it.

So, Turbine proposes the MVC model for web applications. So each
resource is composed by three entities: model, view and controller.

I don't like the MVC terminology so I'll use: model, styler, controller.
which indicates you need a model (XForm? RDF? JavaBean?), a styler
(filter) and a controller (generator).

How would something like that work?

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

How would you achieve this on the server side?

I have no idea!!! That's the point!

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
2) XForm markup should be used to render forms
3) XSLT stylesheets should render XForm into HTML+ECMAScript for
client-side validation
4) in XSP there should be ways to simplify the creation of the "model",
either using beans or XML-ized POST.

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

> Right now I don't see a way how Cocoon could handle this need for
> post-processing through a simple request for a single URL... Maybe only
> through POSTing information, instead of GETting it, but the possibility
> to do a POST is not always available.

Why?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message