T5 Server Side Scripting for CSS

[Daniel Jue <te...@gmail.com>]

[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

Re: T5 Server Side Scripting for CSS

[Davor Hrg <hr...@gmail.com>]

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 <te...@gmail.com> 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
>