Christian Haul wrote:
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
Christian Haul wrote:
<map:transformers>
<map:transformer logger="sitemap.transformer.encodeURL" name="encodeURL" src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
<map:transformer logger="sitemap.transformer.browser"
name="renderForBrowser"
src="org.apache.cocoon.components.treeprocessor.sitemap.TransformerNodeBuilder">
<map:select type="browser">
<map:when test="netscape">
<map:transform src="stylesheets/{foo}/netscape.xsl" />
</map:when>
<map:when test="explorer">
<map:transform src="stylesheets/{foo}/ie.xsl" />
</map:when>
<map:when test="lynx">
<map:transform src="stylesheets/{foo}/text-based.xsl" />
</map:when>
<map:otherwise>
<map:transform src="stylesheets/{foo}/html.xsl" />
</map:otherwise>
</map:select>
</map:transformer>
</map:transformers>
Even passing parameters to the transformer could be achieved easily by adding them to the stack of sitemap variables.
There is one problem though: dependencies among such declarations would make eager initilization difficult. Lazy initialization would produce errors only run-time so a mixture needs to be applied.
and to add IMHO it doesn't really help in
- general sitemap readability
- separating the logic bits from the pipeline-config bits
...but I might be the only one seeing this last emerging advantage in this discussion?
Don't get it. If only generate, transform, and serialize is allowed, then these fragments may be used to factor out common parts -- simple parts to be precise. Hiding complexity away has proven successful in programming. But that requires IMHO to allow some logic e.g. matchers and selectors as well.
Another approach would be to assemble the pipeline fragments through flow but that seems to spoil SoC.
Could you elaborate a little more how you envision this separation, perhaps with a little example?
Chris.
Chris,
I did envision that only simple parts would be defined. And that those parts should get their dynamics from clear named arguments passed (via sitemap params or URI, still don't know) and _not_ from peeking and poking inside request/session/context settings
Furthermore your remark on spoiling SoC is precisely what I saw current matcher, selectors, actions do?
Now getting into your rightful demand for an example I thaught to take up yours:
<map:transformers> <map:transformer name="encodeURL" ... />
<!-- transformer_renderForBrowser(foo, browser) -->
<map:transformer name="renderForBrowser">
<map:transform src="stylesheets/{foo}/{browser}.xsl" />
</map:transformer>
</map:transformers>
<map:full-pipes> <!-- invented this element to prevent confusion with existing stuff, compare to resources as they were intended acording to the mail from Stefano: full-pipes -->
<!-- full-pipe_answerXForBrowser(answer, browser) -->
<map:full-pipe name="answerXForBrowser">
<map:generator src="{answer}.xml" />
<map:transformer type="renderForBrowser">
<map:parameter name="browser" value="{browser}"/>
<map:parameter name="foo" value="answers"/>
</map:transformer>
<map:serialize
</map:full-pipe>
</map:full-pipes>and keep this distinct from where we can have decision logic:
<map:pipelines>
<map:pipeline>
<map:match ...>
<map:action ...>
<map:select ...>
<!-- x levels nested stuff deciding on
{browser} and {answer} --> <map:call name="answerXForBrowser">
<map:parameter name="browser"
value="{../style-for-browser}" />
<map:parameter name="answer"
</map:call>... (and all closing stuff to become wellformed)
Hm, can't say I'm really sure here, comments welcome.
This is probably quite of a revolution compared to what we have now... (so for backwards compat I could see how old style would still be supported)
I might be blowing Stefano's FS and symmetric-design alarms completely here, but I can't help seeing the similarity in
<map:pipelines>
<map:pipeline>
<map:match ...>
<map:call function="answerXForBrowser()"> function answerXForBrowser(){
// decision logic .. sendPage('answerXForBrowser',
{'answer': .., 'browser': ..});
}Given that similarity I could see how in some cases the one approach would be benificial to the other, or even change over time for any particular reason.
-marc=
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
