Ok, seems to me that we are finally converging to something. Great. Hunsberger, Peter wrote:
That could be and it's partly why I've started this discussion. This morning in a responses to Ovidiu I pointed out that perhaps what I really want is just to be able to use XSLT as the flow language? I'm not quite sure how that would work, but that's essentially what I'm looking for...
Ok, so instead of sitemap+flowscript you want XSLT+sitemap. Ok, I'm starting to get it. [snip]
Hmmmm, I'm not currently in favor of a pluggable sitemap engine... but you do have a point here, so let's keep the door open for a possibility.I hope no changes should be needed other than those that are currently be worked on to support flow and blocks. Part of my reason for pursuing this is to see if it will be possible to use flow and/or blocks to support what I want to do.
NOTE: the way cocoon is already architected makes it very easy to connect a new sitemap engine (we already have two: interpreted and compiled) and its also completely detached from the request environment (as for CLI abstraction). It would be pretty straightforward to plug in a different sitemap engine that didn't use the current sitemap semantics but something else entirely.
But I consider this a last resource, something that gets *too* close to FS and over-componentization.
[snip]
Hmmm, so far there has been *no* discussion whatsoever in allowing blocks to extend or overwrite the internal core functionalities of cocoon. And that was on purpose.Yes, I agree; I kept out of the blocks "language" discussion for the most part because I don't have enough experience with trying to plug new things into C2 yet. It looks like that discussion has come to some consensus but I'm not quite sure what it is? It seems to me that however it shakes out will be sufficient for my needs...
This is the first time it emerges but it's good to see if it makes sense or it's just FS.
This is more a community-thing that a technical issue, but look at the mess that Avalon became after allowing people to diverge without creating consensus :/
Not familiar with the issues, but I'll trust you on that and stay away from getting involved if you don't mind ;-)
Oh, lucky you :) [snip]
There are definitely two issues here. I'm not very concerned about this last
one, more about how easy it would be to plug something new in to manage
flow.
Ok, got it.
After working through this discussion it seems that this primaryYes, I definately can't see why anybody would want to use XSLT for the flow description.... but that might well be my personal limitation kicking in and I fully want to understand your point so that I might learn something that I failed to see before.
concern is probably: sitemap+flowxslt instead of sitemap+flowscript. The
problem now is that, (like you ?), I can't quite see how the two concepts
could be pluggable replacements for each other?
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.
[and XSLT is so overloaded with that that's sad!]
No, that can be said for Xalan. Cocoon is much more than a way to transform your data.I'd rather avoid using XSLT extensions, so I guess that means having some kind of DOM model where the input is a bunch of data and the XSLT reduced it to a single node that the flow controller then somehow interprets as the next "step" instruction?What you are presenting above is a very complex way to transform your data.Gee, couldn't the same be said of all of Cocoon? :-)
In case you didn't realize, XSLT is definately *not* a turing-complete language :) [you need internal scripting or extensions to turn it into one]I don't see what you can['t] manage flow with XSLT.Well, as you pointed out earlier, all Turing complete languages are isomorphic to each other...
Well we're still in an architecture mode and I haven't yet started on a prototype, but off the top of my head I could see an XSLT that looked something like the following. (Bear with me for a moment, this isn't right, but I think it introduces the concept better than jumping directly to what I want):
Great.
<xslt:template match="count(data/*) = 0">
<map:transform src="error.xsl">
<map:parameter name="parms" value="/request:parms/*"/>
</map:transform>
</xslt:template>
<xslt:template match="count(data/*) = 1">
<map:transform src="detail.xsl">
<map:parameter name="data" value="data/*"/>
</map:transform>
</xslt:template>
<xslt:template match="count(data/*) > 1">
<map:transform src="list.xsl">
<map:parameter name="data" value="."/>
</map:transform>
</xslt:template>
<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.
This being for the data results selection case we discussed earlier.Yeah, I think that all you want might be achieved with the XPathSelector.
Obviously this trivial example could just be a <xsl:choose> but the point is
that there may be other things going on for each match (in particular the
apply-templates invoking the templates might be complex and the parameter
building would be more complex.)
The problem with this as I've sketched it out so far is that it appears that
the XSLT is spitting out components on the fly (so to speak) when what you
really want to do is choose between existing components. As such, the
output should probably be a new statement. Also, what I'd really like is not
to use parameters to pass the nodes on, but to specify that a particular set
of nodes is directly the input to the transform. Finally, maybe the name
space should be Cocoon: instead of map: since that might make it clearer
where the output is going (and it matches up with the Cocoon pseudo
protocol)? Thus, the example of geographic vs. temporal search might look
something like:
<xsl:template match="searchType">
<xsl:variable name="curType" select="text()"/>
<xsl:choose>
<xsl:when test="/consent='All' or
/consent=protocol">
<Cocoon:select name="search" src="."/>
</xsl:when>
<xsl:when test="not(/history/searchType/text() !=
$curType >
<!-- the above probably doesn't work... -->
<Cocoon:select name="search" src="."/>
</xsl:when>
<xsl:otherwise>
<Cocoon:select name="error.xsl" src="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
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)
Unfortunately, I still think it's a deadly approach. See below.
Just for the heck of it let me contrast what I want with the flowscriptYes. This has been the argument about the XPathSelector as well.
approach to see if this helps:
Flowscript:
I've got a bunch of data, some represented as nodes, some as parameters and
some as a FOM model in JavaScript. I process this mixed representation of
the data and send some of it off to the end user. I get some data back, do
some conversion of the data between the various representations, do some
more processing and send something to the user once more. Etc, etc.
New thingy:
I've got a bunch of data represented as a bunch of nodes. I process these
nodes and I send them off to the end user. I get some nodes back from the
user, I do some more processing on these nodes, etc. etc.
I see what I'm looking for as a conceptually much cleaner way of attacking
the whole problem without having to work with my data being managed in
several different ways. One language, one data model start to finish....
But my architectural vision says that the pipeline should contain data while all metadata should remain outside the pipeline.
This, instead of mixing stuff in the pipeline, enforces separation and clean design.
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).
The use of XPathSelection in the sitemap stops us from being allowed to separate flow from resource production. Exactly because you merge two different datasets (pipeline data and pipeline metadata).
To me it's definately not cleaner model but it's aggregation of concerns.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
