You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Chris Finn <ya...@yahoo.com> on 2001/11/06 23:57:25 UTC
RE: [RT] Flowmaps revisited
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
Re: [RT] Flowmaps revisited
Posted by giacomo <gi...@apache.org>.
On Wed, 7 Nov 2001, Sylvain Wallez wrote:
>
>
> giacomo a écrit :
> >
> > On Wed, 7 Nov 2001, Torsten Curdt wrote:
> >
> > > > >> 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.
> > >
> > > Being so impressed by this idea I implemented something similiar.
> > > I figured out that you have to distinguish between different
> > > _types_ of actions. Maybe this distinction should be forced
> > > for the proper use.
> > >
> > > * transition actions
> > > * sitemap actions
> > > * business actions - who are in fact methods of the diff. BOs
> > >
> > > (Currently transition + sitemap actions = cocoon actions)
> > >
> > > It seems like the implementation of the transition actions can have
> > > a deep impact on the verbosity of the flowmap. I'm not quite sure
> > > if nesting actions is really a good idea. Then you have merge the
> > > results, match them and we will have to sitemap instances one
> > > for the URI space, one for the flow - hm... maybe not that bad at
> > > all. Maybe the same code could be shared... Just an idea...
> > >
> > > In general I feel a full implementation of the flowmap (integrated
> > > with the sitemap) might remove most of the actions from the sitemap
> > > which is IMHO is a good thing. (This might bring back one of the goals
> > > for the sitemap "minimum verbosity" and SoC) It then comes back to URI
> > > mapping and will not be abused to build applications.
> >
> > Yes, definitively. That is what Stefano and I am talking about this
> > week. We have one eye at Berins proposal from Juli this year and we try
> > to get the picture of the puzzle :)
>
> Giacomo and Stefano living together for a few days : be prepared for
> nice RTs or even more ;)
Hey, don't expect too much. There are old sins to be atone ;) (like the
label attribute which is giving me some implememntation headaches
because of XSLT).
Giacomo
>
> > > [snip]
> > >
> > > > 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,
> > >
> > > Why not having a sourceforge project first...
> >
> > I'm not sure about that statement. We could have a vote on this to get
> > the feelings of the other commiters if a Cocoon IDE is something that
> > should be started here or elswhere.
> >
> > Giacomo
> >
> > > > I think it's going to be necessary. We might consider
> > > > the new Eclipse open framework IBM is pushing.
> > >
> > > That's true! I've had a look into "grace" for this
> >
> > >
> > > http://www.gerwin-klein.de/grace/
>
> There are two other nice packages for graph drawing :
> - JHotDraw at http://jhotdraw.sf.net which is used for a Struts editor
> (www.scioworks.com/scioworks_camino.html)
> - GEF at http://gef.tigris.org which is the base of ArgoUML.
>
> GEF is more feature-rich than JHotdraw, but the project seems to be
> asleep.
>
> > > > * 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.
> > >
> > > No!! Using http redirects for flow is bad thing. This
> > > will involve another request!!
> > >
> > > > (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???)
> > >
> > > Short circuit would keep the URL in the browser window
> > > so I am pretty sure it a roundtrip to the client.
> > > --
> > > Torsten
> > >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo a écrit :
>
> On Wed, 7 Nov 2001, Torsten Curdt wrote:
>
> > > >> 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.
> >
> > Being so impressed by this idea I implemented something similiar.
> > I figured out that you have to distinguish between different
> > _types_ of actions. Maybe this distinction should be forced
> > for the proper use.
> >
> > * transition actions
> > * sitemap actions
> > * business actions - who are in fact methods of the diff. BOs
> >
> > (Currently transition + sitemap actions = cocoon actions)
> >
> > It seems like the implementation of the transition actions can have
> > a deep impact on the verbosity of the flowmap. I'm not quite sure
> > if nesting actions is really a good idea. Then you have merge the
> > results, match them and we will have to sitemap instances one
> > for the URI space, one for the flow - hm... maybe not that bad at
> > all. Maybe the same code could be shared... Just an idea...
> >
> > In general I feel a full implementation of the flowmap (integrated
> > with the sitemap) might remove most of the actions from the sitemap
> > which is IMHO is a good thing. (This might bring back one of the goals
> > for the sitemap "minimum verbosity" and SoC) It then comes back to URI
> > mapping and will not be abused to build applications.
>
> Yes, definitively. That is what Stefano and I am talking about this
> week. We have one eye at Berins proposal from Juli this year and we try
> to get the picture of the puzzle :)
Giacomo and Stefano living together for a few days : be prepared for
nice RTs or even more ;)
> > [snip]
> >
> > > 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,
> >
> > Why not having a sourceforge project first...
>
> I'm not sure about that statement. We could have a vote on this to get
> the feelings of the other commiters if a Cocoon IDE is something that
> should be started here or elswhere.
>
> Giacomo
>
> > > I think it's going to be necessary. We might consider
> > > the new Eclipse open framework IBM is pushing.
> >
> > That's true! I've had a look into "grace" for this
>
> >
> > http://www.gerwin-klein.de/grace/
There are two other nice packages for graph drawing :
- JHotDraw at http://jhotdraw.sf.net which is used for a Struts editor
(www.scioworks.com/scioworks_camino.html)
- GEF at http://gef.tigris.org which is the base of ArgoUML.
GEF is more feature-rich than JHotdraw, but the project seems to be
asleep.
> > > * 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.
> >
> > No!! Using http redirects for flow is bad thing. This
> > will involve another request!!
> >
> > > (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???)
> >
> > Short circuit would keep the URL in the browser window
> > so I am pretty sure it a roundtrip to the client.
> > --
> > Torsten
> >
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by giacomo <gi...@apache.org>.
On Wed, 7 Nov 2001, Berin Loritsch wrote:
> Torsten Curdt wrote:
> >
> > [snip]
> > > > Why not having a sourceforge project first...
> > >
> > > I'm not sure about that statement. We could have a vote on this to get
> > > the feelings of the other commiters if a Cocoon IDE is something that
> > > should be started here or elswhere.
> >
> > Well, I would prefer the same repository ;)
> > ...maybe we could introduce a scratchpad like there is in Avalon?
> > --
> > Torsten
>
> If you go that route, I suggest making the folder heirarchy more like Avalon.
> That would be:
>
> ${cocoon}/
> bin/
> lib/
> src/
> documentation/
> java/
> scratchpad/
> test/
> resources/
> webapp/
> webapp.tutorial/
> tools/
> bin/
> lib/
>
>
> In the root bin/ would be the scripts to run Cocoon from the command-line.
> In the root lib/ would be the libraries required for Cocoon to use (i.e. runtime)
> In the tools bin/ would be the ANT scripts
> In the tools lib/ would be the libraries only required for building Cocoon (i.e. ant, junit)
>
> The src/ directory is separated into different source types--like the code,
> the scratchpad area, the test classes, etc. I would be open to treating the
> webapps as a secondary src/ tree like this:
>
> ${cocoon}/
> webapps/
> demo/
> tutorial/
> sitemap-util/
>
>
> In the end it just looks less cluttered, and it makes it easy to know where to
> look for different pieces.
If we will vota about the repository directory structure I clearly vote
+1 for the way Avalon does it. I've found it very tidy.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
>
> [snip]
> > > Why not having a sourceforge project first...
> >
> > I'm not sure about that statement. We could have a vote on this to get
> > the feelings of the other commiters if a Cocoon IDE is something that
> > should be started here or elswhere.
>
> Well, I would prefer the same repository ;)
> ...maybe we could introduce a scratchpad like there is in Avalon?
> --
> Torsten
If you go that route, I suggest making the folder heirarchy more like Avalon.
That would be:
${cocoon}/
bin/
lib/
src/
documentation/
java/
scratchpad/
test/
resources/
webapp/
webapp.tutorial/
tools/
bin/
lib/
In the root bin/ would be the scripts to run Cocoon from the command-line.
In the root lib/ would be the libraries required for Cocoon to use (i.e. runtime)
In the tools bin/ would be the ANT scripts
In the tools lib/ would be the libraries only required for building Cocoon (i.e. ant, junit)
The src/ directory is separated into different source types--like the code,
the scratchpad area, the test classes, etc. I would be open to treating the
webapps as a secondary src/ tree like this:
${cocoon}/
webapps/
demo/
tutorial/
sitemap-util/
In the end it just looks less cluttered, and it makes it easy to know where to
look for different pieces.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Flowmaps revisited
Posted by Torsten Curdt <tc...@dff.st>.
[snip]
> > Why not having a sourceforge project first...
>
> I'm not sure about that statement. We could have a vote on this to get
> the feelings of the other commiters if a Cocoon IDE is something that
> should be started here or elswhere.
Well, I would prefer the same repository ;)
...maybe we could introduce a scratchpad like there is in Avalon?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Flowmaps revisited
Posted by giacomo <gi...@apache.org>.
On Wed, 7 Nov 2001, Torsten Curdt wrote:
> > >> 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.
>
> Being so impressed by this idea I implemented something similiar.
> I figured out that you have to distinguish between different
> _types_ of actions. Maybe this distinction should be forced
> for the proper use.
>
> * transition actions
> * sitemap actions
> * business actions - who are in fact methods of the diff. BOs
>
> (Currently transition + sitemap actions = cocoon actions)
>
> It seems like the implementation of the transition actions can have
> a deep impact on the verbosity of the flowmap. I'm not quite sure
> if nesting actions is really a good idea. Then you have merge the
> results, match them and we will have to sitemap instances one
> for the URI space, one for the flow - hm... maybe not that bad at
> all. Maybe the same code could be shared... Just an idea...
>
> In general I feel a full implementation of the flowmap (integrated
> with the sitemap) might remove most of the actions from the sitemap
> which is IMHO is a good thing. (This might bring back one of the goals
> for the sitemap "minimum verbosity" and SoC) It then comes back to URI
> mapping and will not be abused to build applications.
Yes, definitively. That is what Stefano and I am talking about this
week. We have one eye at Berins proposal from Juli this year and we try
to get the picture of the puzzle :)
>
> [snip]
>
> > 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,
>
> Why not having a sourceforge project first...
I'm not sure about that statement. We could have a vote on this to get
the feelings of the other commiters if a Cocoon IDE is something that
should be started here or elswhere.
Giacomo
> > I think it's going to be necessary. We might consider
> > the new Eclipse open framework IBM is pushing.
>
> That's true! I've had a look into "grace" for this
>
> http://www.gerwin-klein.de/grace/
>
> > * 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.
>
> No!! Using http redirects for flow is bad thing. This
> will involve another request!!
>
> > (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???)
>
> Short circuit would keep the URL in the browser window
> so I am pretty sure it a roundtrip to the client.
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Flowmaps revisited
Posted by Torsten Curdt <tc...@dff.st>.
> >> 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.
Being so impressed by this idea I implemented something similiar.
I figured out that you have to distinguish between different
_types_ of actions. Maybe this distinction should be forced
for the proper use.
* transition actions
* sitemap actions
* business actions - who are in fact methods of the diff. BOs
(Currently transition + sitemap actions = cocoon actions)
It seems like the implementation of the transition actions can have
a deep impact on the verbosity of the flowmap. I'm not quite sure
if nesting actions is really a good idea. Then you have merge the
results, match them and we will have to sitemap instances one
for the URI space, one for the flow - hm... maybe not that bad at
all. Maybe the same code could be shared... Just an idea...
In general I feel a full implementation of the flowmap (integrated
with the sitemap) might remove most of the actions from the sitemap
which is IMHO is a good thing. (This might bring back one of the goals
for the sitemap "minimum verbosity" and SoC) It then comes back to URI
mapping and will not be abused to build applications.
[snip]
> 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,
Why not having a sourceforge project first...
> I think it's going to be necessary. We might consider
> the new Eclipse open framework IBM is pushing.
That's true! I've had a look into "grace" for this
http://www.gerwin-klein.de/grace/
> * 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.
No!! Using http redirects for flow is bad thing. This
will involve another request!!
> (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???)
Short circuit would keep the URL in the browser window
so I am pretty sure it a roundtrip to the client.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org