Hello,
Sorry to hijack this thread, but If you are looking for a way to combine
asset (js and css) you *really* have to look at this plugin :
http://github.com/rande/swCombinePlugin/blob/master/README.md
The main advantage is that no computation is done at runtime, but through a
task.
On Fri,
Hi,
We sometime need to combine js and css depending on runtime things, so its
better handled this way I think.
Thank you !
Cheers,
Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
On Fri, Aug 27, 2010 at 10:53
Hi,
I just implemented this plugin, which seems very interesting (1.4
compatible also).
However, when i use a_include*, I am collecting js and css which are
not in my project, like these one for example:
/apostrophePlugin/css/a-reset.css
/apostrophePlugin/css/a-utility.css
I should probably just store the information via sfCache and allow
sfAPCCache etc. to be plugged in as an alternative to the default
sfFileCache to avoid overhead rather than being cute about it...
On Aug 17, 9:39 am, Stéphane stephane.er...@gmail.com wrote:
I didn't took a look at the
A specific task would be convenient for those who consider 'symfony
cc' too heavy, and I could still invoke it automatically from a
'symfony cc' hook. Would you mind opening a ticket on
trac.apostrophenow.org to remind me to look at this?
On Aug 17, 9:54 am, Stéphane stephane.er...@gmail.com
Done : http://trac.apostrophenow.org/ticket/533
http://trac.apostrophenow.org/ticket/533Cheers,
Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
On Wed, Aug 18, 2010 at 3:24 PM, Tom Boutell t...@punkave.com
Daniel, this almost works and I got pretty excited thinking about
it... but there's a tragic flaw.
On the first page access you slurp up all the CSS files, minify them,
md5 that and create a cache file. Fine.
On the second page access you... can't point to the cache file without
first doing all
I didn't took a look at the implementation yet.
PHP is caching filesystem infos AFAIK.
Can't we use these file informations as part of the key cache to compute md5
? So their will be no more need to invalidate, it will invalidate by itself,
or by calling (for hard-writting apps) clearstatcache()
Mhm, I somehow I knew that this would have been t easy. (:
But okay, so we do need to cache these relations array(bundle = sha1sum.ccsgz)
somewhere it gets loaded on every request and I'd guess the app.yml.php file is
a good place. Still, using this approach does not necessitate – or even
+1 for the specific task !
Before Printing, Think about Your Environmental Responsibility!
Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale!
On Tue, Aug 17, 2010 at 3:52 PM, Daniel Lohse
annismcken...@googlemail.comwrote:
Mhm, I somehow I knew that this would have been
You're right, we do need cache invalidation. I just came up with a
clean way to do it without tweaking app.yml settings, adding a table
or making glob() calls: just use a file in the asset-cache folder to
hold the current cache key. The OS should cache reads from that file
extremely well.
It may
I've opened a ticket on this:
http://trac.apostrophenow.org/ticket/529
I think manual updates are unnecessary, symfony cc can invalidate the
cache key, no muss no fuss (:
On Aug 15, 11:44 am, pghoratiu pghora...@gmail.com wrote:
It might be worthwhile to take things a step further by
Sorry for being a bit slow today: why would we need cache invalidation? If the
filename of the compacted file(s) is a hash generated from the contents of the
file then after one file changes and the scripts/stylesheets are re-generated
the filename changes. The browser then should just request
The cached versions are removed by 'symfony cc' and subsequently
regenerated by the next request. They are files in the web/uploads/
asset-cache folder, so they are not cached by the browser any more or
less aggressively than the original files in web/css, web/
apostrophePlugin/css, etc. would be.
I'm wondering what is going to happen in the following use case:
You got two pages A and B.
- Page A uses script C (10kb), and script D (20kb)
- Page B uses script D (20 kb), and script E (1kb)
Do you generate two different files for each page, or do you have any
heuristics to decide when to
It might be worthwhile to take things a step further by versioning
them in the URL so that they can be given an infinite cache expiration
date, although this requires a database hit or perhaps a glob call
when outputting the pages that contain them. The code is a big step
forward as-is if you
Hi!
How do you solve the cache invalidation for these resources (in case
they are cached on the client side)?
Please post also a link to the sources.
Thanks,
gabriel
On Aug 14, 5:08 pm, Tom Boutell t...@punkave.com wrote:
We've committed a new CSS and JS minifier to the trunk of
17 matches
Mail list logo
