> Cookies are a bad idea for config.
As I noted in my previous response, cookies definitely have their use:
they permit saving of 'configuration' values that should *not* be
stored within the document, such as sensitive *private* data (i.e,
passwords and unpublished URLs) as well as tracking transitory
statefulness of various page content (slider opened/closed, current
tab), which are also two kinds of information that are typically
applied on a user-specific basis, rather than a document-specific
basis.
> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.
My understanding of the word "kludge" carries a very negative
connotation... specifically, that of being a seriously flawed design
with badly written code that should be avoided whenever possible.
Even if that was not your intent, seeing that word used in regard to
CookieSaverPlugin (or any of my work) definitely made me bristle a
bit.
In fact, I feel that CookieSaver's design delivers *exactly* what is
needed: a flexible syntax for associating specified values with named
settings that can be stored within a single tiddler, saved with the
document, and then automatically re-applied each time the document is
loaded into the browser.
One aspect of the CookieSaver design that makes things extremely
straightforward is that it writes simple javascript assignment
statements (e.g., variablename="value") into the [[CookieJar]], which
is tagged with 'systemConfig' so that it will be invoked at startup to
set the specified option values. This technique is precisely the same
as the current practice of manually creating a [[ConfigTweaks]]
tiddler to set 'hard-coded' persistent option values. The only
difference is that the [[CookieJar]] contents are automatically
maintained by a plugin, instead of being hand-written by the document
author.
In addition, the use of javascript in the [[CookieJar]] means that
groups of simple assignments can be wrapped in 'if' tests, such as:
(document.location.protocol=="http:")
or
(config.options.txtUserName=="Joe")
so that certain settings will only be applied when specific conditions
are met. You can even use the [[CookieJar]] to declare default values
for settings that can still be overridden by individual users, like
this:
if (config.options.txtSomeSetting===undefined)
config.options.txtSomeSetting="thisvalue";
When initially loaded, the setting will use "thisvalue"... but if
txtSomeSetting is later changed (and therefore stored as browser
cookie), the local cookie value will supersede the hard-coded value,
allowing both author-defined document-based defaults and user-specific
browser-based preferences to be remembered and applied when
appropriate.
Please note that an alternative syntax for document-based settings
*has* been proposed (see http://trac.tiddlywiki.org/ticket/756), and
would use a 'slice table' to define the name/value associations.
However, the design is not yet fully specified, and currently suggests
adding new special-purpose syntax to the slice name parsing in order
to indicate when various conditional criteria should be applied to
determine which settings are to be used.
I think that using javascript is a *far* superior design than creating
yet another set of obscure TW-specific 'magic codes' to write into a
slice table... and, in any case, whether javascript or slice table or
some other as yet undefined format, the settings will still need to be
written into a tiddler that is saved in the file in order to achieve
document-based persistence, so at least that part of the design is, in
my view, obvious and inescapable.
In summary:
Although you might quibble about the particular syntax that is written
to the CookieJar, I think that CookieSaverPlugin is not only *not a
kludge*, but is, in fact, a very robust solution that addresses a wide-
range of use cases by employing a well-established syntax that
supports very flexible customization using programmable criteria.
thoughts?
-e
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/TiddlyWiki?hl=en
-~----------~----~----~----~------~----~------~--~---
