On Sun, Aug 06, 2006 at 04:18:36PM +0300, Marius Feraru wrote:
> <for Gavin>
> Gavin, what I'm trying to promote is better practices and constructive
> criticism. If you get them as "bombastic" and "trolling", you can
> always set an ignore filter on my name/address and don't bother.
> My recommendation for you is to read Merlyn's /boilerplate/ at:
> http://www.perlmonks.org/index.pl?node_id=205373
> </for Gavin>
>
> I agree my brevity may fail to make some us understand what I meant,
> mostly because of my tendency of avoiding duplication (ergo newer people
> on the list may have missed past discussions). Luckily, there are always
> good fellows around providing more helpful explanations (as Dave did
> with his follow-up).
Marius, I am happy to accept constructive criticism. Can I suggest that you
if you want your comments to be received as such that you listen carefully
to what has been said and tone down comments like:
> >> >> Another interesting trick is to setup an autohandler for the css files
> >>
> >> NO! This is NOT "interesting", it's just like killing a mosquito using a
> >> shotgun. All you'll get is hurting yourself and all the others around.
As it is, you've largely misunderstood what I'm doing here, so most of your
comments are pretty unhelpful.
> As Gavin missed my point completely, I suppose there could be others too
> in the same position, so I'll reiterate (hopefully with less brevity).
<snip>
No Marius, I didn't miss your point. I was showing an alternative technique
for css inclusion in autohandlers, not suggesting the two were equivalent.
If you want inheritance, use methods. I want an optional css file attached
to a component. For this, attributes are easier and faster. So your
criticism wasn't constructive, it was misleading.
> Back to caching...
>
> Gavin wrote:
> > The output is static, the input is not.
>
> So he just confirms my /misunderstood/ observation:
> >> We settled it's not a static file, so using source_file's mtime is
> >> wrong, as you don't use the resultant mtime composed from _all_ the
> >> resources involved in generating the response.
Wrong again. Using source_file's mtime is quite correct _unless_ you have
external dependencies. My CSS files don't. I'm using Mason just as a fancy
macro language e.g.
% if ($topbar_style eq 'experimental') {
#topbar {
color: <% $topbar_color3 %>;
background-color: <% $topbar_bgcolor3 %>;
}
% } else {
# ...
% }
<%init>
my $topbar_color3 = '#fff';
my $topbar_bgcolor3 = '#fc3';
my $topbar_style = 'experimental';
</%init>
which lets me make large changes by tweaking variables rather than making
multiple changes throughout a css file. In this case the source file mtime
is exactly what you want.
> Approach:
> We generate that CSS rules page properly using the values from those
> user_settings fields.
> Now we're to set the "Last-Modified" header:
> <%perl>
> my @mtimes = (
> $user->settings->last_updated->epoch,
> ( stat $m->current_comp->source_file )[9],
> # ... mtime of other data involved in generating the output ...
> );
> $r->set_last_modified( max @mtimes );
> </%perl>
The main part of your response I found useful was this:
> >> For setting modification headers, use "set_last_modified", "set_etag"
> >> AND "set_content_length". Also, using the "Vary" header properly will be
> >> very helpful.
Can you give me an example of how one would use the etag, content_length,
and vary headers in this case?
Cheers,
Gavin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
