Fibbles, Thanks for taking the time to consider this.
I see now that there is a bit more complexity than I first thought. I will keep this as clear as possible. 1. Yes a filter to exclude the tiddlers for which relink happens - eg allow relinking on tiddlers with [has[fieldname]] or not on system tiddlers [!is[system]] 2. Yes, I am keen to have different categories but I agree we need to find a clearer way to conceptualise, and keep the code and operation simple. I think I found this below. Ahh I see what you mean by plain text like that wouldn't be touched anyway. That is what I need. However when I rename some tiddlers I find it wants to rename the title inside import records, trashbin and more. So Item 1 and my suggestion below should help here. I think the simplest way forward would be to provide a filter that determines if the relink is visible or not during rename. The designer could use this to exempt or include relink on whatever tiddlers they wish. For example in my database I would have a list of values in the object-type field eg people office list-tiddler that allows relink to occur on those tiddlers only. This means I need not concern myself with the user renaming other tiddler types beyond the damage that rename itself will cause. Lets call this the "rename filter". Remember that for rename to work correctly, I need to list all the fields to look in, to support rename, until I determine those I do not want people renaming the tiddlers. Now the relinking process. Once a tiddler is allowed to be relinked at rename time there are global settings that determine what to "search" for and rename. This is very comprehensive thank you. Using the info tab quickly shows what tiddlers will be impacted, again thanks. But as noted before I sometimes see tiddlers that will be affected that I do not want affected. Of course in some circumstances I want a comprehensive rename, in others no, so we would think different configurations would be desirable. But I am not sure this is necessary to get the same result. Again another filter here would be helpful - lets call this the "change filter". Perhaps you could consider introducing two variables that defines a "rename filter" and "change filter". The designer can set these either globally and/or override them locally (for example in edittemplate for particular tiddlers). I am not exactly sure how to set this yet. These filters could be applied inside relink using the equivalent of the subfilter operator to further limit the tiddlers affected. For example in the edit template I could set on a subset of tiddlers the following filters (in a variable) - my rename filter may read "[has[object-type]!object-type[system]]" to show relink on any tiddler with the object-type field - except system tiddlers. - my Change filter could read "[!is[system]]" stopping the $:/trashbin and other tiddlers being changed. The old names will remain in the trash. But then If I were renaming other tiddlers the above filters may not apply. So We are not introducing different configurations but we are allowing the rename filter to determine on what tiddlers relink will occur and we are allowing the change filter to limit what tiddlers will be affected by the rename. Some assides. I am yet to work through the full implications of your relink plugin but I think they are revolutionary. Why? - because we now have a system by which we can maintain data integrity while renaming the primary key. Expect future posts on this from me. I am also playing with a little utility to help me identify quickly the fields I may need to add to the relink settings. For example list all people, then search all fields in which one of more people titles appear and list the all fieldnames in which they appear. These fieldsnames need to be considered for addition to relink. Thanks so much for your work Tony On Tuesday, September 17, 2019 at 2:52:26 AM UTC+10, Flibbles wrote: > > Hey @TonyM > > So, I'm a little confused. It sounds like you you might be proposing two > possibilities: > > 1. Have a filter which can be used to exclude tiddlers from being > touched by Relink. Currently all non-shadow tiddlers are touched. But a > filter would be feasible. > 2. Propose having different relink configuration profiles for > different categories of tiddlers. This sounds very complicated, not so > much > to design, but to present to the end-user. > > I'm also a little confused by your mention of the text field, I assume you > mean a tiddler's text field, which refers to the body. Your example of text > content was a note '"Old name" was renamed to "new name"'. But plain text > like that wouldn't be touched anyway. Relink only targets reference-related > instances of a renamed title. > > As to the dangers of renaming a dangerous system tiddler, I think I'd need > to see an example. Since Relink doesn't touch shadow tiddlers, I'm not sure > what harm could be done. The only tiddlers referencing shadow tiddlers are > other shadow tiddlers, I believe. And I don't know of any system tiddlers > that would break anything down if they were touched. > > Avoiding tiddlers like $:/backup or $:/trashbin might be examples. I guess > they have some plugin or module that's creating and maintaining that. The > solution to that ties into the first proposal I think you're putting > forward: reasonable, though I would do something a bit more intricate than > just a filter the user edits, so that plugins could introduce their own > tiddlers to be exempt from relinking. > > Am I understanding you correctly? > -Flibbles > > > On Sunday, September 15, 2019 at 11:58:48 PM UTC-4, TonyM wrote: >> >> Fibbles, >> >> I was impressed with the potential of relink and received a request by a >> client who uses a large Tiddlywiki database to allow them to change >> someones name to their married name. The persons name a tiddler title >> itself, is recorded in a range of fields and relink seems to detect them >> all. However I have names mentioned in text fields such as a note saying >> "Old name" was renamed to "new name" which I would like to exclude. Of >> course I assume I can change the configuration to stop this. However >> changing office names is also needed and these reside in another set of >> fields. I assume just whitelisting all the list fields for all the tiddlers >> I may wish to rename would work fine. >> >> However I am just wondering, I could in this case delete all the rules >> that impact widgets, macro and filters because none of these should contain >> something the user has any reason to rename. In some ways making it less >> "pervasive" is possibly a wise design strategy, or is it?, what if they >> rename a critical system tiddler? Would I prefer this to be relinked or >> would it be best to prohibit relinking on system tiddlers? >> >> I am not sure there is a way for us to selectively filter to what relink >> applies to? >> >> One idea may be to place a filter such that the relink action (when >> renaming) does not appear, or take place on tiddlers that do not match the >> filter. This would allow me to set a filter like >> [all[current]object-type[office]] [all[current]object-type-person]] >> which would use relink on the resulting tiddlers and any other tiddler >> not in this filter would not permit relinking. Then as a designer I could >> change this filter so relink will work for me when I am undertaking >> designer activity and become active on say system tiddlers macros etc... >> >> I am yet to work through the extensive details of your wonderful plugin >> and determine how it can best be used in a range of scenarios. It seems to >> me this is not only a great tool to use to support end users, but to assist >> in the development process. >> >> if I do not understand enough yet let me know, It would or could it be >> desirable to have different relink configurations for different cases for >> example for office and person do not relink items found in the text field, >> but for tiddlers tagged $:/tags/Macro update all occurrences except in >> tiddlers with the prefix $:/backup or $:/trashbin >> >> This is only food for thought, so please do not feel any pressure for a >> refactor or re-write. I would be interested in your view. >> >> Thanks In advance >> Tony >> > -- 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/941ebe93-516f-4363-9663-5276137abc14%40googlegroups.com.
