How protect tiddlers?

[Mat]

How can I ensure a tiddler is not overwritten?

I do not mean that someone would click the edit button etc but rather myself generating a tiddler that accidently has the same ID (i.e title) as an already existing tiddler.

Is it at all possible to protect a tiddler against this?

I guess the second best would be to make it a shadow tid, i.e so that it can be overwritten but then at least restored. What, then, is the best workflow to convert a tiddler into a shadow tid? AFAIK there is no quick button to do so (e.g changing the tiddler type to "shadow" or some such)

Ideas?

<:-)

[passingby]

if you are creating a tiddler by hand, TW gives you a warning about pre existing tiddler.

[Mat]

Yes, I know, but thanks. That's why I mentioned "generated" tiddlers, where I will not notice when a tid is overwritten.

BTW, one way I have solved this before - but it's not appropriate in this case - is to give the tiddlers cryptic titles that are unlikely to be overwritten and then also use an extra "alias" field plus a viewtemplate to show this alias as if it were the title etc.

Anyway, further ideas anyone?

<:-)

[@TiddlyTweeter]

Mat wrote:

How can I ensure a tiddler is not overwritten?

I don't think you can beyond the single warning. Overwritten items are not kept.

 

I guess the second best would be to make it a shadow tid ...

Interesting idea. But would it really help? Reversion would be to some standard thing? Wouldn't a versioning approach be more suited? Something like ... http://twjam5beta.tiddlyspot.com/ a comprehensive versioning system that got very little notice at the time the beta emerged.

[Mark S.]

 What do you mean by "generated" ? There's hmm ... 3 ways I can think of to create tiddlers, one of which has tiddler-collision built-in. If you use that (ActionCreateTiddlerWidget) then it will automatically make a new name if there is an existing name.

The other approach would be to check for the existence of a tiddler, and skip creating it, perhaps making a report so you can handle it per case.

-- Mark

[passingby]

On Monday, August 6, 2018 at 11:33:11 AM UTC-6, Mat wrote:

Yes, I know, but thanks. That's why I mentioned "generated" tiddlers, where I will not notice when a tid is overwritten.

Apologies, my bad, did not read properly. 

[PMario]

 Hi Mat,

I'd go with the shadow tiddler approach.

-m

[Mat]

On Monday, August 6, 2018 at 8:23:18 PM UTC+2, Mark S. wrote:

 What do you mean by "generated" ? There's hmm ... 3 ways I can think of to create tiddlers, one of which has tiddler-collision built-in. If you use that (ActionCreateTiddlerWidget) then it will automatically make a new name if there is an existing name.

The use case is this: I'm currently creating a bigger wiki to use in my work and I occasionally need some quick "special thing" like several tids with some extra pre-set fields or similar. So rather than go searching for a proper solution for this I whip up some button for it or some listwidget that makes a table with EditTextWidgets etc. This is what I mean with "generated". I often only have indirect control of the titles (e.g via a filter) and might assume they don't already exist.

ActionCreateTiddlerWidget - oddly, I'm not even sure I knew about this!!!? I think my default has been to use tm-new-tiddler or ActionSetFieldWidget. Thanks!

The other approach would be to check for the existence of a tiddler, and skip creating it, perhaps making a report so you can handle it per case.

Safety checks rather than actual prevention of overwrite might, yeah if the circumstances allow. Thanks again.

<:-)

[Mat]

PMario wrote:

I'd go with the shadow tiddler approach.

Yeah, thanks.... but if tiddlers are individually shadowified then they're not protected are they? I mean isn't a plugin at risk of being overwritten if one uses the same title? Or is a full page reload required for it to actually be saved as overwritten?

Plus... how would I shadowify tiddlers on an individual basis anyway without a lot of effort?

BTW I just got an idea; would it be possible to shadowify only fields, i.e the title fields!? I'm not sure this make sense at all but maybe it triggers some ideas :-)

Thanks for input Mario!

<:-)

[Mark S.]

On Monday, August 6, 2018 at 1:45:06 PM UTC-7, Mat wrote:

 

Safety checks rather than actual prevention of overwrite might, yeah if the circumstances allow. Thanks again.

<:-)

Since you're filling in forms, the form could hide the "Submit" button if the to-be-generated tiddler exists and replace it with a warning message.

-- Mark

[Mat]

Since you're filling in forms, the form could hide the "Submit" button if the to-be-generated tiddler exists and replace it with a warning message.

hehe, no it's not proper forms. Its typically just some table I throw together with EditTextWidgets for direct setting of field values, which "incidentally" creates the tiddler if it didn't exist already. 

<table>
<$list filter="...">
<tr><td>{{!!title}}</td><td><$edit-text field=foo/></td></tr>
</$list>
</table>

...that kinda thing. Even if I make the titles show as links I can miss their existance when there are multiple such editors and I quickly copy-paste stuff into them, then overwrites can happen and I won't really notice.

<:-)

[Mark S.]

You could put a nested list inside the current list that checks for the prior existence and shows only link if it exists but shows the edit fields if it doesn't.

-- Mark

[Mat]

Mark S. wrote:

You could put a nested list inside the current list that checks for the prior existence and shows only link if it exists but shows the edit fields if it doesn't.

That's a neat idea. Will try to keep it in mind. :-)

I'm still hoping for some more general approach to protect tiddlers though. It probably is shadow tids like Mario suggests, but I'm not sure how to shadowify individual tiddlers in a simple way. There ought to be a simple tiddler tool button for it, but then again, what does it mean that one tiddler is shadowified....

<:-) 

[Mark S.]

Well, here's how you can shadowize your own tiddlers:

