<br><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 9:43 PM, John M. Dlugosz <span dir="ltr"><<a href="mailto:wxju46gefd@snkmail.com">wxju46gefd@snkmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"> On 3/1/2011 9:58 AM, Bill Moseley <a href="http://moseley-at-hank.org" target="_blank">moseley-at-hank.org</a> |Catalyst/Allow to home| wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At build time I minimize and compress css and js (and images) and combine<br>
into single files grouped by page(s). They could be pre-processed by TT<br>
very easily. The final file names include an MD5 of their content forcing a<br>
re-fetch only if they ever change.<br></blockquote></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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' ) %]</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>
</blockquote><div><br></div><div>The entire app gets built and installed to qa, then staging, then rsync to production. (Although moving to RPM deployment.) </div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As for reaching for templates in CSS: Sure, you can break common lines into different tags so you only specify a color once:<br>
<br>
#this, #that, div p .theother { color: xxxxx }<br>
<br>
but that doesn't help making (say) a border color and a background color the same value.</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>