cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <kpiroum...@apache.org>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Fri, 22 Nov 2002 11:05:39 GMT
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>

> Thanks Sylvain for this RT on a missing piece for the blocks concept.
> More inline:
>
> Sylvain Wallez wrote:
> >
> > <snip/>

[...]

> >
> > Pipelines as transformers
> > -------------------------
> >
> > <snip/>
> >
> >    <map:match pattern="a_page">
> >      <map:generate src="an_xdoc.xml"/>
> >      <map:transform type="pipeline" src="xdoc2skinnedHtml"/>
> >      <map:serialize type="html"/>
> >    </map:match>
> >
> > and
> >
> >    <map:match pattern="xdoc2skinnedHtml">
> >      <map:generate type="dont_care"/>
> >      <map:transform type="i18n"/>
> >      <map:transform type="xdoc2html.xsl"/>
> >      <map:transform type="htmlskin.xsl"/>
> >      <map:serialize type="dont_care"/>
> >    </map:match>
> >
> Again, this looks a little bit strange that generator and serializer
> have to be specified but are actually ignored. I can already hear
> thousands of complains from users telling: "Why do I have to declare
> them when they are not used?".
>
> I haven't thought much about this, but I think if we want to define
> services which can be called, than we should have a special syntax for
> this, to make explicitly clear that services are defined and not
> pipelines.

Why not <map:resource />? Current implementation of resources is very
similar to a callable service, but has some, IMO, artificial limitations. By
removing those limitations it'll be possible to declare resources as
services and then <map:call /> them where needed.

>
> I personally would like to add new concepts for new things rather
> than to try to press them into existing concepts where they do not
> fit 100%.

The current sitemap language is already too complex. Adding more new things
to it would make it even worse. Why not extend the current concepts to fit
the needs rather than inventing new ones?

>
> It's a pitty that we didn't had time to discuss this face-to-face,
> because that's a lot easier as I learned from the blocks concept...

For me, it's much easier to read English than comprehend the speach. But
it's really pity that I wasn't able to attend to GetTogether. Hopefully,
next year...

Konstantin

>
> Carsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.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