Thorsten Scherler wrote:
> On Mon, 2005-04-11 at 11:36 +1000, David Crossley wrote:
> 
>>>I defined it in the viewHelper output.xmap like 
>>><map:match pattern="dotdots">
>>>  <map:generate src="{forrest:context}/skins/common/xslt/html/dotdots.xsl"/>
>>>  <map:serialize type="xml"/>
>>></map:match>
>>>
>>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.viewHelper/output.xmap?view=markup
>>>
>>>...and then using it in prepare.xhtml.xsl like
>>><alias:import href="cocoon://dotdots"/>
>>>
>>>http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.view/resources/stylesheets/prepare.xhtml.xsl?view=markup
>>>
>>>Maybe we should declare the common helper stylesheets in the core and
>>>this way could use them in the plugins.
>>
>>Yes, i noticed what you did while i was preparing my patch.
>>However, i have never seen this use of
>><alias:import href="cocoon://..."/>
>>so i did my quick fix until i can get my head around it.
>>
> 
> 
> :) 
> 
> <alias:import/> will result in a dynamic import. The solution that we
> have right now (regarding view/viewHelper) will generate dynamically the
> xsl for the final step of the transformation.
> 
> ...xmlns:alias="http://www.w3.org/1999/XSL/TransformAlias">
>   <xsl:namespace-alias stylesheet-prefix="alias" result-prefix="xsl"/>
> 
> Here we switching namespaces for the resulting alias:*. The result is xsl but with alias as namespace.
> 
> I implemented it like this because I thought is more effective to define
> the templates I need for the transformation before. This way I will have
> always only a subset of templates.
>  
> ...but the drawback is that we do not know whether those pipes will be
> cached by cocoon. I am thinking about a java class to get the templates,
> store them in a JavaBean and then generating the final aggregated
> stylesheet (that only contains "needed" templates) out of the javaBeans
> but I reckon that we can discuss after 0.7 release.
> 
> 
>>Yes i reckon that we should have some method for a library
>>of helper xsl templates.
>>
> 
> 
> +1 That should be valid for the copyless approach. This way the usage of
> the core xsl helper templates will be more effective in plugins.

+1 This looks good.

Ross