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 Tue, 03 Dec 2002 19:18:13 GMT
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]

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

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.

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]

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

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.

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 primary
> 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?  

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

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!]

> 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? :-)

No, that can be said for Xalan. Cocoon is much more than a way to 
transform your data.

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

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]

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

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.

> This being for the data results selection case we discussed earlier.
> 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>

Yeah, I think that all you want might be achieved with the XPathSelector.

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

Yes. This has been the argument about the XPathSelector as well.

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