[ 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). 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"). > 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
