Hi, here are some of my thoughts, For me, most of the times skinning application means changing css and few images, and the approach you are mentioning worked for me...
you should definitely cache you css (force browser to cache it), or else it's same as if you inline it, even worse (extra http request). However, in this case I suggest you increment and record version for your css, then modify your code to include version number in the css url. This way you'll have both caching and immediate refresh of your css. Davor Hrg On 8/29/07, Daniel Jue <[EMAIL PROTECTED]> wrote: > > [Background: I am beginning to abstract/distill my current application > into > something more general, where the GUI can be customized through an > administrative interface without the admins having to touch GUI related > code.] > > There was a post a while back regarding OGNL parsing of assets like CSS. > This is along the same line, but with the parsing/generation done in Java > code and only done once in a while. The resulting textual data > representing > the CSS would be persisted in an ASO or static. > > I have been thinking about an approach to the issue of CSS not supporting > constants, which could be useful for things like colors, background > images, > user-driven style changes, etc. > > On this page > http://icant.co.uk/articles/cssconstants/ > the author notes SSI and server side scripting using languages like php, > jsp, etc. I'd prefer to have the variables for my CSS be set and > manipulated inside my Java code, which can possibly be changed on the fly. > (Though if the browser is able to cache the CSS "file", changes may not be > picked up immediately if the header does not expire) > > Are there real benefits for my application server (i.e. Tomcat) to serve a > concrete file, versus pulling a pre-baked one straight from RAM? > > Is there a way to fake the response for a CSS file request, so that the > CSS > comes from something like a Stream instead of an actual file? > (So the browser wouldn't know the difference, and would cache it, etc) > > Of course we wouldn't want to inline all the css text, because I expect a > couple hundred lines at least (My current optimized CSS has about 4000 > lines > across a few files) > > I guess this is a larger version of whatever issues we would have with the > rounded corner service in T4, which is said to handle caching issues > automagically. > > > http://tapestry.apache.org/tapestry4.1/developmentguide/hivemind/roundedcorners.html >
