Support sessionizing the analytical command queue

[scudco]

I have a fair idea of how to do this thanks to iconara's snogmetrics (http://github.com/iconara/snogmetrics), but I was curious what you had to say on this topic. I'd really like to be able to call "analytical.event('foo')" in a controller that ends up redirecting without losing that event or having to use the server-side implementation (blegh!).

• The command queue should be (optionally?) stored in a session variable
• When analytical emits the javascript the session variable should be cleared

Thoughts?

[jkrall]

Very cool idea... I didn't know snogmetrics was doing that.
(maybe it is a more recent change than when I first checked it out and opted to create analytical)

I agree that storing it in the session makes the most sense. I think you could just serialize the array of queued commands into the session... and, like you said, clear it out when we emit the javascript.

Shouldn't be too hard to implement. Let me know if this is something you have time to tackle, or I can take a crack at it at some point when I have a spare moment.

[scudco]

I basically need this ASAP so I'm going to try and get it working.

[jkrall]

Cool!
(sorry I can't jump on it this evening... but feel free to ping me in here if you need any help or want to kick something around)

[jkrall]

Hey @scudco ... I spent some time on this today (while hanging out at WindyCityRails). I roughed in a solution to this problem, check it out here: http://github.com/jkrall/analytical/tree/session_store

I haven't even tested this in an actual controller yet... so I don't know if the session-based storage of commands actually works. But it's a start. Take a look and maybe this will help you out.

[jkrall]

Update: Just got this working. Check it out :)

[scudco]

AWESOME. I'm going to try it out. I worked on a solution for an hour yesterday, but your code is much better ;) I also like that session storage is optional.

[jkrall]

Cool, let me know how it works. I'd like to keep it out of master until one of us has time to test it some in a real app.

If the size of the data in the session proves to be problematic, another option would be to write a different storage class that used the Rails.cache and some unique hash-key that gets persisted in the session. Wouldn't be too hard to extend what I've got now to do that... but if we don't need it, then it's not worth the trouble.

[scudco]

Just got a chance to play with this. Looks like it is working great for me from the console. It'll be in a staging environment within a couple of days. I'll keep you updated. Thanks again!

[jkrall]

I've merged this in and released it... FYI. (It's still disabled by default)