forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: forrest:hook vs. direct markup - should we drop the hook concept?
Date Fri, 02 Dec 2005 14:14:04 GMT
Tim Williams wrote:
> On 12/2/05, Thorsten Scherler <> wrote:
>>Hi all,
> I've unfortunately been too busy to properly keep up with all of your
> progress so this may not be worth much.
>>lately we proposed a new attribute @element for the forrest:hook
>>element. Now it is possible to have any markup as hook.
> I didn't catch this but now that I understand it, it makes me think
> that we might be letting our templating language make too many
> assumptions about the output (e.g. that it is markup).  Same thing for
> the new hooksXPath attribute. How are these supportive of non-markup
> output formats like text/rtf?

This is markup to create an internal representation of the document for 
later output. RTF is generated from XSL/FO (markup) and text is from our 
internal document format (markup).

We are an XML publishing framework, it is fair to assume everything we 
publish will, at some point in the lifecycle, be markup ;-)

>>- would it not be sufficient to have forrest:view and forrest:contract?
> If you had two contracts that needed the same output style how could
> you do it without having a hook to contain them?

In use, a single contract provides a single output style. There may be 
multiple implementations of the contract for different outputs but only 
one is used at any one time.

That is, if you want two different outpus, you will have two different 
views, one for each output.

>>I will later post my views before I hear some opinions.
> I reckon I think the hooks are needed, but that's based on a dated
> understanding of this stuff.  

I'm on the fence, I want to see more discussion and see some actually 
implementations of this stuff. So far all I can see is a load of code 
with no real example usage (sure we have the v2 seed, but it is not 
exactly comprehensive). I'd like to see some real use of views in 
whiteboard, this will help us address these kinds of issues.

I've made a start with the Notes plugin and we should convert the voice 
plugin to views. The resume plugin and the ECS plugin both have version 
1 views stuff, they need bringinng up to date with views 2.


View raw message