forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyriaque Dupoirieux <Cyriaque.Dupoiri...@pcotech.fr>
Subject Re: forrest:hook vs. direct markup - should we drop the hook concept?
Date Fri, 02 Dec 2005 14:48:37 GMT
Tim Williams a écrit :

>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.
>  
>
Think of a structured document :

hooksXPath can have values such as : document/header, document/footer, document/body, document/body/addresses,
document/footer/notes...



>>>>- 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).
>  
>
Correct, but the question of thorsten was - I think - do we need to have :
      <forrest:hook name="MyOwnHook">
Or simply :
<MyOwnHook>
    ...
</MyOwnHook>

By the way, I have made a test on my fichier.fv (replace all my 
forrest:hook tags by the direct tag - just to see what the file looks like)
And I have no conclusion :-P .

I mean, with the direct tags inclusion, the file is smaller but in fact, 
I am not sure it is easier to read...

Salutations,
Cyriaque,

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

Mime
View raw message