cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Sat, 07 Dec 2002 19:38:40 GMT
Hunsberger, Peter wrote:

(>> it's me)

> No problem, I'm somewhat amazed that you have found the time to follow up at
> all...

Like I said in the past, I like healthy and friendly discussions 
expecially with people that disagrees with my views, because that's how 
I normally learn things.

>>In the flowscript, there is *NO*WAY* you can control how the pipelines 
>>are composed since you just call resources using their URIs. It's not 
>>the flow manager's concern to describe *how* the resources are generated.
> Ahh, now I understand the distinction you are making.  I see what you are
> getting at and why you want it, however this brings to mind two things:
> 1) I hadn't really made the differentiation between your semantics and mine
> partly because the term "callPage" implies, to me, a "call" to a named
> resource.  As such, it seems to me that the command to jump out of the flow
> layer should be something more like "applyURI" or "resolveURI"; you're not
> calling a named resource, your resolving a URI in your flow?

the methods are called 'sendPage*', Peter. We are not calling anything. 
We are handling control to the resource production logic which is 
contained inside the sitemap.

applyURI and resolveURI don't make any sense to me in this context, 
because you are not applying a URI (you are asking for the sitemap to 
generate that resource) and you are not resolving a URI (resolving, in 
my book, means mapping from one URI to another URI)

> 2) I wasn't really intending on letting the flow layer control how resources
> were composed.  My first example started from that, but the second example
> was intended to show that what I really wanted was a bundled set of
> resources.

Great. You have that right now in the flow.

> I hadn't made the leap to only referring to these resource only
> by URI, but I can see why you are doing that.  However, in my experience the
> mapping between a URI and a named resource would be equivalent most of the
> time (if not always)?  

Possibly, yes. And remembers that those URI can be as semantically 
meaningful as you wish.

Could be something like




> For example, in the past I built an e-commerce site for the rental of
> charter jets.  The process of chartering a jet has many steps, 4 of which
> could be done in any order, and the last two of which (credit card
> validation and final confirmation) had to be done in a specific order.  If I
> had URIs like:
> 	xxx/charter?step=n
> 	xxx/cardvalidate
> 	xxx/finalconfirm
> then I don't expect there'd be much guessing on the "contract"? 

well, my father (who doesn't know english) wouldn't agree :)

but the point is not about 'guessing' the contract, is about *having* 
it. It could even be made of a list of numeric pages IDs (that might be 
very handy for you, I don't know and I don't care, it's your choice) or 
they could well be chinese URIs. As long as there is a solid contract, 
there is separation and that's what I care for.

>>This enforces separation. Might be painful at first, but *very* useful 
>>down the road when you can manage and maintain your flow without having 
>>to touch (or being afraid others touch!) the resource-producing 
>>pipelines and the URI space (which acts as a contract between the flow 
>>and the sitemap, enforcing good use of internal contracts and parallel 
>>development between separate teams)
> Well, like I said I can see why you want that contract.  The added
> abstraction does provide some useful separation.  The same separation can be
> maintained by using explicitly named resource; 

Well, you are, in fact, explicitly naming a resource with a URI.

> but why introduce another mapping between the two layers?
> The only reason I can see might be for
> performance; you can enforce name uniqueness in the sitemap and then hash
> directly to the resource from the name saving the URI resolution step.  For
> cases where you want to really use a URI then you support that also, thus
> you may want both "resolveURI" and "callResource"; one which processes a
> general URI and the other which allows Cocoon to shortcut directly to the
> resource as composed in the sitemap.

I see your point, but I don't know why we should make another layer of 
indirection... performance aside, do you envision a functional reason 
for having that?

>>Now, your are proposing to have a flow layer that has the ability to 
>>control *which* transformer gets executed. I don't care about what 
>>syntax you are suggesting to describe that, but I *DO* care about the 
>>fact that you are mixing concerns that I want to keep separate.
>>Do you see my point?
> Yes, I see that.  It was more that I hadn't thought about the exact
> semantics and syntax for gluing this all together than a real desire to
> control directly what transformer gets invoked.  My requirements is to call
> a set of resources and not a specific Cocoon component.

Great, than the flow is *already* what you need.

If you don't like the flowscript syntax, you can still use a 
markup-representation of a FSM and then transform that into flowscript.

> I don't see this, you're just introducing a complier or interpreter between
> the flow instructions (the input to the flow generator) and the flow
> manager.  Whether the input to the flow manager is XML or JavaScript does
> not change the separation between the sitemap and the flow layer.  (The fact
> that the input "language" is XML is a coincidental in this case.)

Yes, I agree with you here.

>>Agreed. I've already said that 'flowscript' is going to mix concerns 
>>between 'presentation flow' and 'work flow'. And this is the reason why 
>>I'm seriously thinking about allowing flows to be created with cocoon 
>>pipelines and imported together because that way I could have part of my 
>>flow as a flowscript and part of it as a WFDL (workflow description 
>>language, a standard declarative markup for workflow definitons) that 
>>can be 'transformed' into javascript by a cocoon pipeline.
> Add BPEL4WS to the mix and you've got all your bases covered.  I think the
> main reasons for not directly implementing the general Cocoon flow manager
> using XML as input are a) there are multiple standards, b) the standards are
> verbose and complex and for most use cases they are over-kill.  However,
> that doesn't mean that it shouldn't be possible to implement a Cocoon flow
> manager that uses these XML descriptions directly instead of first
> converting them to flowscript.


>>I would call for 'inefficiency' right there. You are basically sending 
>>thru *all* your metadata even if you don't know you're going to use it 
>>or not.
> Well no, I'm still using multiple pipelines to aggregate different metadata
> sources as they are needed for a given resource. So, not everything gets
> processed every time. However, the complexity of our business rules does
> require us to process a lot more metadata than other people would ever think
> rational...

Still I don't buy how a 'push model' (I'll send you what you think 
you're going to need) can be more efficient than a 'pull model' (you ask 
me what you want), but that might well be me.

>>>I've been pretty comfortable that we will not require sitemap changes 
>>>or at least no changes to the sitemap language.  I do think we might 
>>>want to use the same hooks as the flow manager.
>>Nop, because the flow manager will *not* have hooks on how the sitemap 
>>pipelines will be composed.
> Right, but I expect you're going to still hook back into Cocoon directly and
> not process the URI up via HTTP unless it explicitly needs to be processed
> that way (or vice versa; allow at least the Cocoon pseudo protocol to bypass
> general HTTP processing)?

Correct, these hooks exists, but the only 'hooks' between the flowscript 
and the sitemap are the sendPage* functions and these are, by technical 
necessity, internal methods.

And these hooks will not have a way to indicate *directly* how a sitemap 
pipeline should be assembled, but will just pass control to the pipeline 
responsible of producing the URI that the sendPage* methods will invoque.

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message