forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: forrest:hook vs. direct markup - should we drop the hook concept?
Date Fri, 02 Dec 2005 14:36:49 GMT
Tim Williams wrote:
> On 12/2/05, Ross Gardler <rgardler@apache.org> wrote:
> 
>>Tim Williams wrote:
>>
>>>On 12/2/05, Thorsten Scherler <thorsten@apache.org> 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 ;-)
> 
> 
>>>From your comments, I gather I'm missing something.  I think of these
> *.fv as output not internal format.  They are manipulating the
> internal format to produce a certain output, thus the need for the
> @type on view element.  Of course, it's fair to assume the internal
> will be markup but why have a type attribute on a view if it cannot be
> anything other than markup?     From my understanding some of these
> markup-related attributes (e.g. hooksXPath, element) don't make sense
> to me when @type != html/xml.

In order to get a non-XML output from Forrest you have to go via the 
internal structure. That is the power of Forrest:

many inputs -> many outputs.

To manage the complexity of this we provide an internal format, 
therefore only need to provide a single input transformation for each 
input and a single output transformation for each desired output format.

The structurer does not, IMHO, change that. If that is the intention 
then it raises some very serious concerns in my mind. Thorsten, can you 
clarify your own thoughts here.

(NOTE: Thorsten has a design goal of making Views independant of 
Forrest, so your concerns may be valid, but not from the perspective of 
Forrest where we are only relly interested in our internal format.)

>>>>- 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 mean two different contracts that were to be bound together on the
> output (e.g. nav-section and search-input).  For output purposes they
> need to be "contained" together somehow -- accomplished through a
> hook->div right now (or at least it was).

As I understand Thorstens proposal, each contract defines where it 
appears in the views ouptut document (potentially distinct from the 
Forrest output document). That doesn't change, ony the way of defining 
how this location is defined will change.

Ross

Mime
View raw message