forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: forrest:hook vs. direct markup - should we drop the hook concept?
Date Fri, 02 Dec 2005 15:28:45 GMT
On 12/2/05, Ross Gardler <> wrote:
> Tim Williams wrote:
> > On 12/2/05, Ross Gardler <> wrote:
> >
> >>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 ;-)
> >
> >
> >>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.

yes I do have a vague grasp of how forrest operates.

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

Yowsers, I must not be typing with clarity today.  I'm not suggesting
that Thorsten has any intention different than the
srcformat->internalformat->outputformat that we have today.  I suppose
instead of confusing the issue further, I'll just ask as simple
question:  Once we're in a V2 world, what is the essence of an output
plugin?  I assumed that, for example, instead of document2text.xsl,
we'd have text.fv.   [potentially combine your answer with my question

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

Why would a contract define it's position in the output?  That would
make contracts much less re-usable I'd think.  Seems to me they should
be context indepedent.  That seemed to be where Thorsten was heading
by wanting to remove the head/body booleans I think.  The xpath
insertion points should be in the view (*fv) rather than the contract.

Anyway,along with my question above, how is a view output document
potentially distinct from the forrest output doc?  Views is creating
the forrest output doc as I understand it -- i think the answer to
this and my question above will clear a lot up for me.

View raw message