Add Cookie and Metadata?

[Jörn Zaefferer]

We've merged Stackfix (fomerly bgiframe) as a plugin, as well as
producing our own standalone utility Position. Taking that a step
further, can we pick up Cookie and Metadata, too? Both are already
optional dependencies of our existing widgets, with both suffering of
hardly any visiblity.

I think both can be kept as standalone plugins ala Stackfix and
Position (no dependency to others) and both are easy to maintain, just
like Stackfix. Getting them under the jQuery UI umbrella would help us
(less badly documented optional dependencies) as well as non-jQuery UI
developers, by giving the plugin the visiblity they deserve.

Jörn

[Richard D. Worth]

+1

- Richard

[Todd Parker]

+1

Todd Parker

to...@filamentgroup.com

[diogobaeder]

+1

I've made a lot of code to give persistance functionality to my
website (http://diogobaeder.com.br/), but it would make sense that it
stays on jQueryUI or be easily visible in its website. Some
functionalities that would be achieved by this, giving persistance to
the user:
- Non-modal dialogs (like help windows for a website);
- Sortable lists (like a menu that a user can personalize for his own
taste);
- Latest/already open submenu in an accordion;
- Latest open tab.

Regards,

Diogo



On Aug 23, 11:26 pm, "Todd Parker" <t...@filamentgroup.com> wrote:
> +1
>
> Todd Parker
> t...@filamentgroup.com
>
> On Aug 23, 2009, at 6:12 PM, "Richard D. Worth" <rdwo...@gmail.com>  
> wrote:
>
> > +1
>
> > - Richard
>
> > On Sun, Aug 23, 2009 at 5:41 PM, Jörn Zaefferer <joern.zaeffe...@googlemail.co

[lrbabe]

I definitely agree.

by the way, I've rewritten the cookie plugin a few month ago to
improve it a little bit:
- I made use of a regular expression to read the cookie, instead of
splitting the whole cookie and looping through its values.
- I added global options to be able to set the "expires" "path" and
"domain" options once for all

I've contacted Klaus Hartl to review to changes but he seemed to be
too busy at that time with the release of 1.7

Here is the code: http://github.com/lrbabe/jquery.cookie/

Regards,

Louis-Rémi Babé

[Jörn Zaefferer]

I've created wiki pages for both plugins. They deserve some attention
before we can add them to our repository.

http://wiki.jqueryui.com/Cookie
http://wiki.jqueryui.com/Metadata

Jörn

[Kevin Dalman]

I just implemented state management in a widget. Based on this, I have
an idea/request for enhanced cookie functionality - essentially I want
to store meta-data in a cookie.

I need to pass state-data to the cookie function *as JSON*, and have
it saved under *a single name*. When I request that cookie back, it
must return the original JSON. This is ideal for state management. In
my case, users can specify which states they want to persist in the
cookie when it is created. Since I only use one cookie, I don't need
to know what was saved in it! I simply retrieve the state-cookie (as
JSON) and $.extend the options object during initialization - voila,
state restored, whether the cookie contained 1 option or 20.

My solution was to 'stringify' the JSON and save it in a single
cookie. When the cookie is retreived, it's easy to convert it back to
JSON...

return window["eval"]("("+ decodeURIComponent( VALUE ) +")") || {};

It would be great if the UI cookie method/plugin could handle JSON
like this. If not the cookie plug-in, then perhaps the widget factory
could have intermediate methods for saving and retrieving state-
cookies as JSON.

I thought I'd mention this idea since you are working on both the
cookie and meta-data plugins. There is a synergy here.

/Kevin

FYI, this is my stringify routine. I don't use arrays, but do use sub-
keys...

function stringify (hash) {
return parse( hash);

function parse (data) {
var D=[], i=0, k, v, t; // k = key, v = value
for (k in data) {
v = data[k];
t = typeof v;
if (t == 'string') // STRING - add quotes
v = '"'+ v +'"';
else if (t == 'object') // SUB-KEY - recurse
v = parse(v);
D[i++] = '"'+ k +'":'+ v;
}
return "{"+ D.join(",") +"}";
};
};

[Jörn Zaefferer]

This is on ice for now, after the descision was made to give "core
plugins" more attention, which includes cookie and metadata, in
addition to bgiframe and others.

Jörn

[diogobaeder]

Kevin,

Just use any JSON specification compliant library (like http://www.json.org/json2.js
from Douglas himself), get/set the cookies using parse/stringify
methods, and use identical comparison to "undefined" and voilà, you
have state management which is independent of what is actually
persisted in the cookies.

Sorry to mention my website again, http://diogobaeder.com.br/, but it
uses this concept, and you can see there where it does:
- If you close a window, the window's closed state gets persisted;
- If you resize a window, its dimensions are persisted;
- If you move a window, its positions are persisted;
- If you click a window, it gets the higher z-index and this is
persisted.

I've made a library to manage these states. It's not that good (I've
made it for my personal use, and didn't care much for
maintainability), but if someone did it for managing the jQueryUI
widgets' states, it would be great! It was not that difficult to
develop mine - the only tricky part was managing the z-index -, so I
think it's an affordable solution.

Regards,

Diogo

[diogobaeder]

Jörn, Kevin and others,

Brainstorming: what if we encapsulated persistance in a set of
methods, and used adapters to use cookies or DOM Storage as the client
code's choice? I mean, DS is a great functionality, since it doesn't
transmit the persisted data to the server and it has its own getter/
setter methods, and if we created a storage abstraction that could
fall back according to browser support, it would be neat! :-)

