cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Flow wishlist :)
Date Thu, 05 Dec 2002 22:14:42 GMT
sorry, it took me a while to get back on this

Hunsberger, Peter wrote:

>>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.

>>>>Ah, we are coming back to the XPathSelector!!!
>>>>
>>>><map:select type="xpath">
>>>> <map:when test="count(data/*) = 0">
>>>>  <map:transform src="error.xsl"/>
>>>> </map:when>
>>>> ...
>>>></map:select>
>>>>
>>>>This was proposed a while ago but was voted down since the sitemap
>>>>routing components shouldn't have a way to access the content of the 
>>>>pipeline.
>>>
>>>
>>>But sitemap components already have ways to access the content of the 
>>>pipeline, it's just that currently you have to expose those contents 
>>>as parameters...
>>
>>Selectors, matchers and actions have no way to get the content of a 
>>pipeline (by design!)
> 
> 
> Well if they don't your solution of having a generator create a parameter
> for choosing between the count=1 vs. count>1 transforms wouldn't work...

yep, I know that. I was just showing how your proposal of using XSLT as 
a flow control layer is close to have XPathSelectors and since we 
already extensively talked about that I could point you to that 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 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.

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)

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?

> There's no difference between using XSLT+sitemap and using
> flowscript+sitemap they both separate things identically.

Exactly, but the code you showed me clearly doesn't.

> The difference is
> that with flowscript I use callPage (or whatever) to get things back to the
> sitemap, with XSLT I use Cocoon:select (or whatever) to get things back to
> the sitemap.  

Nop, dude. The code you showed me had *explicit* calls to map:transform, 
which is not the same thing as returning control to the sitemap thru the 
use of a URI as a contract.

Big difference.

> I think you see what I am proposing as part of sitemap, but I think, rather,
> that it is part of flow...???

The fact that I can't see where your XSLT belongs, shows you exactly why 
I think you are mixing concerns.

>>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.

> It seems that we're simply skipping a step and making things more
> efficient (caching of course pretty well negates that argument)?

No, nothing about efficiency at this point (even if I don't see any 
reason while what I'm proposing can't be efficient), but architectural.

I repeat: I want things to be kept separate. The flowscript describe the 
flow between resources and the sitemap describes how these resources are 
produced.

The contract between them is:

  - the URI space of the cocoon-handled resources
  - the parameters the various resources consume
  - the parameters the various resources produce

No matter *what* syntax you propose to describe the flow layer, I will 
be against it if it doesn't allow this separation as a I described it 
because it would be *nothing* different from what we have today with 
actions.

> Consider the flow manager a black box for a moment.  If I plug in version X
> or version Y of that black box it shouldn't change the way the rest of the
> pipeline views the metadata.

Totally agreed, but this is only *IF* that flow manager is a block and 
that is true *only* if the concepts they implement are the same.

>>>>Your bunch of data is always represented as nodes (since it's XML and 
>>>>must be processed that way). Your bunch of metadata is always 
>>>>represented as objects (since it's not XML and should not be processed 
>>>>that way).
>>>
>>>But all my metadata is XML and I have good reasons for processing it that
>>>way...
>>
>>Oh, gosh, golden-hammer all over the place.
>>
>>XML is a syntax, not a data model. Your data model in the pipeline is 
>>SAX events. Do you need to process your metadata as a stream of events? 
>>I'm positive you don't.
> 
> 
> Arg, too hasty of explanation... As I've pointed out, much of this is driven
> across organizational boundaries.  As such, we've got a common syntax for
> describing our metadata and it happens to be XML.  Do I need to process this
> as a stream of events?  I don't think so but it makes me pause to think
> about the possibilities: one persons meta-data is another persons data.

True. But the data model remains the same for both you and me.

> 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.

In that case, I can further separate things.

But my point is that sitemap/flowscript separation is complete. I was 
challenging your concept of using XSLT to see if the S+F model didn't 
work, but I think it still does because I think it's your model that is 
weaker (SoC-wise, of course) [no offense, please, just trying to be 
objective on what I see so far]

>>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.

I would think that this is against IoC: if should be the transformation 
stage to call your metadata only when it requires some of it. It 
shouldn't be you pushing all your metadata down the transformer's 
throwt. That's utterly inefficient.

> 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.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message