forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Meggitt" <>
Subject Generating files as part of the build process
Date Thu, 29 Jan 2004 19:10:31 GMT
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. 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

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? In addition to project.home and forrest.home, there would be
an additional directory like (project.generate.home). In some ways this
might lead to a standardization of the different means of rendering (static
vs. dynamic) within forrest. For example if I change a projects skin in the change will not take effect until I rebuild the site
(it is a statically rendered change). I only know this through trial and
error (or by closely looking at the code). The introduction of explicit
static rendering will result in improved debugging capabilities, a
simplification of certain transformations and additional flexibility. 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. This is not to say that it is not sometimes worth
the effort to enable changes to be rendered dynamically (in the case of
skinconf.xml it is definitely worth exerting a considerable effort). 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).

View raw message