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.
> > >
> >
> > http://forrest.apache.org/docs_0_80/howto/howto-structurer-dsl.html#cssstructurer
>
> 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
#cssClass{
...
}
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">
contractData
</div>
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;
}
</forrest:property>
</forrest:contract>
</forrest:view>
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" />
</forrest:property>
</forrest:contract>
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
go.
>
> > > [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.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
