forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: view/viewHelper: contract placement
Date Sat, 23 Apr 2005 09:48:33 GMT
HEADSUP: the links are not working of the *old* mails, because we moved
the plugins into the whiteboard. You have to manually change the url to
the plugin from old mails.

Hi Diwaker (can you set reply-to to this list or unset it, thanks), hi

On Fri, 2005-04-22 at 16:03 -0700, Diwaker Gupta wrote: 
> Hi everyone,
> Views allow us to define the order in which contracts appear, and also
> to group them using forrest:hooks. 

BTW I am using your original wordings (like the last sentence) for the
documentation. I hope that is alright for you. ;-)

> However, I didn't quite understand
> how view/viewHelper decides whether a contract goes into the <head>
> section or the <body> section of the final XHTML?

This decision is made by the contract author. Contract implementations
(the default ones) are kept in the viewHelper plugin in

If you have a look on the fontsize.ft you will find 
  format="xhtml" name="fontsize" inputFormat="xsl" body="true"
head="true" css="true">

Here the contract defines that it needs [body="true" head="true"
css="true"] for [format="xhtml"].

You started the discussion about extracting the css part and I guess we
should do it (can you start a vote for it?). 

>  From what I could
> understand from the code, in the view definition, all but the first
> level children are included inside body, rest go into head. Is that
> correct?

Hmm, no.

This is controlled by the view plugin, actually the only limitation
about nodded contracts is that <forrest:css/> or any other name-spaced
css elements will not be included in the body.

you find
<xsl:template match="forrest:view">
 <xsl:apply-templates select="*[local-name()!='css']"/>

The <forrest:css/> has to be in first level due to 
<xsl:if test="/*/forrest:view/forrest:css">
  <xsl:apply-templates select="/*/forrest:view/forrest:css"/>

The rest is defined in the viewHelper implementation and matched in the
above mentioned code:
<!--Test whether there is a body template needed-->
<xsl:if test="/*/forrest:properties/*[@body='true' and @name=$name]">

The forrest:properties are coming from the following match in the
internal.xmap of the view plugin.
      Aggregate the forrest:properties requested by the *.fv.
      The result is an aggregation of properties which defines the
templates to be call.
    <map:match pattern="**">
      <map:generate src="cocoon:/prepare.view.{1}"/>
      <map:transform type="xinclude"/> 
        <map:serialize type="xml"/>


I can extend on that if you like. ;-) 

We have to start a howTo about the forrest dispatcher view
 (view/viewHelper plugins) because now we have docu in both plugins but
to start 
with views you need *both* plugins installed. Trying to say you cannot
see the docu 
until you made the first step right:
1) install the view *and* the viewHelper plugin.

Patches welcome. ;-)


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

View raw message