> sorry, it took me a while to get back on this
No problem, I'm somewhat amazed that you have found the time to follow up at
all...
>>>Hmmm, sure. but that is only a very small part of what flow-management
>>>is about. How would you keep the state across requests in XSLT?
>>
>> Same way you would in any other web app.... That's partially why I've
>> got aggregation of the session, request and other context data feeding
>> this thing.
>
> in that case you need actions in your pipeline and that means that you
> are not controlling the flow in your XSLT.
>
> If this is the case, this is nothing different from we have right now in
> place in terms of flow control.
Well, I meant aggregation in the general sense and not pipeline sense, but
yes, partly what I'm looking for is to make an XSLT version of an action
handler. However, that's only true to the extent that flowscript is a
JavaScript version of an action handler and of course that's only part of
the story...
<snip on xpath selector discussion/>
>>>>>The use of XSLT is *clearly* overkill. What you are describing is
>>>>>*NOT*
>>>>>XSLT: even if it uses the same syntax, the semantics are totally
>>>>>different (in fact, you are mixing XSLT semantics with the sitemap
>>>>>semantics... this cannot possibly be easier to learn/use/maintain than
>>>>>just the sitemap semantics)
>>>>
>>>>
>>>>That doesn't make sense: in that case you'd have to consider the
>>>>production of HTML from XML via XSLT a mixing of HTML semantics with
XSLT
>>>> semantics?
>>>
>>>No, because that content is *passive*.
>>>
>>>Here, you are mixing xslt and sitemap which are both 'active' content,
>>>content that has server-side semantics and will not be passed passivly
on.
>>>
>>>So, in fact, the complexity of sitemap+flowscript is repeated in
>>>XSLT+sitemap, just that your solution doesn't have a way to separate
>>>XSLT+the two.
>>
>> I don't think I understand your distinction. Consider for example
>> that instead of using XSLT I was proposing to use Haskell to write my
>> flow control manager. Would you have the same objection?
>
> yes, totally, because you would mess with the pipeline creation logic
> from the flow layer and that enforces concern overlap.
>
> 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?
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. 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)?
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"?
> 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; 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.
> 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.
<snip on more discussion of the same/>
>>>NOTE: I've been proposing that the flowscript might be generated out
>>>of
>>>a cocoon pipeline. That implies that you might use whatever declerative
>>>markup you want to describe your rules (as people do in a workflow
>>>environment) and have a stylesheet transform it into flowscript.
>>>
>>>That would:
>>>
>>>1) give you a way to keep the rules separated from the resources
>>>2) still use a declarative view of your rule engine (your rules can
>>>even
>>>be extracted out of a database and cached since I don't think they
>>>change that often)
>>>3) no need for custom sitemap transformation components
>>>
>>>this is how I would do it. Using XSLT as a pipeline componentization
>>>skeleton sounds golden-hammer all the way.
>>
>> Well that would meet our needs, but if a flowscript can be generated
>> out of a pipeline what's the difference between using the output of
>> that generator to control the flow and using the input directly to
>> control the flow of the pipeline?
>
> Oh, big difference: you keep things separate.
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.)
<snip on more similar discussion about separation of function/>
>> We've got three separate layers of meta-data in our model already
>> (well we should have three, currently we have two and a mix of
>> concerns as a result). As you climb up and down the abstraction tree
>> you deal with different
>> concerns: business process, work flow, finally, presentation flow. It's
>> nice to try and containerize presentation flow, but work flow always
implies
>> presentation flow (though not vice-versa). Similarly, business process
>> implies a bunch of things about work flow. I haven't come to grips with
what
>> that implies for this whole model but it suggests that there are several
>> more layers of abstraction and separation of concerns to be modeled
before
>> this whole thing is done...
>
> 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.
<small snip/>
>>>You are telling me that your metadata is contained in a
>>>tree-structured
>>>data model and you like it keep it so and you would like to use xpath to
>>>query it.
>>>
>>>Great, write your create sitemap selector that connects to your rule
>>>database, gets an Xml representation, create a DOM, and query that DOM
>>>with an XPath query layer. It's no more than 10 lines of java code if
>>>you know what avalon components to use.
>>>
>>>I tend to think that I don't need a pipeline for things that are not
>>>stream-based. But that's me.
>>
>> Interesting possibility. The thing that is maybe missing is that I
>> want to forward the partially processed sax streams. I don't really
>> need this other than for efficiency of processing.
>
> Oh, look, I wouldn't use 'efficiency' here at all. You are basically
> saying that you have your data in XML, you want to aggregate it (that
> means sending *all* your data thru the pipeline and calling SAX events
> all over the place) for a few transformations stages to react on *some*
> of that information.
>
> 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...
<small snip/>
>> 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)?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
