Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing the Rails Controller and refactor into middleware #251

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mulderp
Copy link

@mulderp mulderp commented Jul 8, 2013

By using Rack middleware, we would allow easier integration of Jammit into non-Rails projects and addresses #161

The basic approach here is using a Rack::Request and extract path_info from there, package the assets with Jammit, and wrap it into a Rack::Response.

I was looking into Rack::Sprockets and Warden for some inspiration on the topic (incl. use of RSpec).

It would be great to hear your feedback what you think.

My first thought was also to rename the Controller into Manager or Packager, to avoid confusion with a Rails or Backbone controller.

The request-response can be tested with:

 bundle exec rspec spec/jammit/controller_spec.rb

@mulderp
Copy link
Author

mulderp commented Jul 8, 2013

This PR is mainly for discussion, it is not yet functional.

@jashkenas
Copy link
Member

Sounds like a decent enough idea in general -- but there are Rails-specfic things that Jammit needs to take advantage of, which simply aren't defined in Rack (AFAIK).

For example, Jammit needs to provide helpers so that you can include correctly generated script and style resources. For another, Jammit needs to access the correct rails ASSET_ID, or similar.

@mulderp
Copy link
Author

mulderp commented Jul 9, 2013

Hmm.. interesting, I didn't think too much on the view helpers. Would it make sense / possible to support these from a separate Railtie?

I was thinking that the use case of asset management was: When hitting the '/assets' path, then build/precompile the requested assets from the path info. From many smaller projects (non-Rails), it is often enough to serve one app.js that is build from smaller files. I will think about this problem for larger projects, but maybe others have some ideas how to address this with a Rack solution too.

@mulderp
Copy link
Author

mulderp commented Jul 10, 2013

A 2-layer approach like Warden/Devise, for jammit-rack/jammit might be nice.

I am just asking myself how jammit-rack would look like in development mode for a non-rails project. Packaging/Compressing assets might be skipped, but this would make the '/assets' middleware rather a static file server. Having a way to load multiple files like require.js allows with main.js might be nice, but not sure.

Anyone here sees use cases for Jammit-Rack for development mode?

@mulderp
Copy link
Author

mulderp commented Jul 11, 2013

Ok, just as a note that it might be possible to move the view helper code into the Rack layer too, similar to rack-livereload where some new tags are inserted in the header: https://github.com/johnbintz/rack-livereload/blob/master/lib/rack/livereload.rb#L27-L36

@mulderp
Copy link
Author

mulderp commented Jul 12, 2013

Update: I added a small test app for a Rack based Jammit approach here: https://github.com/mulderp/jammit_test/blob/master/config.ru

Also, scanning through the header with a regex and append the dependencies seems to work in principle.

@mulderp
Copy link
Author

mulderp commented Jul 25, 2013

this overview on a node based middleware solution looks interesting in this context: http://blog.ponyfoo.com/2013/07/22/upgraded-asset-management

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants