Cj,

If you want to try that you can create a view template that tests if the 
tiddler is missing. If it is it will display the missing message and you 
can interrogate the URL used to get there and propose the users click a 
search button to find the tiddlers new title, if by no other method than a 
unique created date. You could have a table somewhere that it searched for 
the old title, and find the correct and latest new title.

This has the advantage of tiddlywiki informing the user the link has 
changed. Like a html 404 page with a search facility. This could even 
suggest the user open an archived wiki.

I can share more if you want to go that way.

With *"Using URL's containing search and reference to a unique ID is 
superior to permanent links" * the key point is a permanent link is that, 
permanent, it should remain permanent, if we must rename something then we 
are after a non-permanent responsive link (however it is done).


Tones

On Thursday, 6 May 2021 at 12:35:42 UTC+10 cj.v...@gmail.com wrote:

> That is some good stuff.
>
> Only one of those I'd dare fuss about:  
>
>    - Using URL's containing search and reference to a unique ID is 
>    superior to permanent links.
>
> That one I'd say "it depends" on a whole bunch of things.  Every solution 
> is superior to every other one depending on the trade-offs, the scenarios, 
> the design, blah blah blah snooze.
>
> I would much prefer provide ability for visitors to grab UID permalnk 
> because they are so easy), but setup my TiddlyWiki with the smarts to 
> recognize somebody is trying to access a tiddler via a link with a bad UID 
> (maybe I should call that "SEQ" for sequence number), and redirect to 
> TiddlyWiki's search page along with a message that related tiddler no 
> longer exists, here are a few others in the vicinity of the UID in case 
> they are materially close.  Something like that.
>
>
> On Wednesday, May 5, 2021 at 11:13:39 PM UTC-3 TW Tones wrote:
>
>> There is a lot of water under the bridge in this thread so here are a few 
>> points that may or may have not being covered;
>>
>>
>>    - In summary it is not difficult to generate stable permalinks.
>>
>>
>> This is based on 100's of hours of my time considering these issues and 
>> dozens of prior conversations.
>>
>>    - Unless you fiddle with default behaviors the created field will not 
>>    change, the only concern is if more that one tiddler has the same date, 
>>    this can be tested on one one date incremented (in the microseconds) to 
>>    make them unique.
>>    - When making a permalink, who is to say if the tiddler changes its 
>>    name, that link may not longer be valid anyway.
>>    - Using URL's containing search and reference to a unique ID is 
>>    superior to permanent links.
>>    - Others including myself have created viable tiddler serial number 
>>    solutions, which may ONLY be needed for this generating an advanced 
>>    permalink, ie only tiddlers with an advanced permalink need have a serial 
>>    number applied.
>>    - There are other issues if publishing static sites, however url 
>>    redirections can be put in place.
>>    - Interactive tiddlywikis have the smarts to address changes, static 
>>    ones by definition do not necessarily, however it would be trivial to not 
>>    delete a tiddler, when renaming but include a html redirection in it if 
>> the 
>>    static url is to change.
>>    - Global Serial numbers or UUID's are overkill in most applications 
>>    where we need "unique References", references need only be unique to the 
>>    tiddlywiki, at its domain/folder address unless you are designing for 
>>    GUID's to allow dragging and dropping of tiddlers.
>>
>> Regards
>> Tones
>>
>> On Thursday, 6 May 2021 at 10:56:32 UTC+10 cj.v...@gmail.com wrote:
>>
>>> YouTube video:  TiddlyWiki: A Prototype of UID's for stable permalinks 
>>> <https://youtu.be/UOFqXoyEU4I>
>>>
>>> On Wednesday, May 5, 2021 at 5:34:24 AM UTC-3 ludwa6 wrote:
>>>
>>>> The more i use TW, the more concerned i become about maintaining data 
>>>> integrity -and so this issue has boiled to the top of my queue: how can i 
>>>> continue to enjoy the benefits of TW (+ Relink plugin) flexibility, 
>>>> without 
>>>> compromising the integrity of Permalinks?  
>>>>
>>>> This feels like a deep problem that goes right to core TW architecture- 
>>>> since, as PMario explained in last thread 
>>>> <https://groups.google.com/g/tiddlywiki/c/kTrAbuneCkA/m/lAsdkriFAgAJ>, 
>>>> tiddler immutability is tied to its Title (so how can Relink even work, i 
>>>> wonder?)- but if i've learned anything here, it is to not underestimate 
>>>> the 
>>>> creative problem-solving ability of this group :-)... SO:
>>>>
>>>> From a non-technical perspective, what i'd like to do is have some 
>>>> immutable UID (based on date-time, or maybe date+ a serial number, like 
>>>> yyyy-mm-dd-serialnum) that is used for Permalinks (i.e. shared w/ the 
>>>> outside web that is not Relink-aware), but still have Title field and 
>>>> Relink plugin (and everything else for that matter) work just as it does 
>>>> now, from the TW editor's perspective.
>>>>
>>>> Is this a reasonable feature design goal, i wonder?  If so, i'd like to 
>>>> do what i can to help make it happen!
>>>>
>>>> /walt
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/203a1726-9c7c-4ae4-ae18-d78b4f43adffn%40googlegroups.com.

Reply via email to