[ http://issues.apache.org/jira/browse/FOR-632?page=all ]
Ross Gardler resolved FOR-632:
------------------------------
Resolution: Fixed
Assign To: (was: Ross Gardler)
> 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
> 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
