On Friday, May 15, 2020 at 5:17:29 AM UTC+2, TonyM wrote: ... > *Note: *A Common answer in tiddlywiki is don't bother, use as many as you > want and if you get into trouble change it, does that apply here? >
Yes. :)) For your private wikis you can do what ever you want. -------------------- For plugins the point is: If you want to standardize field-names, without prefixes and include them into the TW core, you have to have really, really, really good arguments. Because names that the core uses can't be used ever again by users, for a different purpose. That's why the core itself tries very hard, to avoid name collisions. eg: Have a look at the system tag: $:/tags/Stylesheet for a sytem-tags. It would have been easy to use $:/Stylesheet or Stylesheet. But that didn't happen. The main reason is, that it is very likely, that "new users" want to use them for their own use-cases. So Jeremy had to find a tag name, that is self explaining enough to be useful _and_ that gets out of the way for end-users. If you are a plugin-author .. you are _no_ end-user anymore. Publishing plugins comes with the responsibility to "go out of the users way" ... as good as possible. Using a field-name like: _show-details or show-details is definitely limiting the possibilities for your users. So *it's good, that you think about it*! Especially as we already promoted _field-name with a special meaning as a "private" name. So everything which is prefixed with _ should be treated as "*user private*" and not "plugin private". The advantage of _xxx-name or $:/_xxxx-name for system tiddlers is, that it is automatically sorted at the beginning of sorted lists. ... This behaviour *should be reserved for end-users*, to make their live easier. IMO plugins shouldn't take this away. BUT as always: *This is "just a convention"*. You can do whatever you want, and see, how it works out! Plugin tiddlers do have a namespace like: $:/plugin/<authorName>/<pluginName>/as/complex/as/you/like/it Code that comes with plugins should follow this convention because it is "best practice". ------------------ *If you thought about the things listed above, _and_ there is no other way to make a field-name useful then use it, without any pre-fixes!* ... May be a postfix? Eg: I did use the field name: aliases for my uni-link plugin. It is a space separated list of titles. Anything else doesn't make much sense and imo it is specific enough, that it could also be used by other plugins, that do the same thing, without a naming and meaning problem. I also used the field name: subtitle in contrast to the core caption field. ... I consider aliases and subtitle as "de facto" standards now. .. BUT there is the risk to cause naming collisions in the future. That's why you should really think carefully, until you try to establish a new "de facto" standard! .. Other plugin authors and users will have to accept them. If you use xxx-yyy field names, imo you should *not hide* them in the editor. The risk is too high, that users overwrite them and your plugin will probably cause really hard to find side effects. If users don't know, that they have overwritten something, they have no chance to tell you, if there is an issue. If you try to establish *many *plugin-related fields. I personally would go with a postfix. show-info.psat ... So I can use show-info.wl ... OR we both agree on the behaviour of how show-info should work ;) just some thoughts. have fun! mario -- 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/5e184459-7ef1-4c4b-bb4d-f63316c7d52c%40googlegroups.com.
