Hi all. Currently, rails 2.3 engines can''t have (or override) static files in their own public/ directory like they do with views, controllers, etc. Recently playing with rack, I implemented the following middleware: http://gist.github.com/175518 As you can see, in environment.rb the middleware gets initialized with the asset directories (which exists) from loaded plugins (may be there is a way to check if those are engines?) The middleware sees if the requested file is in one of the engines providing a public/ directory. The first one that matches is returned (an overlay just like the other components of engines work), if not, the request is just passed to the application. This feature is really useful. Now that I see how easy was to implement, I wonder if it is a valid solution, and if the concept could be used to add support in Rails itself for this, or if you guys see a problem with this approach? Thanks Duncan
I guess one drawback here is that the engine assets won''t be delivered directly by the frontend server, causing a hit (although a cheap one) to the application, no? Do you have a cache layer in front of this? On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote:> > Hi all. > > Currently, rails 2.3 engines can''t have (or override) static files in > their own public/ directory like they do with views, controllers, etc. > > Recently playing with rack, I implemented the following middleware: > > http://gist.github.com/175518 > > As you can see, in environment.rb the middleware gets initialized with > the asset directories (which exists) from loaded plugins (may be there > is a way to check if those are engines?) > > The middleware sees if the requested file is in one of the engines > providing a public/ directory. The first one that matches is returned > (an overlay just like the other components of engines work), if not, > the request is just passed to the application. > > This feature is really useful. Now that I see how easy was to > implement, I wonder if it is a valid solution, and if the concept > could be used to add support in Rails itself for this, or if you guys > see a problem with this approach? > > Thanks > Duncan > > >
One of the approaches I saw used in an old attachment plugin - don''t remember which one - was to check this in an asset tag helper. The helper in this case could ne patched to return an engine override if one exists, which would allow the frontend to continue serving the assets. -Matt On 30 Aug 2009, at 13:18, Sven Fuchs <svenfuchs@artweb-design.de> wrote:> > I guess one drawback here is that the engine assets won''t be delivered > directly by the frontend server, causing a hit (although a cheap one) > to the application, no? Do you have a cache layer in front of this? > > On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote: > >> >> Hi all. >> >> Currently, rails 2.3 engines can''t have (or override) static files in >> their own public/ directory like they do with views, controllers, >> etc. >> >> Recently playing with rack, I implemented the following middleware: >> >> http://gist.github.com/175518 >> >> As you can see, in environment.rb the middleware gets initialized >> with >> the asset directories (which exists) from loaded plugins (may be >> there >> is a way to check if those are engines?) >> >> The middleware sees if the requested file is in one of the engines >> providing a public/ directory. The first one that matches is returned >> (an overlay just like the other components of engines work), if not, >> the request is just passed to the application. >> >> This feature is really useful. Now that I see how easy was to >> implement, I wonder if it is a valid solution, and if the concept >> could be used to add support in Rails itself for this, or if you guys >> see a problem with this approach? >> >> Thanks >> Duncan >> >>> > > > >
How about a task ran after a (theoretical) script/engine install? This task would copy assets from public/[images|stylesheets|javascripts]/engine-name in an engine and then put them in the relevant directories in public. You''d then still get them accessible, but without the performance hit. public/images/engine-name would end up in the same spot, so you then can do <%= image_tag "engine-name/image" %> still to get access. I think this would also solve the (potential) problem of apps and engines having identically named files. 2009/8/30 Matthew MacLeod <matt@theskinny.co.uk>> > One of the approaches I saw used in an old attachment plugin - don''t > remember which one - was to check this in an asset tag helper. The > helper in this case could ne patched to return an engine override if > one exists, which would allow the frontend to continue serving the > assets. > > -Matt > > On 30 Aug 2009, at 13:18, Sven Fuchs <svenfuchs@artweb-design.de> wrote: > > > > > I guess one drawback here is that the engine assets won''t be delivered > > directly by the frontend server, causing a hit (although a cheap one) > > to the application, no? Do you have a cache layer in front of this? > > > > On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote: > > > >> > >> Hi all. > >> > >> Currently, rails 2.3 engines can''t have (or override) static files in > >> their own public/ directory like they do with views, controllers, > >> etc. > >> > >> Recently playing with rack, I implemented the following middleware: > >> > >> http://gist.github.com/175518 > >> > >> As you can see, in environment.rb the middleware gets initialized > >> with > >> the asset directories (which exists) from loaded plugins (may be > >> there > >> is a way to check if those are engines?) > >> > >> The middleware sees if the requested file is in one of the engines > >> providing a public/ directory. The first one that matches is returned > >> (an overlay just like the other components of engines work), if not, > >> the request is just passed to the application. > >> > >> This feature is really useful. Now that I see how easy was to > >> implement, I wonder if it is a valid solution, and if the concept > >> could be used to add support in Rails itself for this, or if you guys > >> see a problem with this approach? > >> > >> Thanks > >> Duncan > >> > >>> > > > > > > > > > > >-- Ryan Bigg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
The engines plugin already does this; each time the server started up it copies whatever is in engine-name/assets into public/plugin_assets/ engine-name, and it adds a :plugin option to stylesheet_link_tag, javascript_include_tag, image_path and image_tag, so you call image_tag "image" :plugin => "engine-name" to access "image" for that plugin. see http://github.com/lazyatom/engines/blob/bc5cd970e048dfe5e0e8c06ccf4969bd0d1299be/lib/engines/rails_extensions/asset_helpers.rb On 30-Aug-09, at 8:27 PM, Ryan Bigg (Radar) wrote:> How about a task ran after a (theoretical) script/engine install? > > This task would copy assets from public/[images|stylesheets| > javascripts]/engine-name in an engine and then put them in the > relevant directories in public. You''d then still get them > accessible, but without the performance hit. public/images/engine- > name would end up in the same spot, so you then can do <%= image_tag > "engine-name/image" %> still to get access. I think this would also > solve the (potential) problem of apps and engines having identically > named files. > > > 2009/8/30 Matthew MacLeod <matt@theskinny.co.uk> > > One of the approaches I saw used in an old attachment plugin - don''t > remember which one - was to check this in an asset tag helper. The > helper in this case could ne patched to return an engine override if > one exists, which would allow the frontend to continue serving the > assets. > > -Matt > > On 30 Aug 2009, at 13:18, Sven Fuchs <svenfuchs@artweb-design.de> > wrote: > > > > > I guess one drawback here is that the engine assets won''t be > delivered > > directly by the frontend server, causing a hit (although a cheap > one) > > to the application, no? Do you have a cache layer in front of this? > > > > On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote: > > > >> > >> Hi all. > >> > >> Currently, rails 2.3 engines can''t have (or override) static > files in > >> their own public/ directory like they do with views, controllers, > >> etc. > >> > >> Recently playing with rack, I implemented the following middleware: > >> > >> http://gist.github.com/175518 > >> > >> As you can see, in environment.rb the middleware gets initialized > >> with > >> the asset directories (which exists) from loaded plugins (may be > >> there > >> is a way to check if those are engines?) > >> > >> The middleware sees if the requested file is in one of the engines > >> providing a public/ directory. The first one that matches is > returned > >> (an overlay just like the other components of engines work), if > not, > >> the request is just passed to the application. > >> > >> This feature is really useful. Now that I see how easy was to > >> implement, I wonder if it is a valid solution, and if the concept > >> could be used to add support in Rails itself for this, or if you > guys > >> see a problem with this approach? > >> > >> Thanks > >> Duncan > >> > >>> > > > > > > > > > > > > > -- > Ryan Bigg > > >
I''d prefer it if:1) assets were put in the relevant directories, rather than "polluting" the public directory with more folders. So all images for an engine would go in public/images/engine-name rather than public/engine-name/images. 2) People just did image_tag "engine-name/image", as it''s shorter and I''m all for laziness. 2009/8/31 Mateo Murphy <mateo.murphy@gmail.com>> > The engines plugin already does this; each time the server started up > it copies whatever is in engine-name/assets into public/plugin_assets/ > engine-name, and it adds > a :plugin option to stylesheet_link_tag, javascript_include_tag, > image_path and image_tag, so you call image_tag "image" :plugin => > "engine-name" to access "image" for that plugin. > > see > http://github.com/lazyatom/engines/blob/bc5cd970e048dfe5e0e8c06ccf4969bd0d1299be/lib/engines/rails_extensions/asset_helpers.rb > > On 30-Aug-09, at 8:27 PM, Ryan Bigg (Radar) wrote: > > > How about a task ran after a (theoretical) script/engine install? > > > > This task would copy assets from public/[images|stylesheets| > > javascripts]/engine-name in an engine and then put them in the > > relevant directories in public. You''d then still get them > > accessible, but without the performance hit. public/images/engine- > > name would end up in the same spot, so you then can do <%= image_tag > > "engine-name/image" %> still to get access. I think this would also > > solve the (potential) problem of apps and engines having identically > > named files. > > > > > > 2009/8/30 Matthew MacLeod <matt@theskinny.co.uk> > > > > One of the approaches I saw used in an old attachment plugin - don''t > > remember which one - was to check this in an asset tag helper. The > > helper in this case could ne patched to return an engine override if > > one exists, which would allow the frontend to continue serving the > > assets. > > > > -Matt > > > > On 30 Aug 2009, at 13:18, Sven Fuchs <svenfuchs@artweb-design.de> > > wrote: > > > > > > > > I guess one drawback here is that the engine assets won''t be > > delivered > > > directly by the frontend server, causing a hit (although a cheap > > one) > > > to the application, no? Do you have a cache layer in front of this? > > > > > > On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote: > > > > > >> > > >> Hi all. > > >> > > >> Currently, rails 2.3 engines can''t have (or override) static > > files in > > >> their own public/ directory like they do with views, controllers, > > >> etc. > > >> > > >> Recently playing with rack, I implemented the following middleware: > > >> > > >> http://gist.github.com/175518 > > >> > > >> As you can see, in environment.rb the middleware gets initialized > > >> with > > >> the asset directories (which exists) from loaded plugins (may be > > >> there > > >> is a way to check if those are engines?) > > >> > > >> The middleware sees if the requested file is in one of the engines > > >> providing a public/ directory. The first one that matches is > > returned > > >> (an overlay just like the other components of engines work), if > > not, > > >> the request is just passed to the application. > > >> > > >> This feature is really useful. Now that I see how easy was to > > >> implement, I wonder if it is a valid solution, and if the concept > > >> could be used to add support in Rails itself for this, or if you > > guys > > >> see a problem with this approach? > > >> > > >> Thanks > > >> Duncan > > >> > > >>> > > > > > > > > > > > > > > > > > > > > > > -- > > Ryan Bigg > > > > > > > > > >-- Ryan Bigg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
In our experience copying assets sucks bad. At least on *nix systems it should just symlink them, or have a separate task for that. Obviously with copies when you work on your engine assets you * have to do that in the public/ folder and * then remember to sync stuff back to the engine when committing ... which is something you never have to think about anywhere else in Rails. We''ve lost changes this way a couple of times. :) On 31.08.2009, at 05:08, Ryan Bigg (Radar) wrote:> I''d prefer it if: > 1) assets were put in the relevant directories, rather than > "polluting" the public directory with more folders. So all images > for an engine would go in public/images/engine-name rather than > public/engine-name/images. > > 2) People just did image_tag "engine-name/image", as it''s shorter > and I''m all for laziness. > > 2009/8/31 Mateo Murphy <mateo.murphy@gmail.com> > > The engines plugin already does this; each time the server started up > it copies whatever is in engine-name/assets into public/plugin_assets/ > engine-name, and it adds > a :plugin option to stylesheet_link_tag, javascript_include_tag, > image_path and image_tag, so you call image_tag "image" :plugin => > "engine-name" to access "image" for that plugin. > > see http://github.com/lazyatom/engines/blob/bc5cd970e048dfe5e0e8c06ccf4969bd0d1299be/lib/engines/rails_extensions/asset_helpers.rb > > On 30-Aug-09, at 8:27 PM, Ryan Bigg (Radar) wrote: > > > How about a task ran after a (theoretical) script/engine install? > > > > This task would copy assets from public/[images|stylesheets| > > javascripts]/engine-name in an engine and then put them in the > > relevant directories in public. You''d then still get them > > accessible, but without the performance hit. public/images/engine- > > name would end up in the same spot, so you then can do <%= image_tag > > "engine-name/image" %> still to get access. I think this would also > > solve the (potential) problem of apps and engines having identically > > named files. > > > > > > 2009/8/30 Matthew MacLeod <matt@theskinny.co.uk> > > > > One of the approaches I saw used in an old attachment plugin - don''t > > remember which one - was to check this in an asset tag helper. The > > helper in this case could ne patched to return an engine override if > > one exists, which would allow the frontend to continue serving the > > assets. > > > > -Matt > > > > On 30 Aug 2009, at 13:18, Sven Fuchs <svenfuchs@artweb-design.de> > > wrote: > > > > > > > > I guess one drawback here is that the engine assets won''t be > > delivered > > > directly by the frontend server, causing a hit (although a cheap > > one) > > > to the application, no? Do you have a cache layer in front of > this? > > > > > > On 26.08.2009, at 16:07, Duncan Mac-Vicar P. wrote: > > > > > >> > > >> Hi all. > > >> > > >> Currently, rails 2.3 engines can''t have (or override) static > > files in > > >> their own public/ directory like they do with views, controllers, > > >> etc. > > >> > > >> Recently playing with rack, I implemented the following > middleware: > > >> > > >> http://gist.github.com/175518 > > >> > > >> As you can see, in environment.rb the middleware gets initialized > > >> with > > >> the asset directories (which exists) from loaded plugins (may be > > >> there > > >> is a way to check if those are engines?) > > >> > > >> The middleware sees if the requested file is in one of the > engines > > >> providing a public/ directory. The first one that matches is > > returned > > >> (an overlay just like the other components of engines work), if > > not, > > >> the request is just passed to the application. > > >> > > >> This feature is really useful. Now that I see how easy was to > > >> implement, I wonder if it is a valid solution, and if the concept > > >> could be used to add support in Rails itself for this, or if you > > guys > > >> see a problem with this approach? > > >> > > >> Thanks > > >> Duncan > > >> > > >>> > > > > > > > > > > > > > > > > > > > > > > -- > > Ryan Bigg > > > > > > > > > > > > -- > Ryan Bigg > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Aug 31, 8:11 am, Sven Fuchs <svenfu...@artweb-design.de> wrote:> In our experience copying assets sucks bad. At least on *nix systems > it should just symlink them, or have a separate task for that.Yes, and I also think it may work for a "deployed" web application. But we are developing a remote configuration tool which is "packaged" and therefore having the application to modify the public/ directory is no option. Duncan