DynamicSnippet
==============

If you use page caching (and you should), you'll run into a problem: the
"tyranny of the Bobs.":http://tinyurl.com/6mjoq7 Your entire page could be
static, but if you want to say "Hi, Bob! [[sign out here]]" to Bob and say
"Please [[sign in]], stranger" to anonymous users then each Bob and each
stranger has to get his own page. 

But all we want to do is tell Bob howdy, hide the sign in link and show him a
sign out link.  Rather than falling back to action or fragment caching (yikes!),
we'll make our page (the same one every person gets) ask our server for the
username using AJAX.  Once the server answers back, we can stuff the right kind
of link into our static bar: if it's Bob, we rewrite with "Hi, Bob!", if it's
Barbie we rewrite with "Hiya, Barbie!", and if they're not logged in it's "sign
in | sign up".

So for this, we add a route '/users/userid_and_name' that returns the user's ID
and name (not javascript! not even HTML! just the dozen or so characters!).  The
client queries for it and, if logged in, rewrites the page accordingly. 

We can do even better.  If we are logged in, the client-side JS sets the
userid_and_name as a short-lived cookie.  On each page load we check for that
cookie; if it's there, rewrite using it, and if it's not there, query the
server. The only server-side change is to delete the cookie when we log out.
(The current code also sets it from the server side on log in because it would
occasionally not take until a page refresh... but if I were smart enough to fix
that I'd only set from the client side.)

With the cookie set, it's fast enough that you won't see flashing content or
dancing layout as the hello-bar is rewritten.  And once a user is logged in they
never hit the server for their username.  It's fully robust, too: if Bob turns
cookies off, we'll still say hi but he has to live with an extra 500ms page
load.  If he turns javascript off as well he can still sign in, stay signed in,
and sign out -- he'll get the anonymous-user top bar, but that's not our
problem.

Note that the /only/ thing the cookie does is rewrite the top bar.  The server
never asks for it: just sets it on signin, deletes it on signout.  Client-side
cookies are untrusted inputs, just like URL params, so take care that only
client-side code ever reads this cookie.

Airing of Grievances:
---------------------

I will have disappointed you in the following way: this is neither plugin nor
generator.  I can see why the plugin structure and the generators directory
might have led you to believe that.  Maybe someday it will be... but it's not
really generic enough yet.



# =======================
# Add to config/routes.rb
  
  # Allow page caching with a minority fraction of dynamic content.  
  # Add a similar route for any other ancilliary dynamic content (sidebar, etc.). 
  # If something is *mostly* dynamic, then you should to action or (more likely) fragment cache.
  map.userid_and_name '/users/userid_and_name', :controller => "users",   :action => 'userid_and_name'

  

Caching:
--------
Four out of five dentists agree that page caching is key to rails performance.

* The best caching tutorial, clear and complete:
  http://www.railsenvy.com/2007/2/28/rails-caching-tutorial
* Inspiration for the 
  * http://josh.the-owens.com/archives/2007/08/20/rails-page-caching-with-an-admin-interface/
  * http://withoutscope.com/2007/8/12/for-the-love-of-god-use-the-page-cache
  * http://blog.maxdunn.com/articles/2006/09/16/ruby-on-rails-advanced-page-caching


Example
=======



Copyright (c) 2008 Philip (flip) Kromer, released under the MIT license
http://infochimps.org/