I am fine with a new task, but I just thought that the semantics are similar. The cache, although not built autmatically for web assets is in the web directory, while the "uncached" version is in the plugin directory.
something like "reload assets"? .: Fabian On Thu, Jul 3, 2008 at 8:44 AM, Fabien Potencier < [EMAIL PROTECTED]> wrote: > > I think it's a good idea to create a task for that, but I'm not sure we > want to do it in the cache:clear task. It has nothing to do with > clearind the cache and on windows, it will add a large overhead if you > have a lot of plugins with a lot of assets to be copied to the web/ > directory. > > What about creating a new task? > > Fabien > > -- > Fabien Potencier > Sensio CEO - symfony lead developer > sensiolabs.com | symfony-project.com | aide-de-camp.org > Tél: +33 1 40 99 80 80 > > > Fabian Lange wrote: > > Hi everybody, > > yesterday I moved the current Javascript stuff to a plugin, and didn't > > notice an error that comes up on my new machine: The Javascript assets > > are missing. I didn't notice it yesterday, because my /sf alias in the > > htaccess was still there (but pointing to an 1.0 release :-)) > > Currently plugins will copy their assets on windows when using the > > plugin installation, while un *nix systems it tries a symlink. > > But there is no installation for core plugins. > > This made me come up with a new idea: > > We enhance the clear-cache task in a way, that it deletes the plugins > > asset directory in web folder and then recollects all assets from > > symfony core, symfony core plugins and optional plugis that are > > installed and copies them over. > > > > The pros are that this would work quite easily and help my current issue, > > It would avoid some of the trac tickets that delt with plugin assets in > > windows, > > it would also help updating plugins that you get via svn (where the > > assets are a manual step at the moment) > > > > The cons are limited, at the moment I can see only backwards > > compatibility issues with regard to how the actual path to the JS/CSS is > > used in the plugins, but I guess with some deeper investigations this > > can be solved. > > A slightly less BC problematic solution would be to do that only for > > core plugins. The advantage of that wold be that the path is known (its > > the sf prefixed one) , but it looks a bit inconsistent for me. > > > > As Jonathan is currently working on the deploy task, we could try to > > think about implications of the old and the new behaviour for deploying. > > Afaik the symlink recreation on deployment was also an issue in the past. > > > > Hope you have some good inputs. > > > > @Fabien, any other idea how to solve the data directory issue for core > > plugins? > > > > .: Fabian > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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-devs?hl=en -~----------~----~----~----~------~----~------~--~---
