> From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]]
> On Wed, 10 Apr 2002 20:54:19 -0500, "Ivelin Ivanov"
> <[EMAIL PROTECTED]> 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.
Would you mind if I join to Ivelin in asking ...say, questions that are
easy for you to answer? ;)
> >
> > In this flow, how do you implement a jump from page1 to 2 or 3
> > depending on the user selection. To reuse Konstantin's example, say
> > on the first page the user checks a box whether s/he has a car or
> > not. Then page 2 collects information about the car, but its
> > optional depending on the selection in 1.
> >
> > Could you fill in the "..."s in the snippet above.
>
> I thought this was obvious, sorry about this. Here it goes.
>
> 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.
Let me ask a question? Would you need to do "pretty much everything" in a
flow controller? IMO, flow controller has well defined and limited task:
move from state to state and select appropriate "view" (page in your case)
depending on the data model for this flow and current request. So, I can
seem a little importunate, but your sample can be easily rewritten like
this:
<flow>
<variables>
<variable name="instance" type="xml" />
</variables>
<operations>
<operation name="getUserResponse" class="my.GetUserResponse"
/>
</operations>
<state id="firstpage">
<on-enter>
<!-- initialize the $instance variable -->
<!-- send response to caller, e.g. the sitemap -->
</on-enter>
<on-event name="next">
<exec operation="getUserResponse">
<set-result var="$instance" />
</exec>
<choose>
<when test="XPath($instance,
'/customer/hasCar')">
<goto state="second" />
</when>
<otherwise>
<goto state="third" />
</otherwise>
</choose>
</on-event>
</state>
<state id="firstpage">
...
</state>
<state id="firstpage">
...
</state>
...
</flow>
So, this is the XML version of the same thing. A little verbose for
handwriting, but much better for a Visual Flow tool creation. What do you
think? What can procedural approach do more than this? Continuations can be
handled by the engine itself (which in turn can be implemented in Rhino's
JavaScript, Scheme or something else).
>
> 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().
>
> 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.
And this is very similar to the approach we've used in our Screen Flow
Controller and it uses XML script and someday we'll develop a GUI tool for
it, just like the one which is used in WebLogic Process Integrator! ;)
Regards,
Konstantin
>
> Does this make sense?
>
> Regards,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU,
> Emacs, other stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
