cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [Vote] Controller/Sitemap integration
Date Thu, 17 Jul 2003 21:11:06 GMT


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


Mime
View raw message