Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 58561 invoked from network); 7 Dec 2005 15:37:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Dec 2005 15:37:48 -0000 Received: (qmail 87122 invoked by uid 500); 7 Dec 2005 13:51:08 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 86917 invoked by uid 500); 7 Dec 2005 13:51:07 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@forrest.apache.org List-Id: Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 86906 invoked by uid 99); 7 Dec 2005 13:51:07 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2005 05:51:07 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [81.169.145.175] (HELO natblindhugh.rzone.de) (81.169.145.175) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2005 05:51:06 -0800 Received: from [172.26.0.5] (242.Red-213-97-135.staticIP.rima-tde.net [213.97.135.242]) (authenticated bits=0) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id jB7DogLr005411 for ; Wed, 7 Dec 2005 14:50:43 +0100 (MET) Subject: Re: Views From: Thorsten Scherler To: dev@forrest.apache.org In-Reply-To: References: <1133780425.9762.19.camel@localhost> Content-Type: text/plain; charset=utf-8 Date: Wed, 07 Dec 2005 14:50:40 +0100 Message-Id: <1133963441.8218.50.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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: Now if you actually mean the
contractData
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: /* 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 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)