forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thorsten Scherler (JIRA)" <>
Subject [jira] Commented: (FOR-632) Plugins exporting contracts and format independant contract loading
Date Sun, 14 Aug 2005 16:53:54 GMT
    [ ] 

Thorsten Scherler commented on FOR-632:

"However, this is not a perfect solution since there is now way of knowing what format the
contract produces." -> That is not 100% true. Each contract can produce in theory different
output formats. This information are within the contract (@format).
  format="xhtml" name="branding-grouplogo" inputFormat="xsl" body="true" head="false"/>

However, your suggestions for enhancement (1) are alright if we decide that *one* contract
can only provide *one* output format (we already talked about on the ml).

To (2) if you look in the code (viewHelper.xhmtl) there you will find:
 <!-- <!-#-INTERFACE
    Get the xsl:templates of the requested contract.
  {1} format to deliver
  {2} contract name-#->
   <map:match pattern="get.contract.*.*">
     <map:generate src="cocoon:/resolve.contract.{2}"/>
     <map:transform src="resources/stylesheets/contract.xsl">
      <!-#-Which output format?-#->
      <map:parameter name="format" value="{1}"/>
     <map:serialize type="xml"/>

I suggested your solution in April
There you can as well see the problem which you will run into ("java.lang.StackOverflowError").

> Plugins exporting contracts and format independant contract loading
> -------------------------------------------------------------------
>          Key: FOR-632
>          URL:
>      Project: Forrest
>         Type: Improvement
>   Components: Views
>     Reporter: Ross Gardler
>     Assignee: Ross Gardler
>      Fix For: 0.8-dev

> I've finally got a use case for views, so I'm jumping in with both feet instead of dipping
my toe in the lovely warm waters. So, here is my first observation about the way things work,
and a suggestion for an improvement. I want to run this by the views folk before I implement
it as I am not quite swimming comfortably yet. Lazy consensus is in opertion though, i.e I
will do this if noone objects.
> The Problem
> ===========
> I have enabled plugins to export contracts. However, this is not a perfect solution since
there is now way of knowing what format the contract produces. So we need a way of identifying
the right contract for the right format.
> This is solved in the existing system by having a viewHelper plugin that tells us in
its name what format it is (e.g. o.a.f.p.output.viewHelper.xhtml) and by having a matcher
in that plugins xmap that resolves the contract:
> <map:match pattern="resolve.contract.xhtml.*">
>     <map:select type="exists">
>       <map:when test="{project:resources}/templates/{1}.ft">
>         <map:generate src="{project:resources}/templates/{1}.ft"/>
>       </map:when>
> ...
> I see two issues with this solution:
> 1 - it prevents plugins providing contracts for multiple formats because they will always
have the same name (e.g. contract-name.ft)
> 2- the above matcher will be duplicated across all output formats, therefore is a maintenance
> ---
> Problem 1 can be solved by modifying the plugin naming convention to include a format
identifier, e.g.
> contract-name.xhtml.ft
> contract-name.pdf.ft
> contract-name.txt.ft
> ---
> Problem 2 can then be solved by moving the contract resolver match into the internal
views plugin and modifying it as follows:
> <map:match pattern="resolve.contract.*.*">
>     <map:select type="exists">
>       <map:when test="{project:resources}/templates/{1}.{2}.ft">
>         <map:generate src="{project:resources}/templates/{1}.{2}.ft"/>
>       </map:when>
> ...
> ---
> If nobody points out the flaw in my approach I will have a blast at soon(ish)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message