Regards,

Diogo



On Sep 15, 5:52 am, Jörn Zaefferer <joern.zaeffe...@googlemail.com>
wrote:

> This is on ice for now, after the descision was made to give "core
> plugins" more attention, which includes cookie and metadata, in
> addition to bgiframe and others.
>
> Jörn
>
> On Sun, Aug 23, 2009 at 11:41 PM, Jörn Zaefferer
>

[Kevin Dalman]

> Just use any JSON specification compliant library (like http://www.json.org/json2.js
> from Douglas himself), get/set the cookies using parse/stringify
> methods, and use identical comparison to "undefined" and voilà, you
> have state management which is independent of what is actually
> persisted in the cookies.

Thanks Diogo, but I'm past that. I used json2.js for months as a quick
solution, but I hate JS dependancies, so in my lastest version I wrote
the stringify() subroutine shown above. This allowed me to completely
replaced json2.js for my needs.

My motivation for posting the idea here was: A) So in the future I
could use core UI functionality instead of custom code, and B) because
storing/retrieving JSON seems the best solution for *all* UI state-
management . Using a JSON cookie makes restoring state simple: $.extend
(options, $.cookie("widgetOrInstanceName"));

Because my widget has multiple objects with multiple states, I allow
users to customize which states are persisted by specifying them in
the options. They can also persist multiple instances of the widget by
naming each instance...

options = {
autoStateManagement: true
, cookie: {
name: ""
, autoSave: true // Save a state cookie when page exits?
, autoLoad: true // Load the state cookie when Layout inits?
, keys: "north.size,south.size,east.size,west.size,"+
"north.isClosed,south.isClosed,east.isClosed,west.isClosed,"+
"north.isHidden,south.isHidden,east.isHidden,west.isHidden"
}
}

All standard cookie options can also be set: expires, path, domain &
secure.

I expose methods to read/clear/save/load state so custom code can be
used to manage state instead:

getCookie() // read the cookie
clearState() // delete the cookie
loadState() // update options with saved state
getState(keys) // create JSON object of all 'state keys', ready to
save
saveState(keys) // write state to a cookie

The concept is easily adapted as a *generic state-management solution*
for any UI widget. The missing piece is a standard way to save/
retrieve JSON to/from a cookie. That's why I piped up when I saw meta-
data and cookies being discussed together - seemed like a perfect
match. Even though I have a working solution, I'd like to see the UI
core implement JSON cookies and/or other persistence methods --
eventually.

/Kevin

[diogobaeder]

That seems great, for me, Kevin... in my opinion, this discussion
should be kept and giving support to these functionalities are, at my
point of view, worth putting in the jQueryUI core.

I'd like to see other guys' opinions, too.

Regards,

Diogo



