forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: forrest:hook vs. direct markup - should we drop the hook concept?
Date Fri, 02 Dec 2005 14:27:20 GMT
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.

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

Mime
View raw message