cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <ne...@one.lv>
Subject RE: Cocoon2 Design
Date Thu, 01 Jun 2000 20:09:41 GMT

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Thursday, June 01, 2000 2:23 PM
> 
> > 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.

;-)
This was just an example to illustrate my point.

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

yep, we can. Only thing that concerns me is the compatibility with the
rest of the world ;-)
Unfortunately, problems like browsers (and proxies) cacheing things they
are not supposed to cache, older browsers not fully supporting
redirects, etc., still force us to hack things sometimes...

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

sorry for that ;-)

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

sad but true...

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

makes sense...

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

yes, this what I was looking for. Instead of trying to pass in many
URLs, you can achieve the same effect by doing redirects. However, for
some reason I have been reluctant to use redirects extensively so
far...can't tell exactly why, though... how is the browser support for
redirects?

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

cannot claim that my comments are something more that this ;-)

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

for example, when I want to use simple link for some action (very common
problem): I cannot POST information together with a hyperlink (without
any use of JavaScript).

Neeme

Mime
View raw message