[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:
[ http://issues.apache.org/jira/browse/FOR-632?page=comments#action_12318751 ]
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="http://apache.org/forrest/templates/1.0";
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
format.
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.
Hmmmm....
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
http://marc.theaimsgroup.com/?l=forrest-dev&m=111476836301512&w=2. 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.
Ross
Plugins exporting contracts and format independant contract loading
-------------------------------------------------------------------
Key: FOR-632
URL: http://issues.apache.org/jira/browse/FOR-632
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.
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)
