Ticket #5585 (closed enhancement: fixed)

Opened 10 months ago

Last modified 3 months ago

Proposed change to Persist for dijits

Reported by: tk Owned by: tk
Priority: normal Milestone: 1.2
Component: Dijit Version: 1.0
Severity: normal Keywords: persist, tree, splitcontainer
Cc:

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

  Changed 10 months ago by peller

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

  Changed 10 months ago by peller

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

  Changed 10 months ago by 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

follow-up: ↓ 5   Changed 10 months 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.

in reply to: ↑ 4   Changed 10 months ago by peller

  • milestone set to 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.

  Changed 10 months 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.

  Changed 10 months ago by peller

  • milestone changed from 1.2 to 1.1

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

  Changed 10 months ago by peller

  • owner set to tk

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

  Changed 9 months ago by peller

  • milestone changed from 1.1 to 1.2

  Changed 3 months ago by ktiedt

  • status changed from new to closed
  • resolution set to fixed

(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.