On Tue, Mar 1, 2011 at 9:43 PM, John M. Dlugosz wrote:On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/Allow to
home| wrote:
At build time I minimize and compress css and js (and images) and combine
into single files grouped by page(s). They could be pre-processed by TT
very easily. The final file names include an MD5 of their content forcing
a
re-fetch only if they ever change.
So you added that to the makefile somehow? I take it the generated name
must be supplied to the page's template once it is known. I'd like to learn
more about your system.
We have YAML config files for different classes of resources -- one for css,
one for js, one for images, and a few for different types of media (pds,
etc.). There's three sections in the yaml files, the first is a general
config with a relative source directory and output directory. Other
settings can be added there like compression threshold.
The next section defines "output_sets" where each named set consists of an
output file name e.g. all.css" and a secion "file_sets." There's also
additional config per set e.g. to specify the meda type (screen/print) and
things like IE version. The file_sets is a list of names referenced in the
last section. That section lists the source_files grouped by file_set.
Things like images and media that we want to version but are not combined
like css and js are configured also with YAML files but have a regular
expression to match all files in the source directory tree (so new images
can be dropped in without editing a config file).
Yes, Makefile.PL runs a script that uses the YAML files to build the
resources. Each resource type (css, js) has its own subclass for processing
that type of file. The css background image locations are parsed, images
found (relative to css file), compressed (when configured), copied to build
directory with a new filename (includes the MD5 of the image) and the
background URL is rewritten. Files are gzipped if over a threshold. The
build directory ends up with three copies of every file (linked), one with
the plain file "all.css", one with MD5, and one compressed.
Part of the build process builds a mapping file of "output_set" name to the
markup for either the combined version ("all.css") and also to the
individual files. This allows switching between compressed, minified single
resource file (used in production) to using the individual files for
dev/debugging. In the templates, for example, it's basically [%
css_resource_set( 'dynamic_cms' ) %]
So if you make a small change, you have to re-install the whole app? If the
file name changes, I can't just use Unison to sync the directory on the
production server.
The entire app gets built and installed to qa, then staging, then rsync to
production. (Although moving to RPM deployment.)
Much of this is to minimize the data over the wire and also to minimize the
number of http requests. And to version and cache, of course. The trade
off of fewer requests is some css and js ends up being shared by pages where
that code is not used. All the performance discussion talk about reducing
number of http requests. I'm not so sure about that trade-off -- fewer
requests vs. larger files that combine js and css that are not used on every
page. Now, I'd probably look more at more http request but done in a lazy
load way over a number of domains.
As for reaching for templates in CSS: Sure, you can break common lines
into different tags so you only specify a color once:
#this, #that, div p .theother { color: xxxxx }
but that doesn't help making (say) a border color and a background color
the same value.
I think that's a different problem. Again, it would be easy for us to
pre-process our CSS files, but that's just never been an issue. I think much
of what you are asking about can be taken care of with good css design --
and design changes don't happen very often so it's pretty easy to hunt down
and easy to verify by looking at the site. If the same color is used so
many places that you want to template it maybe then the css is not set up
clean enough.
