I can confirm that if your permalink is out of date (ie the tiddler no
longer exists) opr you click on a link to a tiddler title that does not
exist,
the view template tiddler $:/core/ui/ViewTemplate/body will display the
tiddler $:/language/MissingTiddler/Hint
which contains
Missing tiddler "<$text text=<<currentTiddler>>/>" -- click
{{||$:/core/ui/Buttons/edit}} to create
At first I though It would be simply a matter of redesigning this tiddler
with a button that says this address is no longer valid, click to search
for the renamed/replacement content or similar. Keep in mind currentTiddler
is the missing title.
However an ever smarter bit of wiki text could just make the missing
tiddler "look" like the "new" tiddler" by finding its content and
displaying it as if you were in the new tiddler.
Regards
Tony
On Thursday, 6 May 2021 at 17:39:36 UTC+10 ludwa6 wrote:
> Interesting thoughts, @Tones (as usual), two of which i find most
> stimulating:
>
> On Thursday, May 6, 2021 at 5:21:27 AM UTC+1 TW Tones wrote:
>
>> ...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.
>>
>
> If this could go beyond the typical 404 + direction to the standard search
> widget -and i guess maybe it can, since the wiki KNOWS about this name
> change, right?- then YES, that would be super-interesting. /w
>
>
>> I can share more if you want to go that way.
>>
>
> By all means, Tones -i for one am all ears! /w
>
> 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).
>>
>
> I may be slow, but i do believe it essential to the case -especially since
> @PMario has escalated this issue to the TW devs repo- to deconstruct this
> assertion to underlying premises. Let me try:
>
> 1. A Permalink is by definition permanent.
> 2. The way TW implements it now, it pulls the URL of hosted instance
> followed by /#TiddlerTitle. (NB: that convention works as a reference to
> any tiddler in the wiki, even without using the "Permalink" feature, if
> one
> knows enough to apply it).
> 3. If TiddlerTitle changes to NewTiddlerTitle, then Permalink brings
> user to the default "MissingPage" tiddler (NB: empty, i.e. devoid of any
> more helpful information)
> 4. So if the ability to change TiddlerTitle to NewTiddlerTitle is
> wanted, then a Permalink feature must be tied to some immutable (and
> guaranteed unique) attribute of the tiddler.
> 5. By adding an additional "permalink" field to all tiddlers that are
> only "published" following creation & population of that field with a UID,
> then such link will never break, so long as that field is never modified
> (NB: a rule that could be encoded as a hard constraint).
>
> Now, since both Anders and Charlie have demonstrated two different ways in
> which we can create and populate such new "permalink" field, it is clear
> that this is possible... So what would be the problem with simply
> populating that field with a crash number, as every RDBMS worth of the name
> does as a rule?
>
> (i must be missing something, given all the complexity being bandied about
> here by logical minds greater than mine... But i'm gonna go grab my morning
> coffee and see if i can't catch up w/ y'all :-)
>
> Yours, Walt
>
>
> On Thursday, 6 May 2021 at 12:35:42 UTC+10 [email protected] 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 [email protected] 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/a7f8a256-b806-4e87-9f78-b51cc03ca15dn%40googlegroups.com.
