Christian Haul wrote:
Marc Portier wrote:
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?
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
(have been offline because of a public holliday)
I don't see what's wrong with that since the request can be considered as implicit parameter. To the contrary, I would think this violates the OO design priciple of information hiding. Using the example, a transfomer that is supposed to generate the best representation for a client may use more than the browser identification but may also look into the capabilities and more.
The calling pipeline should IMHO not care how the perfect representation is determined or created.
Otherwise, I would fear that the approach would no scale to complex systems.
Please note that more or less the above is more or less possible by using the cocoon: protocol. The main difference here is that the result is not available through a URI but through a component hint.
In conjunction with blocks and blocks providing services for other blocks or visible from the outside, I believe that it makes sense to do the first through component hints alone and the second through URIs.
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>
Which illustrates that the transformer is almost useless and does not ease the understanding of the full pipeline because the full pipeline stays at a very low level of abstraction.
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)
This does remind me a lot of named templates in XSLT only that those declare the expected parameters.
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 think we should wait a little for the other post-2.1-RTs that are in the pipe and come back to this later.
Cheers.
Chris.
Yep,
I have to finetune my thoughts on this as well, so the extra time is welcome
and your reply now makes me see that the browser-compatibility thing is not the best example to be given (I just wanted to re-use your example not to throw in the need for getting into a new example domain)
browser-compatibility is obviously more in the technical publishing domain then it is in the business/arbitrary logic domain...
regards, -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]
