forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject resolving contracts (was Re: [jira] Commented: (FOR-632) Plugins exporting contracts and format independant contract loading)
Date Sun, 14 Aug 2005 21:07:06 GMT
[I'm replying onlist so we can discuss easily, I'll post summaries to 
the issue when we reach a conclusion.]

Thorsten Scherler (JIRA) wrote:
>     [ ] 
> 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).
> ...
> <forrest:template
>   xmlns:forrest=""
>   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).

What was the conclusion of this discussion? I can't remember.

I do not see how a contract can provide multiple templates (at least 
with the existing implementation) since the template for the output 
format should e provided by the plugin that provides the relevant output 

But wait... If a contract only defines what contract should be used and 
the output plugins only provide the templates then a contract can 
provide multiple output formats.


I think I could have a discussion with myself about this ;-) I'l wait 
for you to help me catch up with the current opinion of those already 
working on views though, no doubt you already went over this stuff.

> 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:transform>
>      <map:serialize type="xml"/>
>    </map:match>-->
> I suggested your solution in April
There you can as well see the problem which you will run into ("java.lang.StackOverflowError").

This is only relevant if contracts provide multiple formats so I'll 
await your response above before exploring this part.


>>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.
>>Problem 1 can be solved by modifying the plugin naming convention to include a format
identifier, e.g.
>>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)

View raw message