Best practice for use with rails 3.1 about sprite-factory HOT 6 CLOSED

I haven't had a chance to use rails 3.1 yet. I'll try to look into it shortly, but until then here is some vague rambling thoughts off the top of my head...

Normally, I would suggest a Rake task that uses the sprite factory API. For example, at liquidplanner.com we use something like this:

desc 'recreate sprite images and css'
task :resprite => :environment do 

  begin    
    require 'sprite_factory'
  rescue LoadError => e
    abort("You are missing the sprite-factory gem")
  end

  SpriteFactory.report = true
  SpriteFactory.csspath = "<%= image_path 'sprites/$IMAGE' %>" # we post process our CSS with ERB in order to get correct cache busting URL's in our sprites

  SpriteFactory.run!('public/images/sprites/icons',          :layout => :packed)
  SpriteFactory.run!('public/images/sprites/medium_icons',   :layout => :packed,     :selector => 'img.medium_icon_')
  SpriteFactory.run!('public/images/sprites/import',         :layout => :vertical,   :selector => 'img.import_icon_')
  SpriteFactory.run!('public/images/sprites/message_icons',  :layout => :horizontal, :selector => 'img.message_icon_')
  SpriteFactory.run!('public/images/sprites/details_pane',   :layout => :horizontal, :selector => 'img.details_pane_icon_')
  SpriteFactory.run!('public/images/sprites/timesheet',      :layout => :horizontal, :selector => 'img.timesheet_icon_')

  # ... etc ...

end

Then a separate tool, such as sprockets, might include/require the generated css file in 1 large unified css file for your application (at liquidplanner.com we have a home grown UnifiedAssets gem that is much like the upcoming sprockets 2 stuff)

Since the location of assets are changing in Rails 3.1 it might be a good idea to extend the sprite factory with an option to specify a location for the output CSS file independent of the location that the output .PNG gets created in so that you can place them into a location that sprockets will automatically pick up (e.g. app/assets/stylesheets - or whatever it ends up in 3.1)

Going a step further, the sprite-factory gem could, in theory, be integrated into the rails 3.1 asset pipeline to automagically resprite whenever the source images are modified, maybe based off a config file (instead of a hard coded Rake tasks) but that would take a bit more thought.

If I get some time soon I'll try to take a closer look at how sprite-factory might work with the rails 3.1 asset pipeline.

from sprite-factory.

I released a new version of sprite-factory (1.4.1) which has better support for working with the Rails 3.1 asset pipeline.

You can read more about it on my blog

I also pushed a working example to github

Hope this helps!

from sprite-factory.

@jakesgordon Great, thanks for you really fast feedback.

As I didn't expect your feedback (with a working new gem) so early and desperately needed that feature, I worked on a solution on my own. My approach is a little different to yours as I dont have a new rake task for generating the sprites but instead tried to write a customer sass importer. This way you can simply do a @import "sprites:icons" in your sass files and it'd automatically regenerate all needed assets if the current ones are outdated when the stylesheet gets loaded. It should work without any problems (and it does with some workarounds), if there weren't two bugs in sass-rails which make some troubles: rails/sass-rails#25 rails/sass-rails#26. If you like my approach I could share my code with you... :)

from sprite-factory.

Sure I'd be interested in taking a look at your code.

I think that sounds like a good next step. My last update was really just minimal amount to play nice with the new rails 3.1 asset locations. The next step would probably be along the lines of your simple import/include that automatically resprited at run-time.

Although I'd probably want to hook it somewhere into the sprockets //*= require mechanism so that it would support both css and sass, it would also need some way to accept some kind of parameterization (or maybe it could read a config file).

Something like, in application.css/scss

//*= require "sprites/icons", :selector => "img.icon_", :width => 45, :height => 45, :etc => 'etc'

or, ideally

//*= resprite "icons", :selector => "img.icon_", :width => 45, :height => 45, :etc => 'etc'

Having said that, I think the need for auto-regeneration is a lot less with sprites than with unified css/js files. In development we are constantly editing the css/js and expect those changes to appear when we refresh the browser, but dropping in a new image that needs to go into a sprite-sheet is a much rarer event, and you're unlikely to want to generate different versions for production than development, so you can usually resprite once in a dev environment and check your generated image/css files into source control.

Having to run a rake assets:resprite is probably an acceptable workflow for most cases.

from sprite-factory.

Hi i saw demo project, and it's good to understand and to fast start. But i also saw that sprite support also available at compass. Can you tell pros and cons of both gems?

Sorry for bad English.

from sprite-factory.

Sorry for late reply (I've been offline this week).

I haven't used compass myself, so I can't really give you a fair comparison. I think compass is much more than just css sprite generation - its more of an extension to sass (which itself is an extension to css) providing a framework for simpler html & css generation overall.

The sprite-factory gem only has a single purpose its purely to generate the stylesheet image and css for use in an application that does not already have that functionality.

Certainly if you are already using Compass, and it provides the features you need you should continue to use it.

Sorry I couldn't give you more detail. I plan to look deeper at compass one day but haven't had the need yet!

• Jake

from sprite-factory.