forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Generating files as part of the build process
Date Fri, 30 Jan 2004 08:23:17 GMT
Peter Meggitt wrote:
> I have some code to generate svg files that can be used by skins as images
> for things like rounded corners on tabs and menus. In some ways this is
> easier to use than hard coding corner properties as part of the url as used
> in the "read-svg2png-corner-resource" resource included in resources.xmap.
> The mechanism entails having an xml file (or generating one) in the skin
> that gets transformed into multiple svg (or png) files. 

You mean that instead of inserting the rounded corner info in the 
filename, you use a single descriptor for all corners?
You see, the CSS can be generated from an xslt file, and so that can use 
your description, *without* having to do any change.
Could you please post it here so I can take a look?

> I would like to
> invoke these transformations statically as part of the build process. With a
> previous version of forrest I would just create the files in
> build/webapp/skins/.... However now with webapp-local, I don't see any way
> of referencing generated resources (unless they are generated to a src
> location).


> Would anyone be opposed to the introduction of an additional directory for
> the purposes of storing and referencing generated resources (images, xslt
> stylesheets, css, skins, etc) when running a forrest site created with
> webapp-local? 

Yup ;-)

There is a mechanism that we will introduce to make source dirs 
configurable, that is the _locationmap_. Each project can have it's own 
locationmap that defines or augments the places where sources are 
searched for, and the same for skins. It's slated for 0.7.

 > I was
> playing with a mechanism to dynamically generate a skin (including css) from
> an enhanced version of skinconf.xml. It seemed (to me) to be much easier to
> generate all the necessary files as part of the build than to add additional
> complexity to sitemap transformations to enable changes to skinconf.xml to
> be rendered dynamically. 

Well, Cocoon is our transformation engine. What makes it "easier" for 
you to generate them before?

 > It is
> just a realization that there are certain transformations that are difficult
> (or impossible) to perform dynamically and that there should be a standard
> way to punt (static rendering).

I don't see anything that has to be generated 'statically', as you say. 
Can you post an example?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message