You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@gmx.net> on 2003/07/16 18:12:27 UTC
[Vote] Controller/Sitemap integration
After the "balkanization" discussion it's time to vote on this last
point before we can release Cocoon 2.1 with stable public interfaces:
Out of Sylvain's RT
[http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016291.h
tml]
> So here are the proposed refactorings :
>
> 1/ In the flow classes. These changes will be totally transparent to
> both existing sitemaps and existing flow scripts.
> - rename "Interpreter" to "FlowEngine",
> - rename "WebContinuation" to "FlowState", and accordingly
> "WebContinuationManager" to "FlowStateManager".
>
> 2/ In the sitemap language. These changes can be disruptive with
> existing sitemaps, but we can provide (although we aren't in beta) a
> compatibility mode :
> - rename <map:call function=""> to <map:call flow=""> or <map:call
> controller="">
> - rename <map:call continuation=""> to <map:call state="">
Compared with the last vote
[http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016879.h
tml]
following items have changed and we need to vote on them again:
[A] The "Cocoon Advanced Control Flow" provides a controller that is
linked into the sitemap (as **child element** of <map:sitemap
.../>:
<map:flow type="[yourEngine]">
[configuration]
</map:flow>
This reflects that the flow is not a *usual* sitemap resource but
something else.
[B] The controller is called by:
<map:call flow="[yourFlow]">
<map:parameter name="x" value="y"/>
</map:call>
[C] A state of the controller is called by:
<map:call state="">
<map:parameter name="x" value="y"/>
</map:call>
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
<flow-engine default="[yourController]" logger="[yourLogger]">
...
</flow-engine>
[E] Changes in the current Javascript implementation:
- rename "Interpreter" to "FlowEngine",
- rename "WebContinuation" to "FlowState", and accordingly
"WebContinuationManager" to "FlowStateManager".
Please cast your votes!
Cheers,
Reinhard
PS: Probably I will not be able to count the votes and summarize the
result as
I'll be on vacation :-)
Re: [Vote] Controller/Sitemap integration
Posted by Geoff Howard <co...@leverageweb.com>.
+1 on all
Reinhard Pötz wrote:
> After the "balkanization" discussion it's time to vote on this last
> point before we can release Cocoon 2.1 with stable public interfaces:
>
> Out of Sylvain's RT
> [http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016291.h
> tml]
>
>
>
>>So here are the proposed refactorings :
>>
>>1/ In the flow classes. These changes will be totally transparent to
>>both existing sitemaps and existing flow scripts.
>> - rename "Interpreter" to "FlowEngine",
>> - rename "WebContinuation" to "FlowState", and accordingly
>>"WebContinuationManager" to "FlowStateManager".
>>
>>2/ In the sitemap language. These changes can be disruptive with
>>existing sitemaps, but we can provide (although we aren't in beta) a
>>compatibility mode :
>> - rename <map:call function=""> to <map:call flow=""> or <map:call
>>controller="">
>> - rename <map:call continuation=""> to <map:call state="">
>
>
> Compared with the last vote
> [http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016879.h
> tml]
> following items have changed and we need to vote on them again:
>
>
> [A] The "Cocoon Advanced Control Flow" provides a controller that is
> linked into the sitemap (as **child element** of <map:sitemap
> .../>:
>
> <map:flow type="[yourEngine]">
> [configuration]
> </map:flow>
>
> This reflects that the flow is not a *usual* sitemap resource but
> something else.
>
>
> [B] The controller is called by:
>
> <map:call flow="[yourFlow]">
> <map:parameter name="x" value="y"/>
> </map:call>
>
>
> [C] A state of the controller is called by:
>
> <map:call state="">
> <map:parameter name="x" value="y"/>
> </map:call>
>
>
> [D] All flow interpreters[3] are Avalon components and declared
> in the cocoon.xonf:
>
> <flow-engine default="[yourController]" logger="[yourLogger]">
> ...
> </flow-engine>
>
>
> [E] Changes in the current Javascript implementation:
> - rename "Interpreter" to "FlowEngine",
> - rename "WebContinuation" to "FlowState", and accordingly
> "WebContinuationManager" to "FlowStateManager".
>
>
> Please cast your votes!
>
> Cheers,
> Reinhard
>
> PS: Probably I will not be able to count the votes and summarize the
> result as
> I'll be on vacation :-)
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Reinhard Pötz wrote:
>>Coming back on the vote:
>>the issue here is not really about renaming these classes, but
>>about introducing this FlowState abstraction layer. Your remark
>>rightfully makes me see I was starting to overlook the subtle nuance.
>>
>>all in all, I have the feeling this is not really part of the
>>public interface we want to nail down here and now ?
>>(meaning that I believe the introduction of this layer could be
>>done whithout much effect on applications that just use an
>>certain flow implementation, of course the flowprocessor impl's
>>themselves would have some refactoring ahead)
>
>
> I don't understand the current flow implementation from Ovidiu and
> Chris or Sylvain's and your proposal in all depth but whatever
> the future brings should only change implementations - the user
> shouldn't even notice that something has changed.
>
I share your hope
>
>>the same remark probably goes for the FlowEngine/Processor and
>>might explain our lesser natural connection to these issues on
>>the table?
>
>
> Sorry, I don't understand what you mean with this last paragraph.
>
yeah, I must say it was very poetic :-)
I noticed much of us have expressed the indifference feeling on
this engine/processor issue,
we'ld have to give it a name here and now, but I guess all of us
kind of 'feel' that changing this in the event we have built up
enough evidence for either case will not be of that high influence...
> Reinhard
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
> Coming back on the vote:
> the issue here is not really about renaming these classes, but
> about introducing this FlowState abstraction layer. Your remark
> rightfully makes me see I was starting to overlook the subtle nuance.
>
> all in all, I have the feeling this is not really part of the
> public interface we want to nail down here and now ?
> (meaning that I believe the introduction of this layer could be
> done whithout much effect on applications that just use an
> certain flow implementation, of course the flowprocessor impl's
> themselves would have some refactoring ahead)
I don't understand the current flow implementation from Ovidiu and
Chris or Sylvain's and your proposal in all depth but whatever
the future brings should only change implementations - the user
shouldn't even notice that something has changed.
> the same remark probably goes for the FlowEngine/Processor and
> might explain our lesser natural connection to these issues on
> the table?
Sorry, I don't understand what you mean with this last paragraph.
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Reinhard Pötz wrote:
> From: Marc Portier [mailto:mpo@outerthought.org]
>
> Hi Mark,
>
> Good remarks!
>
thx.
<snip />
>
>>Renamings:
>> - V1 : FlowState(and -Manager)
>
>
> I would leave the names as they are because as you (I think it was you)
> pointed out that this belongs to the implementation and not the
> interface.
>
> So I'm -0 on a renaming.
>
Well, this in fact touches the very topic of why I think the
<map:continue flow=".." /> could loose the need for a @type
indication...
if all the flow implementations would have their continuing
stateful beasts implement the same interface (FlowState) then we
get to have a higher level of reuse... (and more common stuff
between different implementation, and more cross polination
between their teams, and...)
so what I really meant is that WebContinuation could continue to
exist but then by implementing FlowState and as such be managed
by the BasicFlowStateManager (the same Manager would then manage
the stateful objects that can continue flows initiated by any
engine/processor)
also: implementing a FlowStateManager is IMHO about other
concerns then how you instantiate them in their very nature
(which is the job of the Engine/Processor) -- I'm planning some
RT on those concerns in the near future, think to date I couldn't
achieve a lot more then chaotic ramblings
so the sepecific execution context these managed FlowState's need
to perform their 'continue' action should be enclosed in the
implementation (and thus hidden behind the interface)
[NOTE: I'm using in aparent self-confident-mode a verb like
'should' but I reall am very much in dream-out-loud mode still,
comments and feedback welcome, is this making sense?]
Coming back on the vote:
the issue here is not really about renaming these classes, but
about introducing this FlowState abstraction layer. Your remark
rightfully makes me see I was starting to overlook the subtle nuance.
all in all, I have the feeling this is not really part of the
public interface we want to nail down here and now ?
(meaning that I believe the introduction of this layer could be
done whithout much effect on applications that just use an
certain flow implementation, of course the flowprocessor impl's
themselves would have some refactoring ahead)
the same remark probably goes for the FlowEngine/Processor and
might explain our lesser natural connection to these issues on
the table?
> Reinhard
>
what do others think?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Marc Portier [mailto:mpo@outerthought.org]
Hi Mark,
Good remarks!
> My list then becomes:
> Integrating the flow processor/engine:
> - V2 : flows/flow/(@type,@name)/*
+1
> Call a flow the first time:
> - V2 : initialize/(@flow,@type)/paramaters
+1
> Continue a flow: (just added the option)
> - V7 : continue/(@flow,@type)/paramaters
+1
> Component declaration: (indifferent on the engine-processor)
+0
>
> Renamings:
> - V1 : FlowState(and -Manager)
I would leave the names as they are because as you (I think it was you)
pointed out that this belongs to the implementation and not the
interface.
So I'm -0 on a renaming.
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Reinhard Pötz wrote:
> As I have been confused by all those suggestions you can find a summary
> here:
> http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
>
nice, helps controlling my confusion as well
> After the discussion and all your opinions I would prefer:
>
> Integrating the flow processor/engine:
> --------------------------------------
>
> <map:flows>
> <map:flow name="js" type="javascript">
> <script src="flow/PetStoreImpl.js"/>
> <script src="flow/petstore.js"/>
> </map:flow>
> <map:flow name="java" type="atct">
> <class src="org.apache.cocoon...."/>
> </map:flow>
> <map:flow name="fsm" type="fsm">
> <blabla src="descriptors/fsm.xml"/>
> </map:flow>
> </map:flows>
>
> ... in order to be coherent. Please note that the flow
> element only has name and type. All other things
> are IMO part of the configuration (... someone proposed
> to have a class attribute --> that's useless for e.g. the
> JavaScript implementation)
>
indeed!
>
> Call a flow the first time:
> ---------------------------
> <map:call flow="[yourFlow]" type="js">
> <map:parameter name="x" value="y"/>
> </map:call>
>
> I prefer "call" because this makes the most sense for me.
> But I'm +0.5 with initialize. And I like the word flow otherwise
> it is totally obscured that it is part of the flow implementation.
>
I find 'call' somewhat hiding the initialize/continue essence
nice idea with the @flow (gets us passed the @src discussion)
> Please note again that we need a "type" attribute again.
>
indeed.
> ... and I don't like src because src means something different
> everywhere in Cocoon (something that can be called using the
> SoureResolver ...)
>
>
> Continue a flow:
> ----------------
> <map:continue id="..." type="js">
> <map:parameter name="x" value="y"/>
> </map:continue>
>
in fact liking your @flow so much I would even get it in here to
replace the @id:
in both cases this attribute does the same: it 'identifies' the
'flow' to be started or continued (so going for @flow in the one
would almost impose it on the other on the grounds of coherency,
IMHO)
> Again, I don't like src (see reasons above) and we need the type
> attribute.
>
maybe too early to say, but I would hope that all flow-engine (or
processor) implementations could share _one_ store of active
FlowState's (actually I would see it as one possible
anti-balkanization action, but people with other implementations
in mind might have a different view)
having @type in there for now makes sense, and doesn't harm us
since it could easily become just obsolete in the future case I'm
mentioning
>
> Component declaration:
> ----------------------
> I'm indifferent on this ...
>
me too
>
> --------------------------------------------------------------------
>
> And here a completly new alternatvie (at least for this discussion:)
>
> <map:flow call="" type="js" >
> <map:parameter name="x" value="y"/>
> </map:flow>
>
> and
>
> <map:flow continue="" type="java" >
> <map:parameter name="x" value="y"/>
> </map:flow>
>
> This makes for me the greatest sense because you still know that you
> deal
> with flow and this is not obscured by call, continue, initialize or
> whatever.
>
>
> Perhaps, this would make a renaming of the declaration in
> <map:flows>...</map:flows>
> necessary.
>
>
> What do you think?
>
I like the ones above more, with only the slight remarks
(just added some to the wiki to reflect)
My list then becomes:
Integrating the flow processor/engine:
- V2 : flows/flow/(@type,@name)/*
Call a flow the first time:
- V2 : initialize/(@flow,@type)/paramaters
Continue a flow: (just added the option)
- V7 : continue/(@flow,@type)/paramaters
Component declaration: (indifferent on the engine-processor)
Renamings:
- V1 : FlowState(and -Manager)
> Cheers,
> Reinhard
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
Hi Jörg,
From: Joerg Heinicke
>
>
> Reinhard Pötz wrote:
> > As I have been confused by all those suggestions you can find a
> > summary
> > here:
> > http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
>
> Cool summary, really helps a lot. And here the cool voting matrix :)
>
>
> | A | B | C | D | E |
> ----|-------|-------|-------|-------|-------|
> | | | | | |
> V1 | -1 | +0 | +0 | +.5 | +1 |
> | | | | | |
> V2 | +1 | -1 | -0 | +.5 | -1 |
> | | | | | |
> V3 | ?? | +.5 | -1 | \ | \ |
> | | | | | |
> V4 | \ | -1 | -0 | \ | \ |
> | | | | | |
> V5 | \ | +1 | +.5 | \ | \ |
> | | | | | |
> V6 | \ | \ | -1 | \ | \ |
> | | | | | |
> V7 | \ | \ | +1 | \ | \ |
> | | | | | |
> ----|-------|-------|-------|-------|-------|
Here my matrix:
| A | B | C | D | E |
----|-------|-------|-------|-------|-------|
| | | | | |
V1 | +0 | +0 | +0 | +.5 | +0 |
| | | | | |
V2 | +1 | -1 | -1 | +.5 | +0 |
| | | | | |
V3 | +0 | -1 | -1 | \ | \ |
| | | | | |
V4 | \ | +.5 | -0 | \ | \ |
| | | | | |
V5 | \ | +1 | +.5 | \ | \ |
| | | | | |
V6 | \ | \ | -0 | \ | \ |
| | | | | |
V7 | \ | \ | +1 | \ | \ |
| | | | | |
----|-------|-------|-------|-------|-------|
Fine. So Marc, you and I agree in the most parts.
I hope you don't mind - I updated
http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration and added
our both votings.
What do others think? Please add your votes at the Wiki! page.
Cheers,
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Stephan Michels wrote:
> On Thu, 17 Jul 2003, Joerg Heinicke wrote:
>
>
>>Reinhard Pötz wrote:
>>
>>>As I have been confused by all those suggestions you can find a summary
>>>here:
>>>http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
>>
>>Cool summary, really helps a lot. And here the cool voting matrix :)
>>
>>
>> | A | B | C | D | E |
>>----|-------|-------|-------|-------|-------|
>> | | | | | |
>>V1 | -1 | +0 | +0 | +.5 | +1 |
>> | | | | | |
>>V2 | +1 | -1 | -0 | +.5 | -1 |
>> | | | | | |
>>V3 | ?? | +.5 | -1 | \ | \ |
>> | | | | | |
>>V4 | \ | -1 | -0 | \ | \ |
>> | | | | | |
>>V5 | \ | +1 | +.5 | \ | \ |
>> | | | | | |
>>V6 | \ | \ | -1 | \ | \ |
>> | | | | | |
>>V7 | \ | \ | +1 | \ | \ |
>> | | | | | |
>>----|-------|-------|-------|-------|-------|
>>
>>
>>What is the difference between A V1 and A V2? Only the <map:flows/>? And
>>what does it mean?
>>
>>B V5 was missing. From Marc's answer I guess he meant this, but chooses V1.
>
>
> Don't you think that this makes the voting really difficult ;-)
>
I think the roundup and visualization really helps
it's just that the voting _is_ complex since there have been a
lot of arguments on the table
the alternative would be to go into the meta-level of discussing
which arguments are valid and which not (hardly easier since a
lot of this is personal perception and not to be black/white or
true/false)
> A: V1
> B: V2
> C: V1 with flow instead of type
>
> D: V2
> E: V2
>
> BTW, I think it too early to vote on this. If I must decide now,
> all will be carved in stone. I think we should leave A-C as it is
> for 2.1. And postpone the discussion to the post-2.1-era.
> For my part, I must have first two implementations to find
> more generalized contract, which we don't have at this point.
>
> So my vote would like:
> Should we postpone the generalisation to the post-2.1-era,
> and hazard with the consequences, that we maybe change the
> sitemap syntax of a released version of Cocoon?
>
> +1
>
I partially agree:
- refactoring and continuous design is the reality of this world:
pretending to 'carve in stone' is close to telling lies
- the stress on getting the abstract level right without the
insight of enough detail in the multiple implementations feels
unnatural (given that refactoring has become so easy)
But I also see the other side of things:
- refactoring and change can be a give to those that know the
internals and live by the laws of cvs-head, the same level of
flexibility eagerness might not be found in settings where
upgrading to the latest stable cocoon release is something that
is scheduled at best once a year
- it might be a challenge to abstract things upfront, but brave
man like us do not fear challenges ;-)
So maybe the consensus getting us into beta stage can maybe be
reached by splitting up
- vote on A-C now, carve in 'sand-stone': these are related to
non-coding end-users of flow, transition from one to the other
costs more
- decide on D-E _for_ now, carve in 'yoghurt': this is related to
developer decisions, dependent developers would probably less
mind if changes occur, their refactoring IDE's would help them
out a great deal...
in both cases we (must realize that we) are making a best
estimate on what we know now, that is just how life is...
the remaining argument to actually decide here and now is it gets
us out of the catch-22: it enables more nicely the alternative
implementations that will get us the deeper insight we're missing
to date
what do others think?
(I might be missing the complete point of release management
here, I don't mind if someone points that out to me)
>
> Stephan.
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Revisited Proposed Flow Renaming (was Re: [Vote] Controller/Sitemap
integration)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Marc Portier wrote:
...
> -2- Interpreter should be changed to FlowProcessor (more sense then
> FlowEngine becomes apparent now?) and its methods could make the
> transition from
> callFunction(String funcName, List params, Environment env)
> handleContinuation(String contId, List params, Environment env)
> towards
> initiateFlow(String flowId, List params, Environment env)
> continueFlow(String contId, List params, Environment env)
>
> which maybe gets mapped back to the
>
> <map:initiate flow="flowId" type="interpreter-name" />
> <map:continue flow="contId" type="interpreter-name" />
>
> that was still under discussion somewhat?
Flowscripts are not only usable for handling page flow in webapps, you
can also write flowscripts that perform some side effects and ends with
a sendPage, (and not use any sendPageAndWait), i.e. perform a side
effect and return a page. This use will not set up any continuation
object and have about the same use cases as actions. I would guess that
people who write a lot of flowscripts will prefer this construction
before with actions. For this use case "call" seem to be a much more
natural name than "initiate" while they IMHO has similar descriptive
value for multi page flow I would prefer the naming as is..
/Daniel
Revisited Proposed Flow Renaming (was Re: [Vote] Controller/Sitemap
integration)
Posted by Marc Portier <mp...@outerthought.org>.
While I was typing this mail Carsten has proposed to release on
the 29th, so let me please restate that I don't want to be in the
way of that release in any way... (so postponing the vote is OK
with me)
seperate from that position I'ld just like to get the show on
stage and not let us run away from the discussion now that we are
getting closer... (I wouldn't mind getting us to a vote soon)
sorry if this approach makes you scizofrenic...
Reinhard Pötz wrote:
> So I'm +1 to release the flow implementation as it is ASAP and discuss
> this again when the second implementation is on the table. As already
> mentioned there will be only littly changes necessary for flow users
> (not more changes than with 2.0 --> 2.1).
>
starting to feel guilty about not having the implementation yet
(Sylvain went at length explaining why we didn't want to do that)
so I jumped into it and set some other stuff asside to get my
nose into the code of o.a.c.components.flow first and maybe get a
better understanding
(please correct me where appropriate)
Current situation:
The delegate from the POV of the sitemap is the Interpreter that
gets called to either callFunction() or handleContinuation().
This Interpreter also has a callback forwardTo() function which
hands over the control back to the sitemap providing the URI of
the selected pipeline to use for publishing the answer...
For convenience of specific InterpreterImpls there is an
AbstractInterpreter one can subclass from, it already maintains a
reference to the ContinuationsManager (see below) and provides
the implementation for the forwardTo() which is most likely to be
similar for all implementations (at least if they want to be
reusing existing publication pipeline components that go look for
the bean and continuation object in the predefined spots)
The ContinuationsManager interface and his sole implementation
ContinuationsManagerImpl manage the lifecycle (create, store for
retrieval and cleanup==invalidate) of the actual WebContinuations.
These WebContinuations in their turn are not in anyway directed
to any implementation, instead they are wrapping whatever
stateful 'user-object' the specific InterpreterImplementation
would like to be stored. (they also allow, for hooking them up
in trees, and they carry their own id, which is the thing that is
showing up in the dynamic URI's of course, and is also the 'key'
by which the ContinuationsManager is perfroming it's lookup)
This makes me understand a number of things
- WebContinuations do not need an intermediate layer or interface
to implement cause they solve the multiple impl issue already the
other way around (wrapping around the so called user-object)
[so please ignore my earlier remark in this area]
- as a consequence the ContinuationManagerImpl is already fully
aware of how to manage the continuations of different
implementations. However they are not *driving* the
handleContinuation(), yet are peacefully under control of the
Interpreter at hand to give back the WebContinuation stored by a
certain id. This is mainly because the Interpreter can then
unwrap the user-object from the WebContinuation, cast it to the
correct subclass, share preparation work in building some
execution context,....
[so unlike what I was thinking out loud earlier: if we are to
have more then one possible Interpreter declared inside one
cocoon instance, then some @type will be required in both
initiate and continue cases to point to the correct InterpreterImpl
Coming back on the renaming from this angle:
-1- FlowState, FlowStateManager, DefaultFlowStateManager *could*
be a replacement for WebContinuation, ContinuationManager and
ContinuationManagerImpl...
but I'm getting quite indefferent on this... the historic
connection between Interpreters and WebContinuations is not
reflected by the code in any way, so it's more in our minds then
anywhere else (maybe realizing this helps us setting it asside)
-2- Interpreter should be changed to FlowProcessor (more sense
then FlowEngine becomes apparent now?) and its methods could make
the transition from
callFunction(String funcName, List params, Environment env)
handleContinuation(String contId, List params, Environment
env)
towards
initiateFlow(String flowId, List params, Environment env)
continueFlow(String contId, List params, Environment env)
which maybe gets mapped back to the
<map:initiate flow="flowId" type="interpreter-name" />
<map:continue flow="contId" type="interpreter-name" />
that was still under discussion somewhat?
-3- What remains open is how to declare more then one active
FlowProcessor, for which I think the lign up with other
components inside Cocoon (like Generators et al.) makes the most
sense, but I'm open for other suggestions here
(off course I assuming that the expressed consensus about
actually allowing this is big enough to consider this additional
change)
what do others think?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Stephan Michels
<snip/>
> But nevertheless, I like most ...
I could write again *my* best way of integrating it but I don't see the
value of delaying the release because of this neverending discussion.
So I'm +1 to release the flow implementation as it is ASAP and discuss
this again when the second implementation is on the table. As already
mentioned there will be only littly changes necessary for flow users
(not more changes than with 2.0 --> 2.1).
Before being off-list for about 10 days I'll summarize the current
status of the flow implementation. Expect a mail soon.
Cheers,
Reinhard
RE: [Vote] Controller/Sitemap integration
Posted by Conal Tuohy <co...@paradise.net.nz>.
Stephan Michels wrote:
> <map:pipeline>
> [...]
> <map:continue type="petshop" id="{1}"/>
> [...]
> </map:pipeline>
I think it's a potential source of confusion to have "id" attributes which
are not of type ID (i.e. they are not unique identifiers of elements in the
sitemap). Of course, I realise that "id" is just an abbreviation for
"identifier", and that it's purely conventional that "id" attributes are of
type ID, but I think we should respect this very common convention because
doing so will lower the cognitive burden for people learning Cocoon flow.
http://www.w3.org/TR/REC-xml#id
Similarly, a newbie might expect a "state-id" attribute to be of type IDREF,
which is a mark against it IMHO. http://www.w3.org/TR/REC-xml#idref
And again, that's why I think "src" would be a poor name for the same
attribute, because an attribute with this name would conventionally contain
a URI. http://www.w3.org/TR/xmlschema-2/#anyURI
That's why I'd prefer any other of the alternative names proposed: state,
from, continue, or flow.
Cheers
Con
RE: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
> > From: Stephan Michels
> >
> > <map:initiate> -> select flow -> <map:flow> \\
> > -> select implementation -> <flow-processor>
> >
> > Ohh moment, what makes the flow component different from
> > other sitemap components? Nothing!
>
> >From a technical POV you are completly right but I share Stefano's idea
> that we should show our users that the flow component is different from
> the sitemap components. So I'm -1 on this.
>
> >
> > <map:components>
> > <map:flow name="petshop" class=
> > "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
> > <reload-scripts>true</reload-scripts>
> > <check-time>4000</check-time>
> > <script src="flow/PetStoreImpl.js"/>
> > <script src="flow/petstore.js"/>
> > </map:flow>
> > <map:components>
>
> ... so I like the new section <map:flows>...</map:flows> more. See the
> reasons above.
Oh yes, I mean
<map:components>
<map:flows>
<map:flow name="petshop" class=
"org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
<reload-scripts>true</reload-scripts>
<check-time>4000</check-time>
<script src="flow/PetStoreImpl.js"/>
<script src="flow/petstore.js"/>
</map:flow>
</map:flows>
<map:components>
like every other components.
> And I think it is FS to determine the implementation
> (org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter) at
> sitemap level.
> Do you have a usecase which makes this necessary? I wrote a lot of JS
> flow scripts and haven't had a need for this yet.
1. Usecase: You don't want to use flows -> remove the flow section
2. Usecase: You have different flows in the same map.
3. Usecase: You use different implementations in the same map.
The fact, that specifying of components in the sitemap is in general
a bad pratice, is another point, but don't want to discuss
here(,perhaps later :))
> > <map:initiate type="petshop" start="addItem"/>
> > <map:continue type="petshop" id="{1}"/>
> >
> > Hey, I love this :)
>
> I think this obscures that a flow processor/engine is used. Of course
> this makes only sense in connection with <map:flows>...</map:flows>.
> Therefore I like following syntax more.
>
> <map:initiate flow="addItem" type="petshop" />
> <map:continue flow="{1}" type="petshop" />
>
> Would you be fine with this?
I thought with @type to combine the implementation(Javascript) and
instance(petstore.js), which I see as practice, which already used
with the other components.
Another way could be
<map:initiate flow="addItem" type="petshop" src="flow/petstore.js/>
<map:continue flow="{1}" type="petshop" src="flow/petstore.js/>
And the flow processor could cache the instance with @src
as key.
But nevertheless, I like most
<map:components>
<map:flows>
<map:flow name="petshop" class=
"org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
<reload-scripts>true</reload-scripts>
<check-time>4000</check-time>
<script src="flow/PetStoreImpl.js"/>
<script src="flow/petstore.js"/>
</map:flow>
</map:flows>
<map:components>
<map:pipeline>
[...]
<map:initiate type="petshop" start="addItem"/>
[...]
</map:pipeline>
<map:pipeline>
[...]
<map:continue type="petshop" id="{1}"/>
[...]
</map:pipeline>
This makes the concept really symmetric to the other
components, and can signal that the continuations
are the successor of the actions.
Stephan.5~
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
> -----Original Message-----
> From: Stephan Michels
>
>
>
> On Fri, 18 Jul 2003, Reinhard Pötz wrote:
>
> >
> > From: Stephan Michels [mailto:stephan@apache.org]
> >
> > > A: V1
> >
> > Why do you want implementation details in the element: <map:flows>
> > ...
> > <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> > <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> > ---
> > </map:flows>
> >
> > I don't think that class or src should be attributes of
> <map:flow/>.
> > It should go into the configuration, shouldn't it?
>
> I you think of Configuration class, you can do both. But you
> are right in the case of validation(which is in the current
> case terrible difficult), the second option is better.
>
> I change my A: V1 to A: V2, okay?
>
> > > B: V2
> > > C: V1 with flow instead of type
> >
> > to use the flow attribute to determine which implementation is used
> > doesn't make really sense to me. Everywhere else the type
> attribute is
> > used. I would use the flow attribute to give the flow
> processor a hint
>
> Which implementation you use is defined in <map:flow>
>
> <map:initiate> -> select flow -> <map:flow> \\
> -> select implementation -> <flow-processor>
>
> Ohh moment, what makes the flow component different from
> other sitemap components? Nothing!
>From a technical POV you are completly right but I share Stefano's idea
that we should show our users that the flow component is different from
the sitemap components. So I'm -1 on this.
>
> <map:components>
> <map:flow name="petshop" class=
> "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
> <reload-scripts>true</reload-scripts>
> <check-time>4000</check-time>
> <script src="flow/PetStoreImpl.js"/>
> <script src="flow/petstore.js"/>
> </map:flow>
> <map:components>
... so I like the new section <map:flows>...</map:flows> more. See the
reasons above.
And I think it is FS to determine the implementation
(org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter) at
sitemap level.
Do you have a usecase which makes this necessary? I wrote a lot of JS
flow scripts and haven't had a need for this yet.
<map:flows>
> <map:flow name="petshop" class=
> "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
> <reload-scripts>true</reload-scripts>
> <check-time>4000</check-time>
> <script src="flow/PetStoreImpl.js"/>
> <script src="flow/petstore.js"/>
> </map:flow>
</map:flows>
>
> <map:initiate type="petshop" start="addItem"/>
> <map:continue type="petshop" id="{1}"/>
>
> Hey, I love this :)
I think this obscures that a flow processor/engine is used. Of course
this makes only sense in connection with <map:flows>...</map:flows>.
Therefore I like following syntax more.
<map:initiate flow="addItem" type="petshop" />
<map:continue flow="{1}" type="petshop" />
Would you be fine with this?
Cheers,
Reinhard
RE: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
>
> From: Stephan Michels [mailto:stephan@apache.org]
>
> > A: V1
>
> Why do you want implementation details in the element:
> <map:flows>
> ...
> <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> ---
> </map:flows>
>
> I don't think that class or src should be attributes of <map:flow/>. It
> should go into the configuration, shouldn't it?
I you think of Configuration class, you can do both. But you are
right in the case of validation(which is in the current case terrible
difficult), the second option is better.
I change my A: V1 to A: V2, okay?
> > B: V2
> > C: V1 with flow instead of type
>
> to use the flow attribute to determine which implementation is used
> doesn't make really sense to me. Everywhere else the type attribute
> is used. I would use the flow attribute to give the flow processor a
> hint
Which implementation you use is defined in <map:flow>
<map:initiate> -> select flow -> <map:flow> \\
-> select implementation -> <flow-processor>
Ohh moment, what makes the flow component different from other
sitemap components? Nothing!
<map:components>
<map:flow name="petshop" class=
"org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
<reload-scripts>true</reload-scripts>
<check-time>4000</check-time>
<script src="flow/PetStoreImpl.js"/>
<script src="flow/petstore.js"/>
</map:flow>
<map:components>
<map:initiate type="petshop" start="addItem"/>
<map:continue type="petshop" id="{1}"/>
Hey, I love this :)
Stephan.
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Stephan Michels [mailto:stephan@apache.org]
> A: V1
Why do you want implementation details in the element:
<map:flows>
...
<map:flow name="java" type="atct" class="org.apache.cocoon...."/>
<map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
---
</map:flows>
I don't think that class or src should be attributes of <map:flow/>. It
should go into the configuration, shouldn't it?
> B: V2
> C: V1 with flow instead of type
to use the flow attribute to determine which implementation is used
doesn't make really sense to me. Everywhere else the type attribute
is used. I would use the flow attribute to give the flow processor a
hint
where he should look for the implementation (either to initialize a
new flow or to continue an existing one).
See B:V5 and C:C7
>
> D: V2
> E: V2
>
> BTW, I think it too early to vote on this. If I must decide
> now, all will be carved in stone. I think we should leave A-C
> as it is for 2.1. And postpone the discussion to the
> post-2.1-era. For my part, I must have first two
> implementations to find more generalized contract, which we
> don't have at this point.
>
> So my vote would like:
> Should we postpone the generalisation to the post-2.1-era,
> and hazard with the consequences, that we maybe change the
> sitemap syntax of a released version of Cocoon?
I think the changes from A to D make sense. For me the big
arguement for generalizing the element names in the sitemap
is not the second implementation but to give people outside
of the Cocoon repository within their own projects the chance
to integrate their controllers without having to write a
wrapper within the existing JS interpreter.
So if we find a consensus on A to D we should do the changes.
Cheers,
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
On Thu, 17 Jul 2003, Joerg Heinicke wrote:
> Reinhard Pötz wrote:
> > As I have been confused by all those suggestions you can find a summary
> > here:
> > http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
>
> Cool summary, really helps a lot. And here the cool voting matrix :)
>
>
> | A | B | C | D | E |
> ----|-------|-------|-------|-------|-------|
> | | | | | |
> V1 | -1 | +0 | +0 | +.5 | +1 |
> | | | | | |
> V2 | +1 | -1 | -0 | +.5 | -1 |
> | | | | | |
> V3 | ?? | +.5 | -1 | \ | \ |
> | | | | | |
> V4 | \ | -1 | -0 | \ | \ |
> | | | | | |
> V5 | \ | +1 | +.5 | \ | \ |
> | | | | | |
> V6 | \ | \ | -1 | \ | \ |
> | | | | | |
> V7 | \ | \ | +1 | \ | \ |
> | | | | | |
> ----|-------|-------|-------|-------|-------|
>
>
> What is the difference between A V1 and A V2? Only the <map:flows/>? And
> what does it mean?
>
> B V5 was missing. From Marc's answer I guess he meant this, but chooses V1.
Don't you think that this makes the voting really difficult ;-)
A: V1
B: V2
C: V1 with flow instead of type
D: V2
E: V2
BTW, I think it too early to vote on this. If I must decide now,
all will be carved in stone. I think we should leave A-C as it is
for 2.1. And postpone the discussion to the post-2.1-era.
For my part, I must have first two implementations to find
more generalized contract, which we don't have at this point.
So my vote would like:
Should we postpone the generalisation to the post-2.1-era,
and hazard with the consequences, that we maybe change the
sitemap syntax of a released version of Cocoon?
+1
Stephan.
Re: [Vote] Controller/Sitemap integration
Posted by Joerg Heinicke <jo...@gmx.de>.
Reinhard Pötz wrote:
> As I have been confused by all those suggestions you can find a summary
> here:
> http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
Cool summary, really helps a lot. And here the cool voting matrix :)
| A | B | C | D | E |
----|-------|-------|-------|-------|-------|
| | | | | |
V1 | -1 | +0 | +0 | +.5 | +1 |
| | | | | |
V2 | +1 | -1 | -0 | +.5 | -1 |
| | | | | |
V3 | ?? | +.5 | -1 | \ | \ |
| | | | | |
V4 | \ | -1 | -0 | \ | \ |
| | | | | |
V5 | \ | +1 | +.5 | \ | \ |
| | | | | |
V6 | \ | \ | -1 | \ | \ |
| | | | | |
V7 | \ | \ | +1 | \ | \ |
| | | | | |
----|-------|-------|-------|-------|-------|
What is the difference between A V1 and A V2? Only the <map:flows/>? And
what does it mean?
B V5 was missing. From Marc's answer I guess he meant this, but chooses V1.
Joerg
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
As I have been confused by all those suggestions you can find a summary
here:
http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
After the discussion and all your opinions I would prefer:
Integrating the flow processor/engine:
--------------------------------------
<map:flows>
<map:flow name="js" type="javascript">
<script src="flow/PetStoreImpl.js"/>
<script src="flow/petstore.js"/>
</map:flow>
<map:flow name="java" type="atct">
<class src="org.apache.cocoon...."/>
</map:flow>
<map:flow name="fsm" type="fsm">
<blabla src="descriptors/fsm.xml"/>
</map:flow>
</map:flows>
... in order to be coherent. Please note that the flow
element only has name and type. All other things
are IMO part of the configuration (... someone proposed
to have a class attribute --> that's useless for e.g. the
JavaScript implementation)
Call a flow the first time:
---------------------------
<map:call flow="[yourFlow]" type="js">
<map:parameter name="x" value="y"/>
</map:call>
I prefer "call" because this makes the most sense for me.
But I'm +0.5 with initialize. And I like the word flow otherwise
it is totally obscured that it is part of the flow implementation.
Please note again that we need a "type" attribute again.
... and I don't like src because src means something different
everywhere in Cocoon (something that can be called using the
SoureResolver ...)
Continue a flow:
----------------
<map:continue id="..." type="js">
<map:parameter name="x" value="y"/>
</map:continue>
Again, I don't like src (see reasons above) and we need the type
attribute.
Component declaration:
----------------------
I'm indifferent on this ...
--------------------------------------------------------------------
And here a completly new alternatvie (at least for this discussion:)
<map:flow call="" type="js" >
<map:parameter name="x" value="y"/>
</map:flow>
and
<map:flow continue="" type="java" >
<map:parameter name="x" value="y"/>
</map:flow>
This makes for me the greatest sense because you still know that you
deal
with flow and this is not obscured by call, continue, initialize or
whatever.
Perhaps, this would make a renaming of the declaration in
<map:flows>...</map:flows>
necessary.
What do you think?
Cheers,
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
On Thu, 17 Jul 2003, Joerg Heinicke wrote:
> Stephan Michels wrote:
>
> > <map:flows>
> > <map:flow name="js" type="javascript">
> > <script src="flow/PetStoreImpl.js"/>
> > <script src="flow/petstore.js"/>
> > </map:flow>
> > <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> > <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> > </map:flows>
> >
> > So this will be coherent with the other objects.
>
> Which leads the sentence "This reflects that the flow is not a *usual*
> sitemap resource but something else." ad absurdum :)
Okay, but how should a different implemenation look like?
> >> [B] The controller is called by:
> >>
> >> <map:call flow="[yourFlow]">
> >> <map:parameter name="x" value="y"/>
> >> </map:call>
> >
> >
> > Seems fine, an alternative will be
> >
> > <map:initiate flow="js" call="[Javascript function]">
> > <map:parameter name="x" value="y"/>
> > </map:initiate>
> >
> > <map:initiate type="java" call="[Java method]">
> > <map:parameter name="x" value="y"/>
> > </map:call>
> >
> > <map:initiate type="fsm" call="[Name of state]">
> > <map:parameter name="x" value="y"/>
> > </map:initiate>
> >
> > I like the combination of initiate/continue
>
> initiate/continue is ok, but what about keeping syntax of all sitemap
> objects using @type and @src:
>
> <map:initiate type="java" src="[Java method]"/>
>
> Or is it to far away from the sense or even misleading?
+1
> >> [C] A state of the controller is called by:
> >>
> >> <map:call state="">
> >> <map:parameter name="x" value="y"/>
> >> </map:call>
> >
> >
> > We don't call states in this sense. We continue
> > a continuation ;-)
> > I guess <map:continue continuation="{1}"/> is bad.
> >
> > <map:continue src="{1}"/>
> > or
> > <map:continue id="{1}"/>
>
> Same like above, so I prefer @src.
+1
> >> - rename "WebContinuation" to "FlowState", and accordingly
> >> "WebContinuationManager" to "FlowStateManager".
>
> Here I prefer the States for the reasons Marc provided, so +1 here.
+0
> Conal Tuohy wrote:
> > What about <map:continue from="..."/>
>
> Hmm, I don't really like it. We don't need an English sentence :)
>
> Otherwise you could also change to <map:generate from="foo.xml"/>,
> <map:transform with="bar.xsl"/> and <map:serialize as="html"/>. @type
> and @src is a good abstraction IMO.
I think in the same direction, @src and @type are more intuitive.
Stephan.
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Joerg Heinicke
> Because of this upcomming naming discussion I guess the vote
> started to
> early.
Unfortunatly you are right. After the "balkanization" discussion I
thought that the people here are satisfied with Marc's/Sylvain's
proposal. In the meantime I'm really tired of waiting for the 2.1
release (yes, I want to use it in production --> I don't have problems
with CVS versions but many customers have!) ... therefore my try with
the vote ...
This was also the reason why I voted +0. Those changes would have been
possible for a later release and the migration would have been very
easy.
> First all alternatives should be known. But the
> additions Stephan
> provided make sense (see inline).
>
> Stephan Michels wrote:
>
> >> [A] The "Cocoon Advanced Control Flow" provides a
> controller that is
> >> linked into the sitemap (as **child element** of <map:sitemap
> >>.../>:
> >>
> >> <map:flow type="[yourEngine]">
> >> [configuration]
> >> </map:flow>
> >>
> >> This reflects that the flow is not a *usual* sitemap
> resource but
> >> something else.
> >
> >
> > The point, which irritates me, is that you don't have a
> identifier to
> > address the script/whatever.
> >
> > So my favorite choise will be
> >
> > <map:flows>
> > <map:flow name="js" type="javascript">
> > <script src="flow/PetStoreImpl.js"/>
> > <script src="flow/petstore.js"/>
> > </map:flow>
> > <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> > <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> > </map:flows>
> >
> > So this will be coherent with the other objects.
>
> Which leads the sentence "This reflects that the flow is not
> a *usual*
> sitemap resource but something else." ad absurdum :)
I'm -0 on this changes to my proposal (see Jörg's argument)
>
> >> [B] The controller is called by:
> >>
> >> <map:call flow="[yourFlow]">
> >> <map:parameter name="x" value="y"/>
> >> </map:call>
> >
> >
> > Seems fine, an alternative will be
> >
> > <map:initiate flow="js" call="[Javascript function]">
> <map:parameter
> > name="x" value="y"/> </map:initiate>
> >
> > <map:initiate type="java" call="[Java method]"> <map:parameter
> > name="x" value="y"/> </map:call>
> >
> > <map:initiate type="fsm" call="[Name of state]"> <map:parameter
> > name="x" value="y"/> </map:initiate>
> >
> > I like the combination of initiate/continue
>
> initiate/continue is ok, but what about keeping syntax of all sitemap
> objects using @type and @src:
>
> <map:initiate type="java" src="[Java method]"/>
>
> Or is it to far away from the sense or even misleading?
>
> >> [C] A state of the controller is called by:
> >>
> >> <map:call state="">
> >> <map:parameter name="x" value="y"/>
> >> </map:call>
> >
> >
> > We don't call states in this sense. We continue
> > a continuation ;-)
> > I guess <map:continue continuation="{1}"/> is bad.
> >
> > <map:continue src="{1}"/>
> > or
> > <map:continue id="{1}"/>
>
> Same like above, so I prefer @src.
>
> >> [D] All flow interpreters[3] are Avalon components and declared
> >> in the cocoon.xonf:
> >>
> >> <flow-engine default="[yourController]" logger="[yourLogger]">
> >> ...
> >> </flow-engine>
> >
> >
> > +1, except the name, see next.
> >
> >
> >> [E] Changes in the current Javascript implementation:
> >> - rename "Interpreter" to "FlowEngine",
> >
> >
> > Again, to be coherent my favorite is
> > <flow-processor> like <xslt-processor> and <xpath-processor>, or
> > treeprocessor.
>
> flow-engine vs. flow-processor - I don't know ...
>
> >> - rename "WebContinuation" to "FlowState", and accordingly
> >> "WebContinuationManager" to "FlowStateManager".
>
> Here I prefer the States for the reasons Marc provided, so +1 here.
>
> > Yes, the Continuation represents a state, but to make a clear
> > difference as a new concept, I think 'Continuation' is
> accurate. But
> > 'Web..'?!
> >
> > - rename "WebContinuation" to "Continuation", and accordingly
> > "WebContinuationManager" to "ContinuationManager".
>
> If not states, but continuations at least remove 'Web' => +1
>
> Conal Tuohy wrote:
> > What about <map:continue from="..."/>
>
> Hmm, I don't really like it. We don't need an English sentence :)
>
> Otherwise you could also change to <map:generate from="foo.xml"/>,
> <map:transform with="bar.xsl"/> and <map:serialize as="html"/>. @type
> and @src is a good abstraction IMO.
>
> Joerg
>
Re: [Vote] Controller/Sitemap integration
Posted by Joerg Heinicke <jo...@gmx.de>.
Because of this upcomming naming discussion I guess the vote started to
early. First all alternatives should be known. But the additions Stephan
provided make sense (see inline).
Stephan Michels wrote:
>> [A] The "Cocoon Advanced Control Flow" provides a controller that is
>> linked into the sitemap (as **child element** of <map:sitemap
>>.../>:
>>
>> <map:flow type="[yourEngine]">
>> [configuration]
>> </map:flow>
>>
>> This reflects that the flow is not a *usual* sitemap resource but
>> something else.
>
>
> The point, which irritates me, is that you don't have a identifier
> to address the script/whatever.
>
> So my favorite choise will be
>
> <map:flows>
> <map:flow name="js" type="javascript">
> <script src="flow/PetStoreImpl.js"/>
> <script src="flow/petstore.js"/>
> </map:flow>
> <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> </map:flows>
>
> So this will be coherent with the other objects.
Which leads the sentence "This reflects that the flow is not a *usual*
sitemap resource but something else." ad absurdum :)
>> [B] The controller is called by:
>>
>> <map:call flow="[yourFlow]">
>> <map:parameter name="x" value="y"/>
>> </map:call>
>
>
> Seems fine, an alternative will be
>
> <map:initiate flow="js" call="[Javascript function]">
> <map:parameter name="x" value="y"/>
> </map:initiate>
>
> <map:initiate type="java" call="[Java method]">
> <map:parameter name="x" value="y"/>
> </map:call>
>
> <map:initiate type="fsm" call="[Name of state]">
> <map:parameter name="x" value="y"/>
> </map:initiate>
>
> I like the combination of initiate/continue
initiate/continue is ok, but what about keeping syntax of all sitemap
objects using @type and @src:
<map:initiate type="java" src="[Java method]"/>
Or is it to far away from the sense or even misleading?
>> [C] A state of the controller is called by:
>>
>> <map:call state="">
>> <map:parameter name="x" value="y"/>
>> </map:call>
>
>
> We don't call states in this sense. We continue
> a continuation ;-)
> I guess <map:continue continuation="{1}"/> is bad.
>
> <map:continue src="{1}"/>
> or
> <map:continue id="{1}"/>
Same like above, so I prefer @src.
>> [D] All flow interpreters[3] are Avalon components and declared
>> in the cocoon.xonf:
>>
>> <flow-engine default="[yourController]" logger="[yourLogger]">
>> ...
>> </flow-engine>
>
>
> +1, except the name, see next.
>
>
>> [E] Changes in the current Javascript implementation:
>> - rename "Interpreter" to "FlowEngine",
>
>
> Again, to be coherent my favorite is
> <flow-processor> like <xslt-processor> and <xpath-processor>, or
> treeprocessor.
flow-engine vs. flow-processor - I don't know ...
>> - rename "WebContinuation" to "FlowState", and accordingly
>> "WebContinuationManager" to "FlowStateManager".
Here I prefer the States for the reasons Marc provided, so +1 here.
> Yes, the Continuation represents a state, but to make a clear
> difference as a new concept, I think 'Continuation' is accurate.
> But 'Web..'?!
>
> - rename "WebContinuation" to "Continuation", and accordingly
> "WebContinuationManager" to "ContinuationManager".
If not states, but continuations at least remove 'Web' => +1
Conal Tuohy wrote:
> What about <map:continue from="..."/>
Hmm, I don't really like it. We don't need an English sentence :)
Otherwise you could also change to <map:generate from="foo.xml"/>,
<map:transform with="bar.xsl"/> and <map:serialize as="html"/>. @type
and @src is a good abstraction IMO.
Joerg
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Christopher Oliver wrote:
>
> Marc Portier wrote:
>
> <snip>
>
>>
>>
>> Confusing comes from what we understand under 'Continuation'
>>
>> 1/ Sylvain's meaning when he states other impl should be possible:
>> The word continuation has been associated to this notion of having
>> frozen execution stacks that can be picked up again.
>>
>> I guess this understanding goes back to how Christian Queinnec started
>> using the word in his paper (haven't read it and the link from
>> http://www.webweavertech.com/ovidiu/weblog/archives/000179.html is dead)
>
>
>
> Try http://citeseer.nj.nec.com/476568.html.
>
>
many thx, harvested 11 png files, will print out for careful
background reading
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Vote] Controller/Sitemap integration
Posted by Christopher Oliver <re...@verizon.net>.
Marc Portier wrote:
<snip>
>
>
> Confusing comes from what we understand under 'Continuation'
>
> 1/ Sylvain's meaning when he states other impl should be possible:
> The word continuation has been associated to this notion of having
> frozen execution stacks that can be picked up again.
>
> I guess this understanding goes back to how Christian Queinnec started
> using the word in his paper (haven't read it and the link from
> http://www.webweavertech.com/ovidiu/weblog/archives/000179.html is dead)
Try http://citeseer.nj.nec.com/476568.html.
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
> IMHO:
> I think the verb 'continue' catches a broader consensus:
> interactions or use cases are indeed just started(initiated) or
> continued, and this also captures the relation the sitemap has to
> this.
> The noun 'continuation' has gotten a ring of being tied to a
> interpreted-language implementation.
>
>
> The inflected confusion from the history of the 'noun' adds up to
> some case against using it IMHO.
+1
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
Geoff Howard wrote:
> Stephan Michels wrote:
>
> ...
>
>> We don't call states in this sense. We continue
>> a continuation ;-)
>> I guess <map:continue continuation="{1}"/> is bad.
>>
>> <map:continue src="{1}"/>
>> or
>> <map:continue id="{1}"/>
>
>
> ...
>
>>> - rename "WebContinuation" to "FlowState", and accordingly
>>> "WebContinuationManager" to "FlowStateManager".
>>
>>
>> Yes, the Continuation represents a state, but to make a clear
>> difference as a new concept, I think 'Continuation' is accurate.
>> But 'Web..'?!
>>
>> - rename "WebContinuation" to "Continuation", and accordingly
>> "WebContinuationManager" to "ContinuationManager".
>
>
> I guess I'm a little confused at the general agreement on this naming
> using "continuation". I thought I was hearing in Sylvain's original RT
> that continuations may not be the only implementation. I don't have a
> problem with any of the new names suggested which is why I'm not really
> adding anything to the discussion at this point, but I don't want to
> have the discussion miss this point.
>
> Could someone who resonates with the vision for these other potential
> (non javascript-with-continuations) implementations of flow comment on
> this quickly? If it satisfies you, I have no personal objection.
>
My shy attempt:
Confusing comes from what we understand under 'Continuation'
1/ Sylvain's meaning when he states other impl should be possible:
The word continuation has been associated to this notion of
having frozen execution stacks that can be picked up again.
I guess this understanding goes back to how Christian Queinnec
started using the word in his paper (haven't read it and the link
from
http://www.webweavertech.com/ovidiu/weblog/archives/000179.html
is dead)
2/ Stephan's meaning when he states: "it is that what we continue"
he's backed up by http://m-w.com
Function: noun
Date: 14th century
1 : the act or fact of continuing in or the prolongation of a
state or activity
2 : resumption after an interruption
3 : something that continues , increases, or adds
IMHO:
I think the verb 'continue' catches a broader consensus:
interactions or use cases are indeed just started(initiated) or
continued, and this also captures the relation the sitemap has to
this.
The noun 'continuation' has gotten a ring of being tied to a
interpreted-language implementation.
The inflected confusion from the history of the 'noun' adds up to
some case against using it IMHO.
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
> > Could someone who resonates with the vision for these other potential
> > (non javascript-with-continuations) implementations of flow comment on
> > this quickly? If it satisfies you, I have no personal objection.
>
> Here you have four different states:
>
> state 0:
> x = "bla";
> sendPage("first")
>
> state 1:
> y = "blub";
> sendPage("choice")
>
> state 2:
> y = "yagh";
> sendPage("choice")
>
> state 3:
> sendPage("last")
>
> And several transitions:
>
> state 0 -> state 1 if answer = sucess
> state 0 -> state 2 otherwise
> state 1 -> state 3
> state 2 -> state 3
>
> So, here we have a DFA.
I little correction, you have at least currently a
deterministic push-down automata (DPDA), or in the
case of Javascript a turing-complete automaton.
So, the current state of execution(continuation?!)
involves the stack.
Nevertheless, you can apply the continuation
concept to a DFA.
Stephan.
RE: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
> > So, here we have a DFA.
> >
> > The 'continuation' means to freeze the current state of the
> > execution. The benefit of the continuations are that you have
> > a history of the states, which you had traversed. And like a
> > backtracking algorithm, you can go back to a previous state
> > and follow another route.
> >
> > So, the answer is, it is sufficient to have the 'history of
> > states' to take a new name like 'continuation' instead of
> > simple 'state'? I think yes.
>
> Sorry, I don't think so. I'm not a specialist in Scheme but I think
> there is a concept behind continuations and the general use for all
> controllers in Cocoon would be misleading.
Okay, to be sure I googled around, and found:
http://www.cs.utexas.edu/users/wilson/schintro/schintro_141.html
> call-with-current-continuation
>
> call-with-current-continuation is a very powerful control construct,
> which can be used to create more conventional control constructs, like catch and
> throw in Lisp (or setjmp and longjmp in C), or coroutines, and many
> more. It is extremely powerful because it allows a program to manipulate its own
> control "stack" so that procedure calls and returns needn't follow the
> normal depth-first textual call ordering.
>
> Recall that we said [ WHERE? ] that Scheme's equivalent of an activation
> stack is really a chain of partial continuations (suspension records),
> and this chain is known as a full continuation. And since continuations are
> immutable, they usually form a tree reflecting the call graph (actually,
> only the non-tail calls). Normally, the parts of this tree that are not
> in the current continuation chain are garbage, and can be garbage
> collected.
>
> If you take a pointer to the current continuation, and put it in a live
> variable or data structure, however, then that continuation chain will
> remain live and not be garbage collected. That is, you can "capture" the
> current state of the stack.
It is not exactly what I want, but the core statement is
'A continuation is chain of partial continuations, or captured
states of the stack'
I think :) But maybe I'm wrong?!
It's funny, but the whole continuation concept reminds me of the Tomita
algorithm for simulating a GLR parser, which I currently working on ;-)
http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps
Stephan.
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Stephan Michels
> On Thu, 17 Jul 2003, Geoff Howard wrote:
>
> > Stephan Michels wrote:
> >
> > >> - rename "WebContinuation" to "FlowState", and accordingly
> > >> "WebContinuationManager" to "FlowStateManager".
> > >
> > > Yes, the Continuation represents a state, but to make a clear
> > > difference as a new concept, I think 'Continuation' is
> accurate. But
> > > 'Web..'?!
> > >
> > > - rename "WebContinuation" to "Continuation", and accordingly
> > > "WebContinuationManager" to "ContinuationManager".
> >
> > I guess I'm a little confused at the general agreement on
> this naming
> > using "continuation". I thought I was hearing in Sylvain's
> original
> > RT that continuations may not be the only implementation. I don't
> > have a problem with any of the new names suggested which is why I'm
> > not really adding anything to the discussion at this point, but I
> > don't want to have the discussion miss this point.
> >
> > Could someone who resonates with the vision for these other
> potential
> > (non javascript-with-continuations) implementations of flow
> comment on
> > this quickly? If it satisfies you, I have no personal objection.
>
> A little example:
>
> function myFunc()
> {
> x = "bla";
>
> sendPageAndWait("first")
>
> if (answer = sucess)
>
> y = "blub";
> sendPageAndWait("choice")
>
> else
>
> y = "yagh";
> sendPageAndWait("choice")
>
> sendPageAndWait("last")
> }
>
> Here you have four different states:
>
> state 0:
> x = "bla";
> sendPage("first")
>
> state 1:
> y = "blub";
> sendPage("choice")
>
> state 2:
> y = "yagh";
> sendPage("choice")
>
> state 3:
> sendPage("last")
>
> And several transitions:
>
> state 0 -> state 1 if answer = sucess
> state 0 -> state 2 otherwise
> state 1 -> state 3
> state 2 -> state 3
>
> So, here we have a DFA.
>
> The 'continuation' means to freeze the current state of the
> execution. The benefit of the continuations are that you have
> a history of the states, which you had traversed. And like a
> backtracking algorithm, you can go back to a previous state
> and follow another route.
>
> So, the answer is, it is sufficient to have the 'history of
> states' to take a new name like 'continuation' instead of
> simple 'state'? I think yes.
Sorry, I don't think so. I'm not a specialist in Scheme but I think
there is a concept behind continuations and the general use for all
controllers in Cocoon would be misleading.
Reinhard
Re: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
On Thu, 17 Jul 2003, Geoff Howard wrote:
> Stephan Michels wrote:
>
> >> - rename "WebContinuation" to "FlowState", and accordingly
> >> "WebContinuationManager" to "FlowStateManager".
> >
> > Yes, the Continuation represents a state, but to make a clear
> > difference as a new concept, I think 'Continuation' is accurate.
> > But 'Web..'?!
> >
> > - rename "WebContinuation" to "Continuation", and accordingly
> > "WebContinuationManager" to "ContinuationManager".
>
> I guess I'm a little confused at the general agreement on this naming
> using "continuation". I thought I was hearing in Sylvain's original RT
> that continuations may not be the only implementation. I don't have a
> problem with any of the new names suggested which is why I'm not really
> adding anything to the discussion at this point, but I don't want to
> have the discussion miss this point.
>
> Could someone who resonates with the vision for these other potential
> (non javascript-with-continuations) implementations of flow comment on
> this quickly? If it satisfies you, I have no personal objection.
A little example:
function myFunc()
{
x = "bla";
sendPageAndWait("first")
if (answer = sucess)
y = "blub";
sendPageAndWait("choice")
else
y = "yagh";
sendPageAndWait("choice")
sendPageAndWait("last")
}
Here you have four different states:
state 0:
x = "bla";
sendPage("first")
state 1:
y = "blub";
sendPage("choice")
state 2:
y = "yagh";
sendPage("choice")
state 3:
sendPage("last")
And several transitions:
state 0 -> state 1 if answer = sucess
state 0 -> state 2 otherwise
state 1 -> state 3
state 2 -> state 3
So, here we have a DFA.
The 'continuation' means to freeze the current state of the execution.
The benefit of the continuations are that you have a history
of the states, which you had traversed. And like a backtracking
algorithm, you can go back to a previous state and follow another
route.
So, the answer is, it is sufficient to have the 'history of states'
to take a new name like 'continuation' instead of simple 'state'?
I think yes.
Stephan.
Re: [Vote] Controller/Sitemap integration
Posted by Geoff Howard <co...@leverageweb.com>.
Stephan Michels wrote:
...
> We don't call states in this sense. We continue
> a continuation ;-)
> I guess <map:continue continuation="{1}"/> is bad.
>
> <map:continue src="{1}"/>
> or
> <map:continue id="{1}"/>
...
>> - rename "WebContinuation" to "FlowState", and accordingly
>> "WebContinuationManager" to "FlowStateManager".
>
> Yes, the Continuation represents a state, but to make a clear
> difference as a new concept, I think 'Continuation' is accurate.
> But 'Web..'?!
>
> - rename "WebContinuation" to "Continuation", and accordingly
> "WebContinuationManager" to "ContinuationManager".
I guess I'm a little confused at the general agreement on this naming
using "continuation". I thought I was hearing in Sylvain's original RT
that continuations may not be the only implementation. I don't have a
problem with any of the new names suggested which is why I'm not really
adding anything to the discussion at this point, but I don't want to
have the discussion miss this point.
Could someone who resonates with the vision for these other potential
(non javascript-with-continuations) implementations of flow comment on
this quickly? If it satisfies you, I have no personal objection.
Geoff
voting rights (Was: [Vote] Controller/Sitemap integration)
Posted by David Crossley <cr...@indexgeo.com.au>.
Marc Portier wrote:
> I don't have a vote, but I have been somewhat connected to this
> thread so I thought I'ld speek up anyway...
<snip/>
Hey, Marc and Conal and anyone else. In this community you *do* have
a vote. The opinion of all developers is valued. The only difference
is that the vote of committers is considered to be binding.
http://incubator.apache.org/drafts/voting.html
--David
Re: [Vote] Controller/Sitemap integration
Posted by Marc Portier <mp...@outerthought.org>.
I don't have a vote, but I have been somewhat connected to this
thread so I thought I'ld speek up anyway...
As for the proposal Sylvain and I uttered originally I would
consider the discussion we had on the topic after Sylvain's post
to direct more (but not completely) into the naming-proposals
Stephan is introducing here...
The following might seem like nagging but I do share Sylvain's
eagerness to get names really right, so I'm wide open for other
alternatives and views...
Stephan Michels wrote:
>
> If I think on different implementations for the flow,
> the names are not every intuitive, IHMO.
>
> So, can I offer some alternatives?
>
> On Wed, 16 Jul 2003, Reinhard Pötz wrote:
>
>
>> [A] The "Cocoon Advanced Control Flow" provides a controller that is
>> linked into the sitemap (as **child element** of <map:sitemap
>>.../>:
>>
>> <map:flow type="[yourEngine]">
>> [configuration]
>> </map:flow>
>>
>> This reflects that the flow is not a *usual* sitemap resource but
>> something else.
>
>
> The point, which irritates me, is that you don't have a identifier
> to address the script/whatever.
>
> So my favorite choise will be
>
> <map:flows>
> <map:flow name="js" type="javascript">
> <script src="flow/PetStoreImpl.js"/>
> <script src="flow/petstore.js"/>
> </map:flow>
> <map:flow name="java" type="atct" class="org.apache.cocoon...."/>
> <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> </map:flows>
>
> So this will be coherent with the other objects.
>
and it makes perfect sense after the recent discussions
it does go a step further and assumes we allow for more then one
flow impl to be active at any given time
not needing to choose one impl for the complete cocoon webapp is
still something different then making sure that implementations
can be swapped (we had a consensus on the latter, not yet on the
first)
but again, it makes sense all the way and IMHO assures more
easily for a seemless integration of what is around (and thus
making sure more of the 'related' issues will be handled in equal
ways, making the different impl more 'alligning' then 'competing')
>
>> [B] The controller is called by:
>>
>> <map:call flow="[yourFlow]">
>> <map:parameter name="x" value="y"/>
>> </map:call>
>
>
> Seems fine, an alternative will be
>
> <map:initiate flow="js" call="[Javascript function]">
> <map:parameter name="x" value="y"/>
> </map:initiate>
>
> <map:initiate type="java" call="[Java method]">
> <map:parameter name="x" value="y"/>
> </map:call>
>
> <map:initiate type="fsm" call="[Name of state]">
> <map:parameter name="x" value="y"/>
> </map:initiate>
>
> I like the combination of initiate/continue
>
yes, I stated this in another thread, looking at it from the POV
of the sitemap there are two kinds of URI's:
1/ the ones that start/initiate a use case (of which the state is
managed at the server side)
2/ the dynamic ones that point to states that can continue the
process
>
>> [C] A state of the controller is called by:
>>
>> <map:call state="">
>> <map:parameter name="x" value="y"/>
>> </map:call>
>
>
> We don't call states in this sense. We continue
> a continuation ;-)
actually I think we continue with the 'use-case'
or we continue the 'interaction'
> I guess <map:continue continuation="{1}"/> is bad.
>
> <map:continue src="{1}"/>
> or
> <map:continue id="{1}"/>
>
Still <map:continue state-id=".." /> might make sense as well?
>> [D] All flow interpreters[3] are Avalon components and declared
>> in the cocoon.xonf:
>>
>> <flow-engine default="[yourController]" logger="[yourLogger]">
>> ...
>> </flow-engine>
>
>
> +1, except the name, see next.
>
>
>> [E] Changes in the current Javascript implementation:
>> - rename "Interpreter" to "FlowEngine",
>
>
> Again, to be coherent my favorite is
> <flow-processor> like <xslt-processor> and <xpath-processor>, or
> treeprocessor.
>
quite indifferent here, since processor is still not catching it
completely IMHO, but I don't have a better alternative yet :-(
>
>> - rename "WebContinuation" to "FlowState", and accordingly
>> "WebContinuationManager" to "FlowStateManager".
>
>
> Yes, the Continuation represents a state, but to make a clear
> difference as a new concept, I think 'Continuation' is accurate.
> But 'Web..'?!
>
I think there is two things here: interface and current
implementation.
we should get the correct name for the abstract thing, but the
WebContinuation could keep on existing as the
flow-script-js-continuation thingy that just implements that
(although some reference to js in that name would make more sense
then?)
I still like FlowState in this context... as I said above we
continue with the use case or interaction (rather then 'the
continuation')... the reason why we can do that is because there
is server side State of the Flow maintained for the current point
in that process...
(I know State sounds like something 'passive' while the
continue-responsibility it has points out some 'activity'... note
however that the Flow-prefix makes up for that, and that the
classic 'State' pattern suffers from the same, so some of us
might be used to it)
> - rename "WebContinuation" to "Continuation", and accordingly
> "WebContinuationManager" to "ContinuationManager".
>
>
> Thoughts?
>
> Stephan Michels.
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [Vote] Controller/Sitemap integration
Posted by Stephan Michels <st...@apache.org>.
If I think on different implementations for the flow,
the names are not every intuitive, IHMO.
So, can I offer some alternatives?
On Wed, 16 Jul 2003, Reinhard Pötz wrote:
> [A] The "Cocoon Advanced Control Flow" provides a controller that is
> linked into the sitemap (as **child element** of <map:sitemap
> .../>:
>
> <map:flow type="[yourEngine]">
> [configuration]
> </map:flow>
>
> This reflects that the flow is not a *usual* sitemap resource but
> something else.
The point, which irritates me, is that you don't have a identifier
to address the script/whatever.
So my favorite choise will be
<map:flows>
<map:flow name="js" type="javascript">
<script src="flow/PetStoreImpl.js"/>
<script src="flow/petstore.js"/>
</map:flow>
<map:flow name="java" type="atct" class="org.apache.cocoon...."/>
<map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
</map:flows>
So this will be coherent with the other objects.
>
> [B] The controller is called by:
>
> <map:call flow="[yourFlow]">
> <map:parameter name="x" value="y"/>
> </map:call>
Seems fine, an alternative will be
<map:initiate flow="js" call="[Javascript function]">
<map:parameter name="x" value="y"/>
</map:initiate>
<map:initiate type="java" call="[Java method]">
<map:parameter name="x" value="y"/>
</map:call>
<map:initiate type="fsm" call="[Name of state]">
<map:parameter name="x" value="y"/>
</map:initiate>
I like the combination of initiate/continue
> [C] A state of the controller is called by:
>
> <map:call state="">
> <map:parameter name="x" value="y"/>
> </map:call>
We don't call states in this sense. We continue
a continuation ;-)
I guess <map:continue continuation="{1}"/> is bad.
<map:continue src="{1}"/>
or
<map:continue id="{1}"/>
> [D] All flow interpreters[3] are Avalon components and declared
> in the cocoon.xonf:
>
> <flow-engine default="[yourController]" logger="[yourLogger]">
> ...
> </flow-engine>
+1, except the name, see next.
>
> [E] Changes in the current Javascript implementation:
> - rename "Interpreter" to "FlowEngine",
Again, to be coherent my favorite is
<flow-processor> like <xslt-processor> and <xpath-processor>, or
treeprocessor.
> - rename "WebContinuation" to "FlowState", and accordingly
> "WebContinuationManager" to "FlowStateManager".
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
- rename "WebContinuation" to "Continuation", and accordingly
"WebContinuationManager" to "ContinuationManager".
Thoughts?
Stephan Michels.
RE: [Vote] Controller/Sitemap integration
Posted by Reinhard Pötz <re...@gmx.net>.
From: Reinhard Pötz
> [A] The "Cocoon Advanced Control Flow" provides a controller that is
> linked into the sitemap (as **child element** of <map:sitemap
> .../>:
>
> <map:flow type="[yourEngine]">
> [configuration]
> </map:flow>
>
> This reflects that the flow is not a *usual* sitemap
> resource but
> something else.
>
>
> [B] The controller is called by:
>
> <map:call flow="[yourFlow]">
> <map:parameter name="x" value="y"/>
> </map:call>
>
>
> [C] A state of the controller is called by:
>
> <map:call state="">
> <map:parameter name="x" value="y"/>
> </map:call>
>
>
> [D] All flow interpreters[3] are Avalon components and declared
> in the cocoon.xonf:
>
> <flow-engine default="[yourController]" logger="[yourLogger]">
> ...
> </flow-engine>
>
>
> [E] Changes in the current Javascript implementation:
> - rename "Interpreter" to "FlowEngine",
> - rename "WebContinuation" to "FlowState", and accordingly
> "WebContinuationManager" to "FlowStateManager".
>
>
> Please cast your votes!
I'm +0 on all items.
Cheers,
Reinhard