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 AM, Thomas Rabaix <[email protected]> wrote: > 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, Aug 27, 2010 at 1:56 AM, Benoit Pr <[email protected]>wrote: > >> 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 >> /apostrophePlugin/css/a-forms.css >> /apostrophePlugin/css/a-buttons.css >> /apostrophePlugin/css/a-navigation.css >> /apostrophePlugin/css/a-components.css >> /apostrophePlugin/css/a-area-slots.css >> /apostrophePlugin/css/a-engines.css >> /apostrophePlugin/css/a-admin.css >> /apostrophePlugin/css/a-colors.css >> /apostrophePlugin/js/aUI.js >> /apostrophePlugin/js/aControls.js >> /apostrophePlugin/js/plugins/jquery.autogrow.js >> /apostrophePlugin/js/plugins/jquery.keycodes-0.2.js >> /apostrophePlugin/js/plugins/jquery.timer-1.2.js >> /apostrophePlugin/js/a.js >> >> How do disable the call to thoses files? >> >> Thanks by advance, >> >> On 18 août, 16:34, Stéphane <[email protected]> wrote: >> > Done :http://trac.apostrophenow.org/ticket/533 >> > >> > <http://trac.apostrophenow.org/ticket/533>Cheers, >> > >> > 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 <[email protected]> wrote: >> > > 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 <[email protected]> wrote: >> > > > +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 >> > > > <[email protected]>wrote: >> > >> > > > > Mhm, I somehow I knew that this would have been toooo 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 need for that matter – manual cache >> invalidation >> > > > > because we could send the far future Expires header everytime. If >> files >> > > in >> > > > > that bundle change, clear the files (not necessarily with a >> brute-force >> > > > > symfony cc) and they are rebuilt on the next page refresh. Maybe >> we >> > > could >> > > > > provide a apostrophe:clear-minified-resources [--js] [--css] >> [--all] >> > > > > [--env="dev|prod|staging"] task so as to not need the brute-force >> > > symfony cc >> > > > > or go hunting for these minified files manually? >> > >> > > > > Cheers, Daniel >> > >> > > > > On 17.08.2010, at 15:32, Tom Boutell wrote: >> > >> > > > > > 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 of that again (everything except actually >> writing the >> > > > > > file) just to figure out what the filename is. (: >> > >> > > > > > Opening all of the files, slurping them in and md5'ing them on >> every >> > > > > > page access is overhead we do not want. So it makes more sense >> to >> > > have >> > > > > > a cache key. >> > >> > > > > > On Aug 16, 9:13 am, Daniel Lohse <[email protected]> >> > > wrote: >> > > > > >> 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 file because it doesn't about that file yet (filename is not >> the >> > > same). >> > >> > > > > >> Am I missing something here? >> > >> > > > > >> Cheers, Daniel >> > >> > > > > >> Sent from my iPad >> > >> > > > > >> On Aug 16, 2010, at 2:59 PM, Tom Boutell <[email protected]> >> wrote: >> > >> > > > > >>> 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 even be possible to avoid the filesystem hit by writing >> it >> > > as a >> > > > > >>> PHP file in cache/frontend/prod/config that just calls >> > > > > >>> sfConfig::set(). Then with any luck it would be autoloaded and >> even >> > > > > >>> cached by APC until its modification date changes just like an >> > > app.yml >> > > > > >>> setting would. But plain old file_get_contents() calls to a >> simple >> > > > > >>> file with an asset cache version number in it would also get >> cached >> > > > > >>> nicely by the operating system so it might be overkill to try >> to >> > > wedge >> > > > > >>> it into Symfony's cache. >> > >> > > > > >>> On Aug 15, 11:44 am, pghoratiu <[email protected]> wrote: >> > > > > >>>>> 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 are using unminimized, uncombined CSS >> and JS >> > > and >> > > > > >>>>> has no negative impact on your existing caching issues, but >> we'll >> > > > > >>>>> think about next steps. >> > >> > > > > >>>> ==== >> > > > > >>>> I think think it's important to add cache invalidation as >> well. My >> > > > > >>>> suggestion is to append another key >> > > > > >>>> to app.yml to have a cache key that can be updated manually >> and >> > > append >> > > > > >>>> that key too the minified resource >> > > > > >>>> file: >> > > > > >>>> all: >> > > > > >>>> a: >> > > > > >>>> ver:1 >> > > > > >>>> css/main.css?ver=1 >> > > > > >>>> This way css and js pages can be cached indefinitely on the >> client >> > > > > >>>> side without having problems when manually >> > > > > >>>> updating the css or js files. >> > >> > > > > >>>> gabriel >> > >> > > > > >>> -- >> > > > > >>> If you want to report a vulnerability issue on symfony, please >> send >> > > it >> > > > > to security at symfony-project.com >> > >> > > > > >>> You received this message because you are subscribed to the >> Google >> > > > > >>> Groups "symfony users" group. >> > > > > >>> To post to this group, send email to >> > > [email protected] >> > > > > >>> To unsubscribe from this group, send email to >> > > > > >>> [email protected]<symfony-users%[email protected]> >> <symfony-users%2bunsubscr...@goog legroups.com> >> > > <symfony-users%[email protected]<symfony-users%[email protected]><symfony-users%252Bunsubscribe >> @googlegroups.com> >> > >> > > > > >>> For more options, visit this group at >> > > > > >>>http://groups.google.com/group/symfony-users?hl=en >> > >> > > > > > -- >> > > > > > If you want to report a vulnerability issue on symfony, please >> send >> > > it to >> > > > > security at symfony-project.com >> > >> > > > > > You received this message because you are subscribed to the >> Google >> > > > > > Groups "symfony users" group. >> > > > > > To post to this group, send email to >> [email protected] >> > > > > > To unsubscribe from this group, send email to >> > > > > > [email protected]<symfony-users%[email protected]> >> <symfony-users%2bunsubscr...@goog legroups.com> >> > > <symfony-users%[email protected]<symfony-users%[email protected]><symfony-users%252Bunsubscribe >> @googlegroups.com> >> > >> > > > > > For more options, visit this group at >> > > > > >http://groups.google.com/group/symfony-users?hl=en >> > >> > > > > -- >> > > > > If you want to report a vulnerability issue on symfony, please >> send it >> > > to >> > > > > security at symfony-project.com >> > >> > > > > You received this message because you are subscribed to the Google >> > > > > Groups "symfony users" group. >> > > > > To post to this group, send email to >> [email protected] >> > > > > To unsubscribe from this group, send email to >> > > > > [email protected]<symfony-users%[email protected]> >> <symfony-users%2bunsubscr...@goog legroups.com> >> > > <symfony-users%[email protected]<symfony-users%[email protected]><symfony-users%252Bunsubscribe >> @googlegroups.com> >> > >> > > > > For more options, visit this group at >> > > > >http://groups.google.com/group/symfony-users?hl=en >> > >> > > -- >> > > If you want to report a vulnerability issue on symfony, please send it >> to >> > > security at symfony-project.com >> > >> > > You received this message because you are subscribed to the Google >> > > Groups "symfony users" group. >> > > To post to this group, send email to [email protected] >> > > To unsubscribe from this group, send email to >> > > [email protected]<symfony-users%[email protected]> >> <symfony-users%2bunsubscr...@goog legroups.com> >> > > For more options, visit this group at >> > >http://groups.google.com/group/symfony-users?hl=en >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<symfony-users%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > > > -- > Thomas Rabaix > http://rabaix.net > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
