Re: doctypes - rendering pipeline - considerations

On 14.12.2005 10:12 Uhr, qMax wrote:
> Re.
> 
> While working on doctypes i considered it's a Good Thing to:
> - keep themes off the details of arbitrary doctype format.
> (to avoid (re)designing stylesheets for each added doctype)
> - keep doctype-specific formatting independant of themes and bxcms stuff
> (to reuse stylesheets, or use native xslt like NormanWalsh docbook)
> 
> The best way to achieve this is two stage processing:
>  1: native xml -> plain xhtml (doctype specific)
>  2: xhtml -> styled xhtml/page (theme and page layout)
> 
> The question is where to perform 1 stage.
> Ideally, at stage of styling (applying pipeline transform src="{xslt}"),
> the content of /bx/plugins/plugin[@name='doctype'] should already be
> xhtml, so that themes are completely independant from content.
> /* if required to use doctype-specific styling, 1stage could live hints like @class
> attributes, which is easily to transform in theme and to understand by
> webdesigners */

We do output html in the blog plugin, but that has some flaws as well,
as you have to transform this html again, if you need special designs. I
don't think you can come up with a general html, which fits all doctypes
and all themes. But in general, the idea isn't that bad.

But if you can seperate doctype2html and html2theme and this is
configurable on a "publication" basis, it may ease the whole situation.

> But as i figured out, output of plugin_foo->getContentById() is not
> goes in pipelines, but inserted in /bx/ stuff in collection->getContentById(),
> callen from within bxcmsGenerator, which in turn, calls plugin_foo->getContent()

yep.

> 
> Thus i see 3 ways to achieve the goal:
> 
> 1. use doctype specific xslt-wrapper in place of {xslt}
> (as you proposed, patching bxcms action)
> Such stylesheet should overload <xsl:template name="content"/>
> and transform content of /bx/plugins/plugin[@name='xmldoc'] into xhtml,
> using native stylesheets.
> This avoids using styling of xhtml content itself (e.g. replacing <hr/>
> with images) w/out hairy stuff with exslt,
> and requires yet additional parameter to point doctype native xslt styles.
> Somewhat ugly way.

I don't have an opinion right now on that

> 2. transform plugin output into xhtml before it get into pipeline.
> This transform should be performed in plugin_foo->getContentById()
> using xsltransformer with doctype specific stylesheet.
> Ever better is to use sitemap pipeline for more tweakfullness,
> but i dunno if it is possible and clean to call it from php
> w/out creating yet another popoon instance.

no quick solution comes to mind for that. I would have to dig deeper
into the popoon stuff.

> 3. put custom transform in popoon pipelines
> in standard pipeline before "constant(BX_THEMES_DIR)/{config://theme}/{xslt}"
> Or, i can force to use custom pipeline, with help of getPipelineById()
> and insert my transform before standartOutput transformations.
> This seems the best way, since themes stuff could not care of doctypes at all
> (just to take plugin[@name='xmldoc'] content in addition to [@name='xhtml'])
> And it allows additional freedom to tweak in this pipeline, w/out coding php.

that sounds reasonable to me. you could do in

<map:select type="any" var="{pipelineName}">

 <map:when test="mypipeline">

  <map:include label="bxcmsGenerator"/>

  <map:transform type="xslt" src="{whatever you need here}"/>

  <map:include label="standardOutput"/>
 </map:when>

and you have a 2 stage transformation.

Tell me, if you need something in the core classes for that making to work

chregu

> 
> Are there additional considerations about this ?
> Or maybe i miss something behind this stuff ?
> 

-- 
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [email protected] |  GPG 0x5CE1DECB
-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms