>> I'm not sure that this would hit the core? It looks to me more like a >> resource that wants to call other resources. I plug this new thing >> into the sitemap, it take over for a transformer at some point, then >> it calls other resources as defined in the sitemap. > > Yeah, that's basically what cinclude does. No need to change anything if > you follow that pattern.
Cinclude keeps rearing it's head, we may explore it, but somehow I suspect there are deeper issues connected with what it does vs. what I want to do that just aren't quite apparent... <snip/> >>>Still, XSLT was *NOT* designed for those type of things and my gut >>>feeling is that by twisting its model too much you might end up having >>>something that uses the same XSLT syntax but is not XSLT anymore... so >>>it might simply confuse people and appear as a 'golden-hammer' >> >> anti-pattern. >> >> I'd have to disagree. I think XSLT was designed precisely for this >> purpose: sort through some data and determine what data should be >> created as a result. > > 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. >>>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... They may not have access directly, but they have access? >>>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? There's no difference between using XSLT+sitemap and using flowscript+sitemap they both separate things identically. 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. I think you see what I am proposing as part of sitemap, but I think, rather, that it is part of flow...??? > 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? It seems that we're simply skipping a step and making things more efficient (caching of course pretty well negates that argument)? <snip on side tracked discussion about metadata in pipelines/> >>>This, instead of mixing stuff in the pipeline, enforces separation and >>>clean design. >> >> >> I'm still keeping the processing of the metadata separate from the pipeline. >> You have to call the new thing to access the metadata and the metadata is >> not exposed in the pipeline (as it would be with XPathSelector). > > Then I'm lost. 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. >>>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. 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... > 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. <snip on agreement that actions are problematic/> >> Whether the action >> looked at data, metadata or the phase of the moon to spit out the parameter >> is not relevant to the pipeline. Similarly, how this new component arrives >> at it's determination isn't relevant to the pipeline... > > Cool. > > So, basically your are saying that everything you want can be obtained > by writing a sitemap component (you tend to think of a transformer, I > suggest you to take a deeper look into selectors). Well, as I said I can look at selectors, but they don't really give me everything I want (the forwarded context). Let me ask (somewhat rhetorically), why is the flow manager any different from a selector? > If that is the case, great, we don't need to do anything. The flowscript > is there if you want it, but I won't force people to use it (or not to > use actions). It's entirely up to you. > > I was only concerned about your functional requirements needing sitemap > changes, but if that is not the case, I'm happy and in case you donate > your new component to us, we might want to distribute with Cocoon > because others might find it interesting. 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. > What do you think? Too tired to think any more, but I do hope that we can do something that meets our needs and will be useful to the Cocoon community in general. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
