Hunsberger, Peter wrote: (>> it's me)
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.No problem, I'm somewhat amazed that you have found the time to follow up at all...
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.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?
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 onlyPossibly, yes. And remembers that those URI can be as semantically meaningful as you wish.
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)?
Could be something like
/rule/3984948938498394
or
/webmail/composer/doYouReallyWantToSendYourMessage
For example, in the past I built an e-commerce site for the rental ofwell, my father (who doesn't know english) wouldn't agree :)
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"?
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.
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?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.
Great, than the flow is *already* what you need.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.
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.
Agreed.
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 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...
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.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)?
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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
