Fabian Lange wrote:
> Okay, valid point.
> If I would make such a task, could we integrate it into the plugin 
> installation procedure?
> Would we need two versions of this Task then? One that installs all, and 
> on that installs only for the given plugin?

You only need one task with one optional argument.

If you provide an argument, this is the plugin for which you want to 
install/fix web assets.

With no argument, you want to install/fix web assets for all plugins.

> 
> Does anyone see a problem replacing the current plugin web asset 
> procedure with this?

You don't really replace the current procedure. You refactor the 
existing code by extracting the web asset part to make a new task and 
call it from the old code.

Fabien

> .: Fabian
> 
> On Thu, Jul 3, 2008 at 12:07 PM, markus.staab <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> 
>     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]
>     <mailto:[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]
>     <mailto:[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 <http://sensiolabs.com> | symfony-project.com
>     <http://symfony-project.com> | aide-de-camp.org
>     <http://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
-~----------~----~----~----~------~----~------~--~---

Reply via email to