You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Timm, Sean" <ST...@mailgo.com> on 2000/07/06 19:13:45 UTC
C2: Pre- & Post-Transformers
It seems like it would be useful to have pre- and post-transformers that are
applied prior to and after all other transformers on a per-pipeline basis.
Obviously this isn't necessary, since you could list the transformers in
every single match you had, but it would ease the administration of common
transformers (especially when you had to change something). For instance,
maybe you want XInclude to run every time for a certain pipeline prior to
any of your other transformers (or after your other transformers...or both).
Does anyone else see this as useful? Maybe something like the following:
<map:pipeline>
...
<map:pre-transform>
<map:tranform type="xinclude"/>
</map:pre-transform>
<map:post-transform>
<map:choose>
<map:when test="is('Mozilla5')">
<map:transform src="./stylesheet/site-xul-skin.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="./stylesheet/site-skin.xsl"/>
</map:otherwise>
</map:choose>
</map:post-transform>
</map:pipeline>
- Sean T.
Re: C2: Pre- & Post-Transformers
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > I picture sitemap verbosity as a "measure" of your URI space
> > complexity... so you have a _clear_ feedback of what's going on and you
> > have a coherent view of the whole addressing scheme.
>
> It could also "measure" the "support" level, such as various views, many browsers,
> many languages, abstracted resources, advanced dynamic generation, without having a
> bad URI space.
Totally.
Cocoon2 will finally allow you to "design" your URI space independently
on the "support" level you plan to add to your site. This also allows
you to partition efforts as well as expenses in several milestone points
without affecting the whole system design.
For example, start with single-browser HTML then multiple-browser HTML
then single-browser WAP then multiple-browser WAP then offline
generation then PDF then semantic view, etc...
...without having to modify your URI space, thus avoiding the
broken-link plague and allowing users to "reconstruct" the URI of the
requested resource rather than searching everytime.
If you know that
http://www.hotels.com/europe/italy/pavia/4-stars
tells the 4-stars hotel in my town, then it's easy to extrapolate that
http://www.hotels.com/[continent]/[country]/[city]/[quality]
is the general query paradigm. Which, in fact, represents a very precise
(even if limited by its hardcoded structure) semantic-driven research.
Hopefully, Cocoon2 will help give the users back the power to jump
directly to what they want.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2: Pre- & Post-Transformers
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> I picture sitemap verbosity as a "measure" of your URI space
> complexity... so you have a _clear_ feedback of what's going on and you
> have a coherent view of the whole addressing scheme.
It could also "measure" the "support" level, such as various views, many browsers,
many languages, abstracted resources, advanced dynamic generation, without having a
bad URI space.
Niclas
Re: C2: Pre- & Post-Transformers
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> "Timm, Sean" wrote:
>
> > It seems like it would be useful to have pre- and post-transformers that are
> > applied prior to and after all other transformers on a per-pipeline basis.
> > Obviously this isn't necessary, since you could list the transformers in
> > every single match you had, but it would ease the administration of common
> > transformers (especially when you had to change something). For instance,
> > maybe you want XInclude to run every time for a certain pipeline prior to
> > any of your other transformers (or after your other transformers...or both).
> > Does anyone else see this as useful? Maybe something like the following:
>
> -1;
> IMHO, it breaks cleanliness of the Sitemap, introduces more complexity for the
> sitemap processor (must make sure there are only transformers in the
> pre-pipeline for instance.)
>
> I would instead suggest an "include" of commonly re-occurring segments.
Hmmmm, good point, but I'd leave this for later after we have more
feedback.
> Niclas
>
> >
> >
> > <map:pipeline>
> > ...
> > <map:pre-transform>
> > <map:tranform type="xinclude"/>
> > </map:pre-transform>
> >
> > <map:post-transform>
> > <map:choose>
> > <map:when test="is('Mozilla5')">
> > <map:transform src="./stylesheet/site-xul-skin.xsl"/>
> > </map:when>
> > <map:otherwise>
> > <map:transform src="./stylesheet/site-skin.xsl"/>
> > </map:otherwise>
> > </map:choose>
> > </map:post-transform>
> >
> > </map:pipeline>
No -1 as well.
A couple of reasons:
1) XInclude should not be a filter but something that it's built-in the
cocoon processing chain, just like xbase or schema validation or
namespaces.
2) you risk to make "pipelines" behave as "pipes". Anyway, you'll do
pre-post processing with mounting
<match>
..do something pre..
<mount>
..do something post..
</match>
but should not influence how the pipe works.
3) your stuff doesn't work at all where is the serializer? sure, you
could add your serializer in the post process, but then isn't this just
like placing it into the pipe?
I understand you do this only to reduce verbosity and I agree that
verbosity reduction is almost always a Good Thing(TM), but sometimes it
removes readability....
BTW, if your sitemap is too verbose, probably your URI space sucks :)
I picture sitemap verbosity as a "measure" of your URI space
complexity... so you have a _clear_ feedback of what's going on and you
have a coherent view of the whole addressing scheme.
But again, these are just speculations, we need more real-life feedback.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2: Pre- & Post-Transformers
Posted by Niclas Hedhman <ni...@localbar.com>.
"Timm, Sean" wrote:
> It seems like it would be useful to have pre- and post-transformers that are
> applied prior to and after all other transformers on a per-pipeline basis.
> Obviously this isn't necessary, since you could list the transformers in
> every single match you had, but it would ease the administration of common
> transformers (especially when you had to change something). For instance,
> maybe you want XInclude to run every time for a certain pipeline prior to
> any of your other transformers (or after your other transformers...or both).
> Does anyone else see this as useful? Maybe something like the following:
-1;
IMHO, it breaks cleanliness of the Sitemap, introduces more complexity for the
sitemap processor (must make sure there are only transformers in the
pre-pipeline for instance.)
I would instead suggest an "include" of commonly re-occurring segments.
Niclas
>
>
> <map:pipeline>
> ...
> <map:pre-transform>
> <map:tranform type="xinclude"/>
> </map:pre-transform>
>
> <map:post-transform>
> <map:choose>
> <map:when test="is('Mozilla5')">
> <map:transform src="./stylesheet/site-xul-skin.xsl"/>
> </map:when>
> <map:otherwise>
> <map:transform src="./stylesheet/site-skin.xsl"/>
> </map:otherwise>
> </map:choose>
> </map:post-transform>
>
> </map:pipeline>
>
> - Sean T.