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
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
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
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
-Original Message-
From: Stephan Michels
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
From: Stephan Michels [mailto:[EMAIL PROTECTED]
A: V1
Why do you want implementation details in the element: map:flows
...
map:flow name=java type=atct
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
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
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
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
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
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
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
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
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
From: Marc Portier [mailto:[EMAIL PROTECTED]
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
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 |
Reinhard Pötz wrote:
From: Marc Portier [mailto:[EMAIL PROTECTED]
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
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
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
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
Marc Portier wrote:
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...
I don't have a vote either :-) but I agree - names are a very important detail, so
I'll stick my nose in...
[C] A
21 matches
Mail list logo