In that case I would put a "login" link that does the ajax request when
clicked.  That way your not hitting the server at all unless you have to.

Rob

On Thu, Sep 4, 2008 at 10:30 AM, tommy <[EMAIL PROTECTED]> wrote:

>
> Thanks Rob, my reasoning was this:
> Page caching is the fastest solution because it allows nginx to serve
> the page without even touching Mongrel/Rails at all.
>
> This allows the page to load instantly for the user.
>
> If under load, it may take a second for the ajaxed login form to
> appear, but at least the user sees something instantly.
> -
> Fragment caching will still hit the Rails framework for the entire
> page request.
>
>
> More thoughts?
>
>
> On Sep 4, 9:38 am, "Rob Kaufman" <[EMAIL PROTECTED]> wrote:
> > If you want to keep the token (which is a good thing) you can either:
> >
> > 1. remove the form from your template and have it be its own (non cache)
> > page.  This isn't the best UI choice but might be a good practical
> > solution.  Just don't let my wife (a usability engineer) know I told you
> ;-)
> >
> > 2. use fragment caching to cache the rest of the page and leave the form
> > dynamic.
> >
> > Both of your solutions mean just as many calls to the server which
> basically
> > is defeating your caching.  If you save a server call, but then have to
> > spend one you have almost as much overhead as you started with.  You
> might
> > gain some speed if the rest of the page is resource expensive to put
> > together, if its not that you've saved nothing.
> >
> > There may be other options, but thats what I've got off the top of my
> head
> >
> > Rob
> >
> > On Thu, Sep 4, 2008 at 9:01 AM, tommy <[EMAIL PROTECTED]> wrote:
> >
> > > I want to be able to use page caching but i have a login form that is
> > > using an authenticity token.
> >
> > > Any suggestions on approaching this?
> >
> > > some thoughts i had:
> > > 1. have a JS call to render the partial upon page load.
> > > 2. hmm, iframe the login form?
> >
> >
> >
>

--~--~---------~--~----~------------~-------~--~----~
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
-~----------~----~----~----~------~----~------~--~---

Reply via email to