i also think a new task would be the better way... because if people edit the assets in their webfolder and start the clear-cache task all the custom code would be overriden by the default assets
On 3 Jul., 08:48, "Fabian Lange" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