https://tiddlywiki.com/dev/#How%20to%20create%20plugins%20in%20the%20browser

Note that you don't see the result of your plugin saving until you reload. It seems to me that it would fairly straight forward to make a javascript "cheater" macro and button that could add new items to your "save-me" Plugin. (cheater because macros aren't supposed to modify things, but there you go).

But I don't think it will help as much as you think. So, something gets written over, and you realize the mistake and can roll it back. BUT, what about the new data that you had input that created the mistake? Don't you still want that? That's why the catch-it-when-you-edit might be the better all-up plan.

Have fun,

-- Mark

[PMario]

On Monday, August 6, 2018 at 10:54:07 PM UTC+2, Mat wrote:

Yeah, thanks.... but if tiddlers are individually shadowified then they're not protected are they?

No ... In TW everything is a tiddler and therefore can be changed. .. Also the core is a tiddler ... A big one :) but still a tiddler.

The only thing you get is the "overwrite warning" when you start editing. ...

 

I mean isn't a plugin at risk of being overwritten if one uses the same title?

Yes ... That's a feature, by design. ...

You can prepare stuff for someone else. But as soon as they want to modify it, they should be able to do so. ... Even if they break it.

 

Or is a full page reload required for it to actually be saved as overwritten?

If you create a new plugin, a full page reload will be needed, that the plugin will be activated. ... Overwriting a plugin TEXT tiddler will be active immediately. Overwriting code tiddlers will need a restart.

 

Plus... how would I shadowify tiddlers on an individual basis anyway without a lot of effort?

You'd need some additional plugins, that need to do the handling. 

 

BTW I just got an idea; would it be possible to shadowify only fields, i.e the title fields!?

No ... shadow-tiddlers only.

-m

[Mat]

PMario wrote:

I mean isn't a plugin at risk of being overwritten if one uses the same title?

Yes ... That's a feature, by design. ... 

But so it wouldn't make sense to shadowify individual tiddlers then. Instead have to be put into some container tiddler (really a plugin). This means I cannot create a tiddler and spontaneously decide to "protect" it and then go on to deal with another tiddler.

If you create a new plugin, a full page reload will be needed, that the plugin will be activated. ... Overwriting a plugin TEXT tiddler will be active immediately. Overwriting code tiddlers will need a restart.

Code = "application/javascript" type, or what does actually "code tiddler" mean? Wikitext is text, right?

Thanks!

<:-)

[PMario]

On Tuesday, August 7, 2018 at 1:04:07 PM UTC+2, Mat wrote:

Code = "application/javascript" type, or what does actually "code tiddler" mean? Wikitext is text, right?

wikitext is text. yes.

-m

[PMario]

On Tuesday, August 7, 2018 at 1:04:07 PM UTC+2, Mat wrote:

PMario wrote:

I mean isn't a plugin at risk of being overwritten if one uses the same title?

Yes ... That's a feature, by design. ... 

But so it wouldn't make sense to shadowify individual tiddlers then. Instead have to be put into some container tiddler (really a plugin).

As I wrote. The only thing, that's possible at the moment is: get a "warning" when you start editing.

The good thing is: If you mess up your changes, you can delete the "content-tiddler" and the shadow tiddler will take over again.

 

This means I cannot create a tiddler and spontaneously decide to "protect" it and then go on to deal with another tiddler.

Protect it ... from what?

You can't protect a tiddler from other users. .. TW gives everyone the freedom to change everything. .. and I personally think that's a good thing.

-m

[passingby]

Another idea is to completely forego putting titles in the title field. Put them in caption field or a description field. And use timestamps as titles. So two tiddlers of the same caption could exist side by side no problem.

On Monday, August 6, 2018 at 10:35:56 AM UTC-6, Mat wrote:

[Mat]

Guys, just a thank you for your input on the matter. Even if there doesn't seem to be a spot-on solution, you have given me some ideas.

<:-)

[TonyM]

Mat,

You ask "How can I ensure a tiddler is not overwritten" but if it is and you know it has being and you can recover it then do you have what you need?

If so there are dozens of ways to to achieve this, within noteself all versions are retained, 

there is this plugin http://j.d.revisions.tiddlyspot.com/ 

There is a trails plugin

In some ways it is actually about your workflow. Your tiddler generation tool can test for the existence of a tiddler first or using the correct method to create tiddlers will not overwite but increment the title with a number.

If you generate and import tiddlers the bundles plugin can test for overwrite before import and keep track of all imports in the import bundle.

I worry about the number of cats that get "skinned" given tiddlywiki "has so many ways to skin a cat".

Regards

Tony

[Mat]

TonyM wrote:

You ask "How can I ensure a tiddler is not overwritten" but if it is and you know it has being and you can recover it then do you have what you need?

Thanks Tony. The thing is that in the use case I'm concerned with, I will not know that it was overwritten. Plus the approach to recover rather than to prevent overwriting in the first place is not the ideal solution here. While I agree with e.g Mario that things should generally be modifiable, I still want to be in control over circumstances that permits or prevents modification.

But those are some interesting plugins! That jd plugin looks really useful in the right context and I had missed or forgotten about the Trails plugin.

Thank you.

<:-)

[TonyM]

Mat,

Perhaps your solution could be designed to clone any tiddler it is about to replace to another name eg; $:/temp/overwritten/tiddlername (n)

Regards

Tony

[TonyM]

Mat,

Just an aside

Since you seem to be bulk creating tiddlers you may be interested in this http://tobibeer.github.io/tw5-plugins/#make

a filter that allows to create unique or random tiddler titles

Regards

Tony

On Tuesday, August 7, 2018 at 2:35:56 AM UTC+10, Mat wrote: