Changing the way plugins provide web assets - symfony developers

Message from discussion Changing the way plugins provide web assets
Received-SPF: neutral (google.com: 72.14.220.152 is neither permitted nor denied by best guess record for domain of fabien.potenc...@symfony-project.com) client-ip=72.14.220.152;
Message-ID: <486C754A.3000409@symfony-project.com>
Date: Thu, 03 Jul 2008 08:44:26 +0200
From: Fabien Potencier <fabien.potenc...@symfony-project.com>
Organization: symfony
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
To: symfony-devs@googlegroups.com
Subject: Re: [symfony-devs] Changing the way plugins provide web assets
References: <21b6c1320807022319s4c228724o620d2c78ccddc5ba@mail.gmail.com>
In-Reply-To: <21b6c1320807022319s4c228724o620d2c78ccddc5ba@mail.gmail.com>

I think it's a good idea to create a task for that, but I'm not sure we=20
want to do it in the cache:clear task. It has nothing to do with=20
clearind the cache and on windows, it will add a large overhead if you=20
have a lot of plugins with a lot of assets to be copied to the web/=20
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=E9l: +33 1 40 99 80 80


Fabian Lange wrote:
> Hi everybody,
> yesterday I moved the current Javascript stuff to a plugin, and didn't=20
> notice an error that comes up on my new machine: The Javascript assets=20
> are missing. I didn't notice it yesterday, because my /sf alias in the=20
> htaccess was still there (but pointing to an 1.0 release :-))
> Currently plugins will copy their assets on windows when using the=20
> 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=20
> asset directory in web folder and then recollects all assets from=20
> symfony core, symfony core plugins and optional plugis that are=20
> installed and copies them over.
>=20
> 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=20
> windows,
> it would also help updating plugins that you get via svn (where the=20
> assets are a manual step at the moment)
>=20
> The cons are limited, at the moment I can see only backwards=20
> compatibility issues with regard to how the actual path to the JS/CSS is=
=20
> used in the plugins, but I guess with some deeper investigations this=20
> can be solved.
> A slightly less BC problematic solution would be to do that only for=20
> core plugins. The advantage of that wold be that the path is known (its=20
> the sf prefixed one) , but it looks a bit inconsistent for me.
>=20
> As Jonathan is currently working on the deploy task, we could try to=20
> think about implications of the old and the new behaviour for deploying.=
=20
> Afaik the symlink recreation on deployment was also an issue in the past.
>=20
> Hope you have some good inputs.
>=20
> @Fabien, any other idea how to solve the data directory issue for core=20
> plugins?
>=20
> .: Fabian
>=20
>=20
> >=20