Re: resolving contracts (was Re: [jira] Commented: (FOR-632) Plugins exporting contracts and format independant contract loading)

[Thorsten Scherler <th...@apache.org>]

On Sun, 2005-08-14 at 22:07 +0100, Ross Gardler wrote: 
> [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.
> 

The conclusion AFAIR was that a contract should only provide *one*
format (for a number of reasons).

> 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.
> 

IMO the interface though is the way to go in the future. 

The problems we have to solve first to make the interface working is 
a) the @head and @body problematic.
b) write a ContractGenerator.java (implements TraversableSource)

When I designed this part of the code I thought about it like:

get.contract.{format}.{name}
           |
           |
           +--> ContractGenerator (right now: resolve.contract.{2})
           |    Aggregates all contracts with {name} 
           |    from all locations (incl. plugins)
           |
           |
           +--> analyze result of ContractGenerator and choose {format}
           |    (right now: contract.xsl) 
           |
          \|/
Return the {name} contract in right {format}.

> > 
> > 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.
> 

Actually I will soon start refactoring parts of views into avalon
components. Anyway, please, go ahead and explore the possibilities,
because till now we did not have any contracts in multiple formats.


salu2
> 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)
> > 
> > 
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)