Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <20011012134634.36746.qmail@web20405.mail.yahoo.com>
Date: Fri, 12 Oct 2001 06:46:34 -0700 (PDT)
From: Chris Finn <yarnfish2001@yahoo.com>
Subject: RE: [RT] Flowmaps revisited
To: cocoon-dev@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Wow, this is impressive stuff, Daniela.  As others
have mentioned, we too are interested and have done
some design work in this area.  Rather than try to
match your eloquent description, I'll provide a
differential comparison, offer some ideas and and ask
a few questions.

First, can you clarify a couple of issues for me?

> Each transition is described by a unique name, a
> target state and the parameters that are
> required for this transition. These parameters are
> NOT necessary for the
> flow control itself, but they are for form handling
> and automatic generation of flow navigation
> elements. They result either from filling
> form fields or represent environmental data provided
> by the data generation classes.

1) Can you clarify "environmental data"?  Is that
"data stored in the Session" or "data embedded in the
generated XML", or is it other data?

2) Is it possible to have multiple actions take place
during the processing of a state?

3) Is it possible (or have you found a need yet) to
support other types of return values from the Actions
in a state besides the "event" one?

4) In our model, we are considering a
"select/when/otherwise" syntax for handling
conditional logic; however, I like the terseness of
your <if> logic.  An open question is: what's the
minimum set of control structures we can get by with?

Other comments and issues:

Bugaboos
========
Here are the biggest bugaboos we've run into trying to
figure out how to represent transition flow.  While I
think you can design a transition map strategy
assuming a single-page "flat" representation (and
therefore bypass most of these concerns), I also think
that a robust design would take into account
situations when these techniques need to be used.

1) Multiple-flow applications.  Although I personally
don't like sites that make use of these techniques
(because most of them do it poorly), handling things
like pop-up browser windows (window.open() in
Javascript) and framesets can cause headaches in
representing a linear application flow.  The only way
I see around this is to embed "next-state" information
in the generated pages themselves--meaning that the
FlowHandler can't expect to maintain any state
information itself.  Put another way, the "adornment"
of a produced page with the transitions (or links) has
to provide a pre-computed "next-state" recipe that the
FlowHandler can understand.  Is that what you're
proposing?  If so, we've reached that conclusion
independently.

2) Some transitions make sense to be driven by the
client.  Consider a portal window with a smart
Javascript control that wants to use DHTML tricks to
update a stock ticker.  The simplistic option would be
to do a complete refresh of the page with a page-flip.
 A smart model would permit just the XML data that
needed to be interpretted (or perhaps, just the DHTML
that needed to be inserted in the page) to cut down
the flickering and large round trip.  However, this is
a form of "subtransition" that you might like to
represent in a formal way.  [We call these
subtransactions--the poor man's implementation is just
a refresh with different parameters in the URL.]  I'd
like to think you could still represent this as part
of the flow (because it involves server requests).  As
apps become more interactive, I think this needs to be
accounted for.

3) Flow adjustment based on conditional information. 
Consider a site where after login, you must pass
through a click-through agreement.  Furthermore,
assume that this click-through agreement may change
from time to time, and the knowledge of whether to
display this is controlled by a database setting.  It
appears that your model handles this case well, as
long as the "insertion point" of this branch is known
beforehand.

4) Reusable subflows.  Okay, this is where I think
some problems could arise.  Imagine an application
where you want to have a "reusable subflow"--a
sequence of screens which can be invoked from anywhere
in an application (or in a number of applications yet
to be written).  This can be initiated from different
"Cocoon applications" (or subsites) or from a lot of
different pages.  Rather than account for links to
these subflows everywhere, we need a way to make them
independent and reusable.  Your latest email addressed
some of these reusabilit yissues--I'll discuss one
idea below that is our way around it.  Related to this
are common menus that appear on lots of pages--it'd be
nice to make these reusable in a clean way.

5) Back button problems.  Although I can't tell for
sure, it appears that the model you're describing
stores no state in the FlowHandler, so issues with the
back button might not arise in any of your proposed
use of this.  If you're trying to maintain some state
or a stack of nested subflows, the back button can
mess up the attempts to retain any state.

