Mario, Thanks for sharing your expertise on this. I have a need for a subtly different approach, because I am thinking of fields I may use in solutions I deliver. Solutions intended for common use. For example a journal-date field with a time stamp so there is no need to parse the "pretty title", or a tool that displays "descriptions" when they exist in a verbose mode.
I can keep this all in my wikis, but I would like to share my work to save others time. *So the OT was can I pollute the fieldname space, You said yes, and I should consider moving some capabilities away from tags and fields is appropriate.* Here is what has led me to this whole question; I have built a development environment that allows me to define and handle objects and fields, I have simplified this with a seperate set of reusable field types, and they respond to a different modes the wiki is in. I now have a library of field and field type definitions for a lot of common fields, from email addresses to reference links and source urls. I have secured the meaning of these fields by using them on tiddlers only with an object-type field but they are freely available to use anywhere and come with their own display/report/table and editing tools, including special modes such as given a year number how many years old is it. It in this open source shared environment I would like to build the resources to make better use of fields for every one. If installed on an empty.html they should give plain and simple fieldnames with meaning by their name and not cluttered with prefixes or suffixes. I believe this should not cause conflicts with plugins and if one field did you can redefine it, create a new one. Another example is on $:/config/tiddlers I can add a field called config-values containing the possible values including a filter then build a solutions that works on all config tiddlers, buttons, selects and opening the tiddler itself. It would be a defacto standard for me and anyone that uses it, but it would not make sense to add .psat, especially to the values. My feeling is if field names are well chosen, there will be few overlaps, as long as their use is scoped eg; on tiddlers with $:/config/ prefix the config-values may exist. If authors could register what the names of the fields are and what kind of content they hold others can view the registry and decide their own or to reuse a name. eg; a Keywords field, would presumably hold only words not tiddler titles?, a system-caption would be an alternate name for a system tiddler like a caption that will appear in standard search such as link to $:/Manager <http://127.0.4.85:8081/resources#%24%3A%2FManager> would be named "Tiddler Manager" in search results. These solutions almost depend on using the appropriately named fields. Regards Tony On Friday, 15 May 2020 22:39:45 UTC+10, PMario wrote: > > On Friday, May 15, 2020 at 2:18:21 PM UTC+2, PMario wrote: > > 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 ;) >> > > As i wrote this, I had an idea. ... What if plugin authors agree on a > defined behaviour for new fields. This would allow us to use the same field > name with multiple plugins. > > This may lead to "total confusion" but imo it's worth some thoughts. eg: > > field name: show-info > values: yes.psat no.wl > > So my filter code could be: [contains:show-info[no.wl]] and your > [contains:show-info[yes.psat]] > > This can only work, if every plugin-author would work that way from the > beginning. .. It wouldn't be possible to test for "empty value" anymore, > because an other plugin would have a value in the field. That wouldn't be a > problem for me personally, but may be for others. > > Adding new values can be done with: append and removing a value can be > done with: remove. ... A _new_ toggle listops may be a convenience > function. > > The above would only make sense for "yes / no" like fields. > > just some thoughts > 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2fc542ca-94bf-454a-b196-96b8d82c0ac3%40googlegroups.com.
