Opened 12 years ago

Closed 11 years ago

#5585 closed enhancement (fixed)

Proposed change to Persist for dijits

Reported by: tk Owned by: tk
Priority: high Milestone: 1.2
Component: Dijit Version: 1.0
Keywords: persist, tree, splitcontainer Cc:
Blocked By: Blocking:

Description

Instead of persist: true/false, I propose we modify persist to be a numeric value so we can use {expire: persist} in dojo.cookie() to specify longer cookie expiration dates. This could be done several way....

my suggestion would basicalyl be to treat anything !== false or possible >-1 since 0 is a valid option (session cookie) as true...

Comments/suggestions?

Change History (10)

comment:1 Changed 12 years ago by Adam Peller

it would be nice if we were consistent with dojo.cookie. dojo.cookie seems to use days for props.expire...

comment:2 Changed 12 years ago by Adam Peller

(In [12033]) Persist splitter size. How's this look? Refs #5585

comment:3 Changed 12 years ago by Adam Peller

(In [12034]) Just use Boolean persist for now. Realized that Number or Date isn't possible in the parser, so the previous example was really coming through as expires: null, not expires: 1. expires: yyyy-mm-dd is funky but perhaps not really useful? Refs #5585

comment:4 Changed 12 years ago by tk

I would say not support dates.... how many websites say "your cookie will expire on X day (unless they are telling you what X days from now is)

this would mean false, 0+ are the only values we care about, and you can say true==0 for boolean compatability if oyu really want to.

in this case, false means no persist 0 == sessions (default current only behavior)

0 == X days

Off to bed, just wanted to put this in a safe spot for others to ref later.

comment:5 in reply to:  4 Changed 12 years ago by Adam Peller

Milestone: 1.2

Replying to tk:

this would mean false, 0+ are the only values we care about, and you can say true==0 for boolean compatability if oyu really want to.

This would still imply mixed types, which the parser doesn't handle well, plus it complicates the API. Bill has suggested we just go with boolean and have some global setting that lets the user customize the persist behavior.

comment:6 Changed 12 years ago by bill

Right, and also perhaps we should change the default behavior so that persist="true" on a widget persists forever, not just for the session. That's a simple change that could be added to 1.1 to partly address this bug.

comment:7 Changed 12 years ago by Adam Peller

Milestone: 1.21.1

moving back to 1.1 so we don't forget that part

comment:8 Changed 12 years ago by Adam Peller

Owner: set to tk

please change the default to 365 days for 1.1, but don't change widget APIs.

comment:9 Changed 12 years ago by Adam Peller

Milestone: 1.11.2

comment:10 Changed 11 years ago by Karl Tiedt

Resolution: fixed
Status: newclosed

(In [15017]) fixes #5585 adding {expires: 365} as 3rd arg to all the persist cookie write statements... !strict

Note: See TracTickets for help on using tickets.