Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: forrest:hook vs. direct markup - should we drop the hook
	concept?
From: Thorsten Scherler <thorsten@apache.org>
To: dev@forrest.apache.org
In-Reply-To: <43905C01.20803@apache.org>
References: <1133519890.8213.8.camel@localhost>
	 <499888440512020520y50c22a30hb56c4c7d38824d3e@mail.gmail.com>
	 <439056AC.9020500@apache.org>
	 <499888440512020627m4b8b1cedkec64213ebf856354@mail.gmail.com>
	 <43905C01.20803@apache.org>
Content-Type: text/plain; charset=utf-8
Date: Fri, 02 Dec 2005 16:31:03 +0100
Message-Id: <1133537464.8213.66.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

El vie, 02-12-2005 a las 14:36 +0000, Ross Gardler escribió:
> 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.
> 

Hmm, which thought? Just to remind everybody the structurer is in the
end only an enhanced version of an output plugin. It works like we
stated in our TR.

Regarding the hooksXpath, if we decide to drop hooks this would not be
needed anymore. 

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

Yes, instead of writing:
<forrest:hook element="xXx">...</forrest:hook>
one can write:
<xXx>...</xXx>

I am still not came to a final conclusion whether or not to drop hooks.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)