cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivelin Ivanov <>
Subject Re: [RT] Flowmaps
Date Sun, 16 Jun 2002 20:17:04 GMT

 > c) the sitemap executes the "getNumberA.xsp", which is given by
 > <xsp:page
 >   language="java"
 >   xmlns:xsp=""
 >   xmlns:jpath=""
 > <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="">
    <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:submit id="submit" class="button">

The XMLForm transformer can automatically do the job of the jpath logic
sheet and append the continuation parameter to the request.

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

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

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

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



To unsubscribe, e-mail:
For additional commands, email:

View raw message