forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Views
Date Wed, 07 Dec 2005 13:50:40 GMT
El mar, 06-12-2005 a las 12:49 +0930, Paul Bolger escribió:
> > (NOTE: default.fv is now common.fv!!!)
> > > [views:modify html classes] I'm trying to work out where css classes
> > > are being inserted, specifically in content-main.ft, because I'd like
> > > to modify local versions to skip a lot of the superfluous ones.
> > >
> >
> >
> That tells you how to add extra CSS - I'm trying to get at the classes
> which are inserted into the contract itself.

Hmm, I am unsure whether I understood correctly, but here it goes:
If you are looking for the 
definition they are in the *.css that is referenced in the structurer.
Which one in special that depends on which theme you are using.

e.g. with the pelt theme the first css is:
<link media="screen" href="themes/common.css" title="common"
rel="alternate stylesheet" type="text/css" />

Now if you actually mean the 
<div class="someClass">
definition of the "to-be-used" class/id in the divs they are either
coming from a forrest:hook and/or from the contract directly. 

Bottom line is that you are actually never define your css in the
structurer nor in the contract, you online define the "to-be-used"
class/id and then edit a *.css to meet your current design needs.

Now linking the css will slightly change as soon as the
dispatcherTransformer is finally better tested and with less bugs. ;-)
Sadly the asf is down ATM and I cannot check in the example of how we
will define css, but here is a structurer example:
  <forrest:view type="css"  hooksXpath="/">
    <forrest:contract name="branding-generic-css">
      <forrest:property name="branding-generic-css-input">
        /* Extra css */
    p.quote {
      margin-left: 2em;
      padding: .5em;
      background-color: #f0f0f0;
      font-family: monospace;

The concept is the same as for html. The above will result in a
standalone css file which you then have to link in your html-structurer
definition. In general the css type will be IMO the exception because
you normally do not need dynamic css definition (one exception is e.g.
the branding-theme-profiler).

> > (NOTE: the css inclusion will change. The forrest:css will be gone once
> > we release the first implementation. Then the css linked/or inline have
> > to be requested by a contract.)
> Does that mean there would be the equivalent of an SSI for the css links?

Hmm, I do not understand what you mean, but imagine the above resist in
index.fv then linking in the html part like 
<forrest:contract name="genericMarkup">
  <forrest:property name="genericMarkup">
    <link media="screen" href="localhost:8888/index.css" title="common"
rel="alternate stylesheet" type="text/css" />
would bring this up.

> > > [views: no css] Is there a way, yet, to set views to produce no css at
> > > all? I notice there was some discussion about this a few months ago,
> > > but couldn't find any reference to it happening.
> > >
> >
> > Like always in forrest: You get what you define. ;-)
> >
> > Seriously, till now there is a fallback, if no forrest:css is defined in
> > the *.fv then the common.fv will be inserted. As soon as you add *one*
> > forrest:css *only* this get linked/included.
> But you still get stuff like "id="menu_1.2" class="menuitemgroup" all
> the way throught the output, that's really what I'd like to lose.

Then you need to rewrite some of the contracts, because they are
responsible for what you just wrote. I imagine your are talking here
about "nav-*" contracts. Just add to your project theme dir to the
common html contract the ones you want to override and you are good to

> > > [indent html]  Where would one put the indent="yes" attribute to get
> > > Forrest to output indented html?
> > >
> >
> > We are using the XHTML serializer and *not* the html one David gave the
> > link for. Please see the internal.xmap of the structurer.
> >
> > > [views: naming]  I'm confused! Themer, v2, structurer, views,
> > > dispatcher  - are these all the same thing?
> > >
> >
> > Already answered. ;-) Themer and Structurer are integrated components of
> > the dispatcher. The first prototype implementation was called views,
> > followed by the current version v2.
> >
> I'd volunteer to write up the functions and definitions of the various
> components, but I still don't understand. If we were to have a 'views
> glossary' section do you think it should be a new doc, or stuck on the
> end of one on the existing ones, howto-structurer-dsl, for instance?

We need an introduction to dispatcher document, maybe you are keen to
start it, would be awesome.


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

View raw message