cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: continuation fear (was Re: [status & RT] design challenges)
Date Thu, 11 Apr 2002 12:15:10 GMT

Ovidiu,


----- Original Message -----
From: "Ovidiu Predescu" <ovidiu@apache.org>
To: "Ivelin Ivanov" <ivelin@apache.org>
Cc: <cocoon-dev@xml.apache.org>
Sent: Wednesday, April 10, 2002 9:34 PM
Subject: Re: continuation fear (was Re: [status & RT] design challenges)


> On Wed, 10 Apr 2002 20:54:19 -0500, "Ivelin Ivanov" <ivelin@apache.org>
wrote:
>
> > I'll keep asking dummy questions until I start to get the picture or you
> > stop responding ;)
>
> Please keep asking if you see I don't respond ;-) There was a lot of
> traffic these days on the mailing list, and I know I forgot to answer
> to few messages I wanted to.

Oh, you're trouble, you didn't want to give me the green light .. :)

>
<snip/>
>
> Say the checkbox could be obtained from the request using the "hasCar"
> name. You can then write something like this:
>
> function transaction()
> {
>   ...
>   sendPage("page1");
>   var hasCar = cocoon.request.getParameter("hasCar");
>
>   // do some other stuff to prepare page2, then send it
>   ...
>   sendPage("page2");
>
>   // now if the user has a car we need to ask information on the car
>   if (hasCar) {
>     sendPage("getCarInfo");
>
>     var make = cocoon.request.getParameter("make");
>     var model = cocoon.request.getParameter("model");
>     var color = cocoon.request.getParameter("color");
>
>     // pass the above information to the Java business logic to insert
>     // it in a database
>   }
>
>   // now ask other questions
>
>   sendPage("restOfQuestions");
>
>   ...
> }
>
>
> The idea is that since the flow control is a full programming
> language, you can do pretty much everything in it.
>
> As you notice the flow control is acting the Controller in the
> Model-View-Controller paradigm (MVC). The Model is the business logic
> behind, and the View is invoked using sendPage().

Beautiful.

I want to understand more of the internals. How do you ensure that the
"action" attribute
on the form in "page1" points to a URL which will allow sendPage("page1") to
ever return?

Would it be noncence to say that the major advantage of this solution is the
"continuation" semantics of sendPage()?
If so would it be reasonable to just add a <map:fetch src="page1"/>
construct,
instead of introducing another fully functional language in the mix?


>
> The above sendPage() is actually a simplification, what you pass to it
> is not only the URL to be interpreted by the sitemap, but also an
> object, an array of a dictionary containing information to be placed
> into the generated output by the View, e.g. by the generator in the
> matching pipeline. In this model, the generator no longer needs to do
> any business logic, it just extracts the data from the object passed
> to it. The jpath.xsl logicsheet does this for XSP, but this was only a
> quick way to implement it. In the near future I'll come up with a
> simple transformer which could be placed in the pipeline, that does
> the same thing.
>
> The above MVC programming model will render obsolete XSP and all the
> other page centric approaches to Web programming. The MVC model I
> propose will introduce a very clear separation between the layers of a
> Web application.
>
> Does this make sense?
>
> Regards,
> --
> Ovidiu Predescu <ovidiu@apache.org>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message