I have a tool palette which shows up when an admin user is logged in to a site. The palette is draggable (via jQueryUI.draggable) and I would like it to remember the position between pages/refreshes... Is there a standard way of doing this, or a plug-in I should be using, or do I need to roll my own (via cookies or something)?
views:
1259answers:
4
+1
A:
I'm not aware of plugins or standards for doing this (although it is likely they exist), but its not a terribly complicated operation anyhow. Cookies is one way of accomplishing it.
My preferred method of storing this type of client-side state is to set a callback function which delivers the new state to the server via Ajax. Then, I can do as I please with it. Generally, I'll store it in the session, but there are times when I have decided certain things should persist permanently and moved it from the session to the database. Having this stored server-side lets you make that change easily. I recommend starting by storing it in the session via Ajax callback, and retrieving it on pageload.
JoshJordan
2009-08-25 13:30:27
+1
A:
I think cookies are a good solution. There is even a jquery cookie plugin here. You could save the coordinates in a cookie on the stop event. When the page changes you could check if the cookie exists and if so change the css on the dragable.
You could save it on the server in a database but that seems a bit overkill to me. Because you will have to change your schema.
Kevin suggested to use the unload event to save the coordinates. This way you don't have to write to the cookie every time the dragging stops.
MrHus
2009-08-25 13:32:58
While this is my original answer... remember that storing cookies on client side has it's effects. They are always transmitted to the server side, for EVERY page request. -> much more traffic.
elcuco
2009-08-25 13:35:25
@elcuco But its only for the administrator, plus storing on the server would perhaps mean an extra database query.
MrHus
2009-08-25 13:39:01
Storing on the server yealds better performance, yet the whole "personalization" feature will cost much more than the cookie. And, whenever the palette is moved, there will be an ajax request in order to save the position - which is an overhead, too.
Alexander Gyoshev
2009-08-25 13:59:54
In any way, keeping the static resources on a cookie-less subdomain would be the best option.
Alexander Gyoshev
2009-08-25 14:00:46
Any reason not to wait until the unload event to persist the coordinates? That should save you some overhead whether you choose the AJAX route or the cookie route.
Kevin
2009-08-25 14:34:24
Hm, true. But isn't it an unreliable event?
Alexander Gyoshev
2009-08-25 22:56:39
+3
A:
Cookies are a fine option - you can use the functions by PPK like this:
$('#palette')
.css({ top: readCookie("palletteY"), left: readCookie("paletteX") })
.draggable({ stop: function (event, ui) {
createCookie("paletteX", ui.position.left, 100);
createCookie("paletteY", ui.position.top, 100);
} });
Alexander Gyoshev
2009-08-25 13:34:26
I think this is the simplest, esp. given the default setting of a cookie in the ppk code... but, one slight wrinkle - the palette is show using position:fixed i.e. it stays put when the window content is scrolled, and although I can see that you're solution *should* work, it doesn't ;-)
Dycey
2009-08-25 15:13:30
Yes - the cookie is being stored - and updated - correctly. But on page refresh, the palette still loads in the default place. The code executes, and firebug shows that the styles have changed... yet it remains in place - so some error in the css. I'll get back to you.
Dycey
2009-08-25 18:49:34
The problem was down to casting as numbers! $("#palette") .css({ top: $.cookie("paletteY")*1, left: $.cookie("paletteX")*1 }) .draggable({ stop: function (event, ui) { $.cookie("paletteX", ui.position.left); $.cookie("paletteY", ui.position.top); } });
Dycey
2009-08-25 19:57:27