On Sep 20, 1:21 am, Kevin Dalman <kevin.dal...@gmail.com> wrote:
> > Just use any JSON specification compliant library (likehttp://www.json.org/json2.js

[Kevin Dalman]

Native JSON in HTML 5
-----------------------------
JSON, or JavaScript Simple Object Notation is a popular alternative to
XML, which was almost the de-facto standard before the existence of
JSON. Until HTML 5, you needed to include libraries to encode and
decode JSON objects. Now, the JavaScript engine in that ships with
HTML 5 has built-in support for encoding/decoding JSON objects.
http://www.webreference.com/authoring/languages/html/HTML5/

I just learned that HTML 5 will include native browser support for
encoding/decoding JSON. It seems reasonable that jQuery implement the
same functionality *today*.

JSON encoding/decoding methods is a perfect match for jQuery's goals,
which is to simplify and componentize common functionality so it is
easily reused in custom code, jQuery plug-ins and UI widgets.
Potential uses include state-managment, parsing meta-data, Ajax
requests, and JSON cookies! If these methods existed in the jQuery
core, adding state-management to UI widgets would immediately become
much easier.

So my suggestion is that JSON encode/decode methods be added to the
jQuery core. Existing JSON code (like in $.ajax) would be updated to
call these new methods, centralizing all JSON handling. This may not
be a top priority, but I believe it deserves to be *on the TODO list*.

The jQuery community could be encouraged to submit canditates for this
by creating a *small* plug-in utility. The functionality should be
limited to HTML5-style decode/encode so its footprint is as light as
possible. Users can use the full json2.js library if they require
anything more.

/Kevin

[diogobaeder]

In my opinion JSON could be added at the jQuery core, not as an
extension of the main jQuery object, but as a global JSON object:

if (!JSON) {
window.JSON = {
stringify: function(obj) {
// etc
},
parse: function(str) {
// etc
}
}
}

Is this what you were thinking of, Kevin?

I know that it's hard and undesired to put things at the core, and
that we should maintain it as slim as possible, but JSON is becoming a
prefered data format in many web applications, as parsers become more
robust, and jQuery itself needs to understand JSON (but, in my
perspective, in the wrong way, because of the use of "eval" function).

Looking forward to other guys' opinion,

Diogo

On Sep 21, 2:17 pm, Kevin Dalman <kevin.dal...@gmail.com> wrote:
> Native JSON in HTML 5
> -----------------------------
> JSON, or JavaScript Simple Object Notation is a popular alternative to
> XML, which was almost the de-facto standard before the existence of
> JSON. Until HTML 5, you needed to include libraries to encode and
> decode JSON objects. Now, the JavaScript engine in that ships with

> HTML 5 has built-in support for encoding/decoding JSON objects.http://www.webreference.com/authoring/languages/html/HTML5/

[Scott González]

jQuery should not define JSON, and absolutely should not create a second global object. If you need JSON, include json2.js. There is absolutely no reason for libraries to be redefining already existing solutions.

[Kevin Dalman]

> There is absolutely no
> reason for libraries to be redefining already existing solutions.

I respectfully disagree. $.ajax, $.cookie, $.browser - good
implementations of these existed, but replacing a mishmash of
libraries with a single unified system is one of jQuery's strengths.

> jQuery should not define JSON, and absolutely should not create a
> second global object.

I agree. Query should not replicate the json2.js library, which has a
lot of new object methods and code for edge-cases.

> If you need JSON, include json2.js.

I do not agree! jQuery *already* does JSON parsing (ajax and
metadata), and it does not use json2. All jQuery needs to round out
its capabilities is a basic 'stringify' method.

Things got off track here. My suggest was really for *basic JSON
functionality*, sufficient for ajax, metadata, metadata-cookies, state-
management, and similar uses by plugins and widgets.UI widgets should
not have non-jQuery dependancies (json2), so if stringify is not part
of jQuery or UI, then it is not available unless each widget
implements it separately.

This is why I suggest 'encapsulating' existing JSON handling rather
than having ajax & metadata duplicate code. At the same time, adding a
stringify/encode method would offer new possibilities, like a standard
state-management system for UI widgets.

FYI, my own JSON encode/decode implementation is only 300 bytes. In
fact my entire state-management system is under 2K, including 8 public
methods and *full* cookie capability, so it would be even smaller if
$.cookie was in the core.

Just my 2-cents.

/Kevin