cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: SoC between flow and sitemap
Date Tue, 20 May 2003 08:12:31 GMT


Stefano Mazzocchi wrote:
> on 5/19/03 2:34 PM Marc Portier wrote:
> 
> Marc,
> 
> from the various questions you posed in this thread, it appeard to me that:
> 
>  1) you have never used the flow

fair enough, small nuance: not in production projecs, I have (and 
am) investigating through samples, exercises, try-outs... (and 
discussions like these)

maybe I am playing out of my league by speaking up in this thread 
so early, but it sure helps my understanding. I tend to believe 
I'm a rather easy understanding person, even if stuff gets 
complex. Still I don't want that knowledge build up to be at the 
cost of you wasting time (but I don't have the feeling I reached 
that point)

>  2) you have only a stereotypical notion of what it is and what it can
> do for you

uh, but actively showing that I like to deepen that understanding?

I started my thread by excusing for the upcoming rant-y tone of 
voice...  I guess I should of have kept the disclaimer in there

>  3) you have your own way of doing webpps and you like it

well, it serves a class of problems, I haven't seen that being denied

nor did anyone deny that it _is_ distinct to flow (while being 
similar at some points)

>  4) you would like to keep using it in the future

nuance:
- only when it applies
- and also inside cocoon

so more nuance:
- I'm also willing to invest in making it easily available to the 
larger community here... so at that time I see myself starting to 
discuss things over here?

(in fact as soon as I start on thinking in code I'm seeing myself 
condemned to the Action interface?, so I started thinking that 
jumping in on the same level as Flow makes more sense, also cause 
I could hope for reusing some of the nifty publication components 
out there)

so excuse me for being lazy and wanting to reuse so much of what 
is already there?

and this applies also for what I called 'the classic' technique 
which I think serves very well the gateway-passthrough to 
arbitrary stateless back-end (and it's a bit unfair to condemn 
people in this case to Actions while keeping on bashing everyone 
that uses it)

I like to believe there is a best tool for the job at any 
particular time (so yes I _do_ want to invest loads in flow since 
they cover a big class of webapps)

I also believe that a clear contract between sitemap, publishing 
components and 'arbitrary logic components' will make sure that 
more reuse between all of them is possible (i.e. 'the best tool 
for the job' attitude should not lead to a pile of mess)

So yes, I am asking to let different approaches then flow to be 
allowed into the game, we could still go about liking our own 
thing, or liking the fact that we can use the best thing for the 
job, but at least we could compare them on par in any specific case.

>  5) you are afraid that the flow will make it harder for you to keep
> using it
> 

mmm, don't think it is about fear here...

This is how I see it: I am questioning that not every webapp 
needs to keep a frozen execution point for every end-user 
interaction.

Some do: use a continuations based paradigm
Some only need interaction based state
Some only are passing through: please don't use actions ;-)

in all cases reuse large parts of your publication lines (and the 
  knowledge you have in building those)

> please, correct me if I'm wrong with any of the above.

naah, I like this 'upfront' message, there is some nuances to 
make as I showed, and I have to admit I was close to the point 
were I was going to ask you the same about being so fond of flow :-)

'if all you have is a hammer, then everything starts to look like 
a nail?' :-)

please understand that I might be challenging you all to think a 
bit out of the flow box... the less I feel willingness to do 
that, the more I'm cast into the role of the big flow-disliker 
which I am fundamentally not.

> 
> Now:
> 
>  1) the contracts between the "transition controller" and the object
> model will be solidified with the addition of an object to the object
> model. I will propose to call it "FlowModel" and it will be a read-only map.
> 

and that map will be made available to the jxpath thingies in 
this world to read out the #{..} stuff

the fact that '{continuation.id}' is going to be in there, still 
somewhat limits the reuse, but it's a bit too early to 
see/propose how that could be loosened up.

the back-forward discussion makes me think something like 
'flow.next', 'flow.back', 'flow.named-resource-x' makes sense?

>  2) actions aren't going anywhere for Cocoon 2.1
> 

fair enough, just make it realy easy for people to plug in their 
own component that gets called.

>  3) I showed (and you agreed) that there a contract between views and
> controller is needed and that the sitemap is not the right place to
> describe it.
> 
> So far so good. The above should remove all of your fears and close this
> thread (which is loosing focus). If not, please, let's try to keep focus.
> 

yep, I found myself introducing the broader reasoning behind my 
questions, guess I am silently looking for broader interest in 
the contributions I'ld like to make?


>                                  - o -
> 
> This said, before comparing the flow with anything else, please, at
> least, use it once.
> 

really actively doing so, but rest assured: 'using' it can be 
done at different levels, some of those will lead to threads like 
these?
(and it's not the example try-out user doing it I'm afraid)

and again when I say flow is [not 'the' way] (which you agreed) I 
do NOT mean to say it is [the 'not' way]?

-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