cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 19:18:11 GMT
Ivelin Ivanov wrote:
> 
>  > c) the sitemap executes the "getNumberA.xsp", which is given by
>  >
>  > <xsp:page
>  >   language="java"
>  >   xmlns:xsp="http://apache.org/xsp"
>  >   xmlns:jpath="http://apache.org/xsp/jpath/1.0"
>  >
>  > <document>
>  >  <body>
>  >   <s1 title="Calculator">
>  >    <form>
>  >     <xsp:attribute name="action">
>  >      <xsp:expr>"kont/" + <jpath:continuation/></xsp:expr>
>  >     </xsp:attribute>
>  >
>  >     <p>Enter value of <strong>a</strong>:
>  >           <input type="text" name="a"/></p>
>  >     <input type="submit" name="submit" value="Enter"/>
>  >    </form>
>  >   </s1>
>  >  </body>
>  > </document>
>  > </xsp:page>
> 
> What if this is represented by:
> 
> <document xmlns:xf="http://xml.apache.org/cocoon/xmlform/2002">
>     <xf:form id="form-calculator" view="enter_A" action="kont">
>           <xf:caption>Enter Value For A</xf:caption>
>           <xf:textbox ref="a">
>               <xf:caption>number A</xf:caption>
>               <xf:violations class="error"/>
>           </xf:textbox>
>           <xf:submit id="submit" class="button">
>               <xf:caption>Enter</xf:caption>
>           </xf:submit>
>     </xf:form>
> </document>
> 
> The XMLForm transformer can automatically do the job of the jpath logic
> sheet and append the continuation parameter to the request.

Absolutely! The extremely nice thing about the current flowmap design is
that SoC is maintained. The flowmap deals with the logic, but the URI
handling and response generation is the sitemap's responsibility since
it's nothing about 'flow'.

This allows you to do whatever you want to come up with the response,
and your flowmap-aware transformers can be as complex/capable as you
like, just they don't require you to write actions anymore.

>  >
>  > where the "jpath" logicsheet is used to obtain the "continuation" of the
>  > current flow and is then encoded in the URI called.
>  >
>  > So, when the users hits 'submit', Cocoon will receive a request for an
>  > hypotetical URI "kont/39849834983498", then Cocoon will match it with:
>  >
>  >       <map:match pattern="kont/*">
>  >         <map:continue with="{1}"/>
>  >       </map:match>
>  >
>  > and resurrect the flow logic from where it was left. So, again, between
> 
> We can come back to this later, since it affects performance and
> scalability, not functionality, but I'll raise the issue early.
> There is a potential for overloading the server memory with stale
> continuations. This will happen if halfway through the wizard a user
> decides to jump to an unrelated part of the site. The next time they
> decide to return to the wizard, it will start a new continuation stack,
> unless they return with the Back button, which may or may not be the case.

This is a good point: out of my head, we could solve this like we do for
sessions by using an expiration time. In that case, an expired
continuation will trigger you back to the initial state.

Anyway, this requires more thinking... hmmm, great point anyway.

>  >
>  > First of all, let me say that I consider the above concept the biggest
>  > advancement in server-side web technology since servlets.
> 
> It certainly is quite ambitious.

Granted.

> It choses to follow a command line driven input model, versus desktop
> GUI model. Most web apps today chose to act on commands/events much like
> a desktop GUI app.
> It may not be easy or cost efficient to describe some page flows
> with a flowmap. Multi page forms are used often but they are not
> dominating.

Everywhere I looked in the programming circles I've been involved with,
there is somebody feeling lost without the good old procedural
programming.

I know many (myself included) who dislike GUI builders because they are
so declarative that it's scary: they build the skeleton for you (and
this is great), but then you are left with a bunch of work to do to fill
the holes and no global vision whatsover.

When I wrote JMeter, I started with JBuilder and I had a monolythic
piece of software. So I erased it, went back to good old text editor and
came up with a highly modular GUI solution (which is still in place
today after 4 years).

Sure, I agree with you that the flowmap might not map 100% of the cases
well, but if it maps even only 80% of the cases with the simplicity and
RAD of a client side javascript code and the full power of the cocoon
framework, I strongly doubt anybody will complain for that 20% which
requires them to write specific java components.

At least, this is my personal vision.
 
>  > This design not only makes it a breeze to implement MVC, but it shows
>  > you how natural and clear things become once you separate the procedural
>  > flow, from the declarative serving of resources.
> 
> It certainly makes natural describing linear workflow.
> There is a variety of UI usage patterns which are not linear
> and might be easier handled with command/event handling model.

Absolutely. But remember: you are *not* forced to use the flowmap and
for sure, we won't deprecate actions until everybody agrees that they
are not needed anymore (which I grant might be an overstatement from my
side)

> Since I never experimented with the newly proposed approach though, I
> remain very interested in its use cases.

I find myself in the same situation.

Hopefully, by providing more docs and howtos people will try it out and
show us enough usecases to let us validate the concept in real life.
[even if, to be honest with you, it seems just too appealing on paper
not to work in practice]

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message