cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Finn <yarnfish2...@yahoo.com>
Subject RE: [RT] Flowmaps revisited
Date Tue, 06 Nov 2001 22:57:25 GMT
Daniela, sorry for the delay in responding.  Thanks
for the responses.  I've spent the last few weeks
working on a variation of your design for an
application we're delivering, and I've learned quite a
bit.

>> 2) Is it possible to have multiple actions take
>> place
>> during the processing of a state?
>
>Good question.
>
>First, I was tempted to answer with "yes", because I
>was so used to the
>current action model of the sitemap, but the longer I
>think on this, the
>more I'm convinced that "no" might be the more
>approriate answer.
>
>I think it might result in a much clearer model if we
> assume that each hidden state is bound to exacly one
> action. If you need a second action to be executed,
> this should be done in a seperate state.
>
>But I'm not yet sure on this point.

I've implemented something recently similar to your
model.  What I've found is that there can easily be an
*explosion* of transitions, states and hidden states
for even a modest application.  I haven't had a need
to chain actions together yet, but it is trivial to
support and I can think of plenty of instances where
you'd want to.  My vote would be to allow actions and
nested actions, but promote a "proper" use where only
*screenflow* logic is represented in the flowmap;
business logic should be factored out of the flowmap.

>> 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?
>
>Hmm, no, we haven't found a need yet (have you?) and 
>I'm not sure if
>there is one. The usual way to handle this is to
>store this kind of data
>somewhere else (e.g. in the session) and to retrieve
>it from this place
>when generating the page. But you can convince me
>otherwise.

Perhaps the action is a call to a rule system which is
capable of returning a map of results corresponding to
things like "which rule fired" or "reasons why this
result was produced".  How you'd process that with
simple <if> elements, I don't know--now that I think
about it, I also don't see a big need--I was mainly
interested in maintaining parity with Cocoon actions
which return a Map instead of a String.  We've ended
up using the session to pass this complex information.
 I haven't decided if this is an impure mixing of
concerns.  In most cases, our actions store Java
objects in the session which the generators then
operate upon.  While the actions don't generate XML,
they are doing generation of new objects in the
"model" represented by the session.  My concern is
that such implicit action behavior isn't really
documented anywhere.

>Hm, are you talking about common menus just as a
>group of hyperlinks
>that you want to place on a number of pages? Or are
>these really links
>to pages that are part of a flow (carrying event
>parameters and so on)?
>I think it's important to distinguish between these
>two navigation
>types, and you might want to use a different menu
>generating mechanism
>for the both.

Related to the flowmap explosion I've talked about
earlier: we're dynamically generating all links within
the app--no link appears that isn't represented by a
transition in the flowmap.  A lot of these links end
up being the same from page to page (i.e., for common
menu bars).  It's led us to consider an <eventHandler>
element.  For example, if you have several states that
all need to process the same set of events, you would
define an entry like this:

<eventMaps>
<eventMap name="CommonMenu">
	<if event="A" transition="A"/>
	<if event="B" transition="B"/>
	<if event="C" transition="C"/>
	<if event="D" transition="D"/>
</eventMap>
</eventMaps>

then in the state:

<state name="MyState" resource="MyState.xsp">
	<eventHandler name="eventMap"/>
</state>
<state name="MyOtherState"
resource="MyOtherState.xsp">
	<eventHandler name="eventMap"/>
</state>

Furthermore, we've also found that it is nice to
convey some information (like the name of the
eventMap, or the particular "event" that will be a
POST target) along with the flowmap links generated in
the XML.  This is the trick that allows us to treat
link generation as part of the generated XML (and not
as a post-generation step with a transformer).  We
tried to match up the generated links to the right
locations in the XSL for an HTML page, and quickly
found out how hard this can be.  So to get around
this, we pass this meta information about the links in
the generated XML for the links.  E.g.,

<FlowLinks>
	<FlowLink href="A.xsp?event="SUBMIT" display="Submit"
grouping="MyFormName"/>
	<FlowLink href="A.xsp?event="DO_THIS" display="Do
This" grouping="CommonMenu"/>
	<FlowLink href="A.xsp?event=DO_THAT" display="Do
That" grouping="CommonMenu"/>
	<FlowLink href="A.xsp?event=DO_WHAT" display="Do
What" grouping="CommonMenu"/>
</FlowLinks>

That makes it possible for a common menu to query into
the produced XML and iterate through all the
"CommonMenu" links to produce the common menu, or for
a form definition to refer in XSL to a
"/FlowLink[grouping='MyFormName']" XPath to figure out
what it should use for its POST action target.

As I've mentioned before, there are several things I
don't like about our current implementation.  You may
or may not be seeing these same issues.

* While the number of visible <state> elements is
manageable (in effect, the flowmap becomes a registry
of the pages in your app, along with the events they
can respond to), the number of <transition> elements
to keep track of gets big very fast.  Especially if
you have variations on similar paths through the app. 
Reusing states and transitions within an application
is not as easy as I expected, but we may be able to
fix that when we refactor.
* Manually building a valid flowmap is difficult and
error prone.  The second app I wrote with the flowmap
was a flowmap validator that checked the 10 most
common inconsistencies we'd find with large flowmaps. 
;)
* The complexity of some of the flowmaps we've built
makes us long for an IDE to lay out the app (or
perhaps a web app under Cocoon to manage flowmaps). 
Although I don't think the Cocoon crowd is up for
distributing a drag-and-drop flowmap IDE with Cocoon,
I think it's going to be necessary.  We might consider
the new Eclipse open framework IBM is pushing.
* The other confusing thing for developers and users
is that because we took the tip to "always post back
to the page that generated you", the URL in the
browser window shows the page you came from, not the
page you're on, and the hover status in the status bar
doesn't give the right visual feedback about what's
going to happen.  I guess we could do something with a
redirect instead of generating the page the
flow-handler tells us to, but I haven't tried that. 
(Does anyone know if the sitemap "redirect" map
element does a complete redirect roundtrip to the
client, or does it short circuit and just redirect
within the context of the open request???)

Thanks again,
Chris



__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

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


Mime
View raw message