On 12/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > On 12/2/05, Thorsten Scherler <[EMAIL PROTECTED]> 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. > > > >>- 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). > >>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