6) Scalability: take a look at a site like Excite,
with approximately 100 or so transitions off the
initial page.  Many of these links represent "reusable
subflows" that appear on other pages.  The thought of
mapping the flow of an application like Excite is
daunting; I would argue that there has to be a way to
distribute some of the logic of transitions to the
page definition.  Below, I describe one idea that
addresses it (but one which might make you cringe.)

Differential Analysis
=====================
On the reusability of flows: the sitemap as it stands
seems suited towards the publishing roots of Cocoon;
sites that manage documents where strict standards can
be imposed and sitemap rules can be written to define
relationships.  Most of the flowmap/transition map
proposals I've seen seem suited towards simple
applications or single-site portals.  I'd like to
encourage us to consider scaling these ideas up to a
model where multiple applications could be created
from a library of reusable subflows (groups of states
and transitions).  As it stands, the transition map
design you propose gets us closer in that it
formalizes a set of transitions, but it still seems
like something that wouldn't scale up to a larger
development staff working on multiple apps in parallel
who seek reuse and commonality of subflows.

What I'd propose is a variation on what we use: we
create a global dictionary of the transition
information.  Like a sitemap, it can centralize (or
partition) the definition of reusable states and
transitions.  But unlike a sitemap, this dictionary
provides an interface that hides the representation of
the transition information; if at some point you want
to store the state/transition info in an XML database,
you could do so.  (For now, we use a separate XML file
that hosts this info outside the sitemap.)  This
dictionary allows you to load state/transition
relationships by name.  We think this might help down
the road when we create an IDE for dragging in
pre-packaged subflows to define an application.

Are there enough reasons to store this outside the
sitemap?  Maybe not.  But as I see the sitemap grow
and grow as we'd add this information, it becomes
apparent to me that for maintenance purposes on a live
site, you'd probably want to externalize this and
allow more freedom of how updates are made and
managed, without touching the sitemap (just like we
don't like to touch cocoon.xconf unless there's a good
reason).

On "transition adornment": we believe that in the
generation step (either as part of the generation, or
as an action associated with generation), a standard
XML-blob of pre-built transition URLs should be
provided.  Our presentation XSLs will know to look for
these and associate them properly (e.g., some may be
associated with specific content blobs, others, like
menus, may be associated with the page "globally"). 
This adornment means that the presentation-developer
needs only stick the links in the right place and can
by and large bail out of screenflow concerns.  I
hadn't thought of a transformer approach--to me, it
seems much more like an action that will provide some
aggregatable content.

On distributing this logic: okay, here's where I'll
probably get some flack.  We use XSPs and a custom tag
library.  The tag library allows us to describe both
the content and the transitions from the page.  (What
actually happens because of the "transitions" is
stored in the database or transition map.)  When the
page is requested, the action fires off the aggregated
content requests and simultaneously "adorns" the
transition descriptions to produce the proper URLs to
further the flow.  Think of it as "just-in-time"
screenflow.

Why did we do this?  Think of the excite page with 100
links on it...it seemed just too complex to imagine a
single map describing the screenflow of a site like
Excite...and scaling that up to 10 or 20 similar
applications wanting to reuse states/transitions.  By
distributing some of the transition information into
these XSP page descriptors, we can let people easily
glance at a page and know what it is trying to
accomplish, but defer what it actually *does* to the
definitions in the common dictionary.

Somewhere in there, I've probably lost you...if anyone
is still following, I'd love to hear your thoughts and
opinions.

Other General Comments
======================
I very much agree with your point about delivering
apps now.  I've tried to abstract as much of our
architecture outside of Cocoon as possible to prevent
a moving codebase from hurting us.  I'd love to get
the right solution tunneled into the base
architecture, but I can't wait, so building this
initially as extensions appeals to me (especially if
we can devise an upgrade path to future versions to
preserve the pages and flows we're creating.)

Finally
=======
Finally to Stefano and the rest, I'd like to say how
impressive the Cocoon architecture is...RTs like this
one prove that much of the value of the architecture
comes from its ability to stimulate independent
innovation around the globe.  I find this feature, and
these discussions, as valuable as the actual code.  It
was a pretty cool week to find Daniela's message in my
inbox literally 12 minutes before a design meeting on
the same topic, and then Ovidiu's SOAP work delivered
less than 24 hours later.  Very impressive.

Chris

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

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