4 ms·

Rack::ChromeFrame, easy Google Chrome Frame integration for Ruby apps

36 points by luigi 17y ago

tamersalama 17y ago
nice - but looks like it doesn't take into consideration the user agent. http://github.com/sunlightlabs/rack-chromeframe/blob/master/chrome_frame.rb http://github.com/sunlightlabs/rack-chromeframe/blob/master/...
- luigi 17y ago
  You're right, a check for User-Agent needs to be put in there.
judofyr 17y ago
Shouldn't this first check if Chrome Frame is actually used (by using the User-Agent header) before it injects the code? And why not just place the four lines straight into your layout?
- evdawg 17y ago
  I feel like a complete jerk for saying this (partly because Sunlight Labs is a non-profit), but it suffers from what I like to call the snippet marketing syndrome: 4 - 5 lines of code being fancied up into a 10 - 30 line "plugin" with heavy references to the consulting studio that 'coded' it.
  - judofyr 17y ago
    But, but, it's Rack! Everything related to Rack is awesome.
    - evdawg 17y ago
      I wonder what the overhead of doing this as Rack Middleware is versus just putting it into your layout. This is markup, it belongs in your layout files. You're really just disorganizing your app by putting this into middleware.
      - bts 17y ago
        I think the biggest disadvantage of putting something like this in middleware, is that it's completely incompatible with stuff like memcache. The injection of this meta-tag is done after a memcache SET would have been done in the web app, and so if you have a reverse proxy in front of your webserver, for any cached page that's served, it won't include the injection. Also, the user-agent check that's being done in this plugin yields incorrect results in the presence of caching for similar reasons.
  - luigi 17y ago
    The idea behind Rack middleware is that it's incredibly easy to implement for the developer and re-usable across the spectrum of Ruby web apps. Yes, implementing Google Chrome Frame in a given app is trivial. But removing this from the concern of a given app and into a re-usable middleware is where I think it's useful.
simonw 17y ago
This should check the Content-Type header and only modify text/html - otherwise it might mangle outgoing JavaScript / XML / etc files.
- luigi 17y ago
  Thanks, fix just pushed up.
petercooper 17y ago
Didn't use the plugin but used the code snippets on a site just to test it out and.. I think Google need to slicken it up a bit first. The installation overlay blocks out most of the site on IE6 and doesn't seem to be closable. I'm guessing this is really meant for sites that demand it be installed rather than an optional thing - but if that's true, why not just redirect?
- luigi 17y ago
  Peter, see the developer's comment here: http://groups.google.com/group/google-chrome-frame/browse_thread/thread/80f9488134473c9d/a27315d0c7085106 http://groups.google.com/group/google-chrome-frame/browse_th...
  - petercooper 17y ago
    Useful info - thanks.

36 points by luigi 17y ago

nice - but looks like it doesn't take into consideration the user agent. http://github.com/sunlightlabs/rack-chromeframe/blob/master/chrome_frame.rb http://github.com/sunlightlabs/rack-chromeframe/blob/master/...

luigi 17y ago
You're right, a check for User-Agent needs to be put in there.

judofyr 17y ago

Shouldn't this first check if Chrome Frame is actually used (by using the User-Agent header) before it injects the code? And why not just place the four lines straight into your layout?

evdawg 17y ago
I feel like a complete jerk for saying this (partly because Sunlight Labs is a non-profit), but it suffers from what I like to call the snippet marketing syndrome: 4 - 5 lines of code being fancied up into a 10 - 30 line "plugin" with heavy references to the consulting studio that 'coded' it.
- judofyr 17y ago
  But, but, it's Rack! Everything related to Rack is awesome.
  - evdawg 17y ago
    I wonder what the overhead of doing this as Rack Middleware is versus just putting it into your layout. This is markup, it belongs in your layout files. You're really just disorganizing your app by putting this into middleware.
    - bts 17y ago
      I think the biggest disadvantage of putting something like this in middleware, is that it's completely incompatible with stuff like memcache. The injection of this meta-tag is done after a memcache SET would have been done in the web app, and so if you have a reverse proxy in front of your webserver, for any cached page that's served, it won't include the injection. Also, the user-agent check that's being done in this plugin yields incorrect results in the presence of caching for similar reasons.
- luigi 17y ago
  The idea behind Rack middleware is that it's incredibly easy to implement for the developer and re-usable across the spectrum of Ruby web apps. Yes, implementing Google Chrome Frame in a given app is trivial. But removing this from the concern of a given app and into a re-usable middleware is where I think it's useful.

simonw 17y ago

This should check the Content-Type header and only modify text/html - otherwise it might mangle outgoing JavaScript / XML / etc files.

luigi 17y ago
Thanks, fix just pushed up.

petercooper 17y ago

Didn't use the plugin but used the code snippets on a site just to test it out and.. I think Google need to slicken it up a bit first. The installation overlay blocks out most of the site on IE6 and doesn't seem to be closable. I'm guessing this is really meant for sites that demand it be installed rather than an optional thing - but if that's true, why not just redirect?

luigi 17y ago
Peter, see the developer's comment here: http://groups.google.com/group/google-chrome-frame/browse_thread/thread/80f9488134473c9d/a27315d0c7085106 http://groups.google.com/group/google-chrome-frame/browse_th...
- petercooper 17y ago
  Useful info - thanks.