Ton, the reason for the current syntax is that it is conceivable that someone might want to use the value "cookie" as an option. (Here's a stupid example: someone might have the nickname "cookie", which they might want to set as their username.) I know this is somewhat contrived, but there is also the issue of future features to consider: suppose, in future, we wanted to add a new way of controlling options (say "default") - we'd run the risk of breaking any TiddlyWiki that had an option string set to "default".
I'm not sure what I think about having different precedence for local and http viewing - this could cause problems for someone who has a TiddlyWiki that they have exported from TiddlySpace - having different online and offline options could be very confusing. Likewise having two sets of options, one for online and one for offline. I'm not dismissing this out of hand, but I will need to think about the consequences. Martin On Nov 19, 11:53 am, Ton van Rooijen <tons...@xs4all.nl> wrote: > This is a very nice enhancement indeed. > > The syntax however is i.m.h.o. somewhat confusing. Why append the > option-name with "_cookie:"? > a) to me it looks like an unnecessary complication of the syntax. > b) the syntax more or less suggests (because of the closing colon) > that you could still provide a value, which is illogical. > > So why not simply stick to the original syntax of > "option-name: value" or > "option-name=value" > in which value can be "cookie", "true", "false" or a real value (like > e.g. in "txtUserName"). > > W.r.t. the discussion about the preference: cookie vs SystemSettings I > would like to suggest 2 possible solutions. > Either: > SystemSettings take preference when viewed over HTTP, whilst when > opened from a local file the cookies take preference. This gives > maximum control for the author/owner. > Or: > The SystemSettings enhancement is even further enhanced by being able > to have 2 sets of system-settings: one options-set for viewing over > HTTP and one for local use from a file. > > I fully support the earlier suggestions from AlanBCohen and > "whatever", to make cookies dependent on the filename of the TW-file. > So every TW-file gets its own cookies. > > P.S. This whole contribution is written based on experience with > independent TWs; I have no knowledge of or experience with > TiddlySpace. > > Thanks to all involved for again having a great TW release. > > On 18 nov, 14:06, Martin Budden <mjbud...@gmail.com> wrote: > > > I'm pleased to announce the TiddlyWiki 2.6.2 beta release. > > > This release consists of a number of minor usability and hackability > > enhancements, as described athttp://trac.tiddlywiki.org/wiki/History, > > and one fairly major enhancement. > > > The major enhancement is the addition of persistent options, also > > known as 'baked cookies'. This is the ability of TiddlyWiki to store > > some of its options in a tiddler, the SystemSettings tiddler, so that > > these options are retained even if the user deletes all their cookies, > > or moves the TiddlyWiki to another computer. > > > The persistent options are more fully described at: > > >http://tiddlywiki.com/beta/#PersistentOptions > > > We are soliciting feedback about Persistent Options as part of this > > beta release, in particular: > > > 1) Which options do you think should be persistent, and which options > > should be in cookies? > > > 2) Do you think the persistent options have been explained properly, > > and do you have any suggestions to improve the explanation? > > > 3) Which should take precedence a persistent option or a cookie? That > > is should a persistent option overwrite an option previously set in a > > cookie, or should the cookie value take precedence? This has been the > > subject of some discussion, and we are by no means sure which is the > > better option. In the beta the persistent option overwrites the cookie > > option. > > > Note that for a standalone TiddlyWiki, the impact of the difference in > > precedence is not that great, but for TiddlySpace the impact is more > > significant: it means an option set locally by a user in a cookie can > > be overwritten by another user of the TiddlySpace, if that option is > > persistent. > > > Martin -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
