[Catalyst] uri_for (or lack thereof) in static pages

apv apv at sedition.com
Thu Nov 16 22:10:08 GMT 2006


Something I have done and will probably do again (but I'm not using 
right
now) is having static pages like that served by Catalyst the first time
they are requested and then writing them to disk (as part of the end
handler to let apache serve) them as static going forward. To update
files, erase them. Catalyst will rewrite them on the next request
and only the first one will have any kind of performance hit. A semi-
permanent disk cache, really.

You need apache to serve static files that alrady exist instead of
asking Catalyst for them. MST put up some htaccess instructions
for that in one of the fastcgi set up pages. Also, the "webuser"
needs to have file/dir write permissions which isn't always
possible (bride admin scenario again) or recommended.

-Ashley

On Thursday, Nov 16, 2006, at 13:47 US/Pacific, Cédric Bouvier wrote:

> I have a ѕimple yet thorny problem, which I expect most of you also 
> have
> or had. It has several possible solutions, but I'm chiefly interested 
> in
> knowing how *you* would solve it and why.
>
> We're developing a Catalyst application. It serves HTML, CSS,
> JavaScript, and images. HTML is the output of TT2, but CSS, images and
> JavaScript are static. We have them served by C::P::Static::Simple on
> the built-in server, and we use a <Location> the have them directly
> served by Apache/mod_perl, one the production server. Under mod_perl,
> the application's root is not the server's root, i.e., it is
> http://server/myapp, whereas it is http://localhost:3000 on the 
> built-in
> test server.
>
> This would not be a problem if the CSS were not linking to images. And
> because CSS pages are static, they cannot make use of uri_for(), and
> therefore get the links to the pictures wrong.
>
> Several solutions come to mind, and I cannot choose which one I like
> best (or I dislike the least):
> - have CSS served through TT2. I'm wondering about the extra load it
>   would put on the Catalyst engine. Maybe it's completely negligeable,
>   maybe not... Is it worth the effort to cache them? If so, what are 
> the
>   recommended best practices?
> - make all links in CSS relative. This makes it harder to spread the
>   stylesheets in a deep directory structure, unless one is willing to
>   tediously count the ../../.. (or was it ../..?) and count them again
>   when a stylesheet moves.
> - insist that MyApp be installed at the server's root, bribing the
>   sysadmin if need be (or threatening, or loudly shouting at, or 
> blackmailing, or
>   sacking, torturing...)
> - use some black magic involving mod_rewrite or even HTTP::Proxy to
>   modify the broken links on the fly... Hmmm, blackmailing the sysadmin
>   should be easier than having him tweak mod_rewrite...
> - Pre-process the CSS at install time, with some sort of ttree, and 
> then
>   serve them as static content.
>
> Any war stories worth telling, Gentlemen, Ladies?
>
> -- 
> C é d r i c   B o u v i e r
> <signature.asc>_______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: 
> http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>




More information about the Catalyst mailing list