“All Explorer” is a clumsy name, but it’s descriptive at least.
I like these tiny tweaks to things!
1 Like
It is not my reaction as history shows many wikis outside of the $:/ system namespace are not named hierarchically. So the top of the tree will often be flat including most tiddlers. In this default case it is of little use.
3 Likes
My reaction was based on expectations that even if you dont have structure, the root of a “tree” command should be able to be set to the base of the tree. The result is a flat list - ie, basically a different way to get the same basic view as is in the ‘All’ tab.
And if you DO have namespace structure, then that is an even more useful reason to be able to set the base of the tree at the root.
(my own TW is more the former - almost no hierarchical structure, and I may just remove the ‘All’ tab at some point down the track in favour of the ‘All explorer’)
1 Like
In addition to my last comment I did previously build a tiddlywiki where all (well many) of my customisations (not content) were under the / “root” and hierarchically named like plugins. If I was doing this again I would turn / into an additional system namespace, I now know how to do this https://namespaces.tiddlyhost.com/
- Perhaps it is worth asking others if they would use such a feature?
One could imagine adopting \ as a non system namespace, under which data is hierarchically organised and they still appear in standard search.
Why did I not continue with the above naming practices?
- I came to put my own code under my own brand structure
$:/PSaT/projectnameand if needed$:/plugins/PSaT/projectname - I now use the system tags, also flags, advanced search and relink to reduce my need to use a name to find something, even anything.
- I will leverage the system prefixes for genralised solutions such as
$:/fields/fieldnames - I much prefer using plain English tiddler titles and rarely ever get a clash with my own code or even that of other plugins or solutions.
I did not respond earlier as the simple answer it to use the default mechanism of the title N where N starts at one for the 1st duplicate, at least initially then rename more usefully.
However it really does depend on the nature of the data and if you are entering it or importing it. As soon as you know there is going to be more than one you can choose if you will qualify it some how or add an increment, for example WC, do you care about the name beyond WC? This may be suited to numbering, But public parks most likely have names so I would try and source them.
- Consider identifying and saving types eg tiddler-type=public-park or tag them as such, give them an incremental number until you find the “unique real name”.
- Where there is one unique item such as the state mascot the name will be unique (unless you included another country when it could be possible, although unlikely), so no increments or renames needed.
On Slugs
On other websites a slug is a unique URL, usually system generated, where the title in tiddlywiki forms part of that url, but unlike other slags it is not a short name as the tiddler title is often human readable.
- This has being explored extensively and there are many different ways to handle this. In fact the sky is the limit, and I am happy to provide guidance and support but I don’t think it is relevant to your current use case as it seems only to be a matter of avoiding duplicate titles, in hierarchical imported data.
- Be careful if you share a url to a tiddler you rename, it will not be there, become a dead link
- I did create a solution for this where the old title is retained but links to/transcludes the new title.
1 Like