Hi FND,
Thanks for the kind reminder and the hint on 'anon'. By the way, where
does this peculiar 'anon' have its origin? Never heard of this before.
Does that simply stand for anonymous?
Would you think, too, that it made sense to turn this into a global
utility function in the TiddlySpace core? ...returning the visitor
status with respect to a space ...which as of today would thus be one
of 'member', 'user' or otherwise 'anon' ...and maybe in some remote
future possibly also 'owner'?
Would it not even make sense to store this when a space loads in some
variable, thus available to core functions and plugin authors alike?
At least, it seems rather redundant to implement this in every plugin
that could make use of it.
On the other hand, the cleaner version for my usecase indeed seems to
be to make certain plugins private and only have them run when you're
a member... so you cannot spoof the system into thinking that you're
someone which you're not. Although, today you might still be able to
gain access to the correspoding information, in case of it being
stored in a publicly displayed field value.
Thinking about this further... private tiddler fields (/tags too?)
would be somewhat welcome... which would load in addition to the
public tiddler fields (/tags) ...at least, that way one could have a
tiddler that has public contents, yet some private fields associated
with it, only accessible if you're a member. In some way, this would
be like a private draft on top of the public version ...quite
different from the current model, where all you can do is save over
the public version in case it still goes by that name.
On the other hand, as for storing those remote typewith.me URL's I
could imagine a dedicated private 'data tiddler' with either slices or
fields corresponding to each tiddler... probably in the form of some
ID also stored at that public tiddler, so that there is no need to
worry about any subsequent name-changes or people being able to derive
anything meaningful form the ID, thus
public tiddler1 -> {typeWithMeDoc:Tiddler1ID}
public tiddler2 -> {typeWithMeDoc:Tiddler2ID}
private typeWithMeData -> {Tiddler1ID:URL1,Tiddler2ID:URL2}
However, if there were private fields, it would be much more
painless...
public tiddler -> {}
private tiddler -> {typeWithMeDoc:URL}
That however seems to have quite some consequences, as now there would
be a difference if I were to do a store.setValue or store.getValue
from {public} or {private and public} fields... same with tags,
although the convention might simply be to do the former when public
and the latter, when private. Well, setValue would eventually need an
additional parameter to set a private field value.
Well, I guess one could also have something like this...
public: Tiddler
private counterpart: Tiddler_
...and then use some code to look for the corresponding values at that
private tiddler or to provide a toolbar button that opens or creates
it. Looks like a new plugin is born... the "open the private/public
version of this tiddler" toolbar command... which in case it exists,
opens it or otherwise creates it with the above mentioned id reference
logic.
Cheers, Tobias.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" 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/tiddlywikidev?hl=en.
