Re[2]: doctypes - rendering pipeline - considerations

Thursday, December 15, 2005, 2:37:28 PM, Christian Stocker wrote:
CS> 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 */

CS> We do output html in the blog plugin, but that has some flaws as well,
CS> as you have to transform this html again, if you need special designs. I
CS> don't think you can come up with a general html, which fits all doctypes
CS> and all themes. But in general, the idea isn't that bad.
The core idea is to have some intermediate format to convert all
doctypes on a site.
(Apache Forrest uses this idea with their own xdocs format.)

Benefits are:
- themes do not care about original format,
- this intermediate xml could be easily converted into something
other, then text/html output (text/plain or xml/fo) using common stylesheets.
- possible more comfortable integration of one page content to another.

The plugin output xhtml is anyway transformed in
themes/standard/common.xslt with
<xsl:template match="*" mode="xhtml">
<xsl:element name="{local-name()}">
    <xsl:apply-templates select="@*" mode="xhtml"/>
    <xsl:apply-templates mode="xhtml"/>
</xsl:element>
</xsl:template>
(BTW, why just <xsl:copy> is not used ? some namespace bug somewhere ?)
And special designs are just a matter of adding templates in mode "xhtml" with
higher priorities.

CS> But if you can seperate doctype2html and html2theme and this is
CS> 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()

CS> yep.
One drawback of this design i've found:
pipeline parameters (pipelineName and stylesheetName) is global for
all collection, and selected using plugin FIRST declared in .configxml
(and matching given request uri)
This avoids mixing several plugins in collection that use parameters.
In my case: i cannot mix xhtml and my xmldoc plugins in a collection.
(that's ok since i can handle xhtml with xmldoc).

Maybe it would be better to setup these parameters right in .configxml,
instead of using getFirstPlugin() ?

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

CS> no quick solution comes to mind for that. I would have to dig deeper
CS> into the popoon stuff.
The benefit of this way is that plugin output gets through popoon
pipelines and can be applied with popoon features like aggregating,
switching, etc.
Dunno if it is really needed.

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

CS> that sounds reasonable to me. you could do in
CS> <map:select type="any" var="{pipelineName}">
CS>  <map:when test="mypipeline">
CS>   <map:include label="bxcmsGenerator"/>
CS>   <map:transform type="xslt" src="{whatever you need here}"/>
CS>   <map:include label="standardOutput"/>
CS>  </map:when>
This is exactly what i've done, using {stylesheet} pipeline parameter.
And it works fine
(with point that mentioned above, about global pipeline params)
It required 2 plugins (handler and resource),
Changes in sitemap.xml
and bxcms action (to set up parameter stylesheet)
And 1 additional module to handle site-wide doctypes configuration.

When i'll come up with all this working fine -
can i submit it to bugzilla as an extension patch ?

-- 
 qMax

-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms