Supporting config tiddlers

[AnthonyMuscio]

Both for the operation of tiddlywiki and custom designed tiddlywikis the existence of prefixed $:/config tiddlers is used. in addition there are also visibility tiddlers containing show/hide.

I want to build the following for myself but wonder if it may be a useful addition to the standard distribution?

Use case: Set a standard practice optionally available to users and designers for handling configuration tiddlers. Improve hackability by providing the ability to read a description and toggle the valid values of any config tiddler core, plugin or designer built.

For example should I create a tiddler $:/config/wiki-mode with a caption of "Set Wiki mode", a description and a field "values-filter" then when viewed it displays the description and provides a radio or select to choose one of the values eg "read-only view update edit".

It would also be helpful if there existed matching global macros generated automatically that populate a variable with the value such that given the above example \define wiki-mode() {{$:/config/wiki-mode!!text}} such that <<wiki-mode>> will hence forth contain the current configured value throughout the wiki unless over-ridden.

Further we could provide a config template that would allow a config tiddler to be transcluded and provide the same selector as seen when viewing the config tiddler. This could also be retrofitted to existing config tiddlers, and added to plugins when publishing their own config tiddlers.

Example {{$:/config/wiki-mode||$:/core/ui/configTemplate}} allowing designers to surface a configuration setting wherever they want.

Alternatively we could have an additional tiddler type to handle such config tiddlers.

If there is support for this I am happy to go ahead and build a bundle to support this for review. But your criticism is welcome if you think there is a better way I will not "waste" my time.

Regards Tony

[twMat]

You're definitely on to something and I believe this jives with the spirit of opening the black boxes (e.g #3967 ). It is a nice idea with either a best practice or ready made widgets/macros to be used when hacking together config tiddlers so to get a consistent UI e.g in plugins.

It doesn't seem native TW sticks to one single practice for "configurations" though. Case in point: The other day, I (again) spent annoying time on tracking down how tiddler buttons are made visible or not. Instead of adding/removing the prefix $:/config/ViewToolbarButtons/Visibility/ to the title it would make more sense to set a field value in the tiddler itself or perhaps in some global config tid.

[AnthonyMuscio]

mat,

The danger of updating a field the actual button tiddler for visibility is either it appears the button changed (creating a shadow tiddler) or timestamps off, there is no recently changed tiddler to track where the visibility is set.

I was recently corresponding with @pmario on bundle tiddlers with a number of settings contained within them that can be applied and reapplied as a batch. having config tiddlers helps in this case. With a click you can set and reset a large number of settings to a known state or states.

Another code pattern we could do more to support with config tiddlers is locally overridden global config settings. eg; $:/config/wiki-mode contains a wiki wide mode setting In any given tiddler you can override this with a tiddler-mode field. In any tiddler you can refer to <<current-mode>> which is derived from the global and local. In this case there is a macro associated with the configuration setting.

Also in my recent Proposal: Tiddler Serial Numbers I created actions that when saving a tiddler actually increments a config tiddler on issuing a new serial number. This is enabled by 5.1.20 maths operators and allows us to create a "real variable", that actually changes over time but is globally accessible. This is a new configuration variable we could provide a facility for.

[AnthonyMuscio]

Mat,

The idea for a global config tid using a data tiddler has some merit. because we could code a method to convert any config value there in, to a global variable with the value within the global config tiddler. All we need to do is ensure if any entry is changed there in that the variables values are "refreshed". The only disadvantage is there is no easy place to store possible variables and other documentation, tooltips etc for each value unless we use a field or separate tiddler anyway.

[AnthonyMuscio]

I just found a simple way to manage global variables from config files.

In a tiddler tagged $:/tags/Macro include a line as follows for each "variable" you want global \define test() {{$:/config/test!!text}}

if config changes so will this variable

Perhaps a long with the standard treatment of config tiddlers this could just be a convention $:/config/global taged $:/tags/Macro and make this editable from within the control panel.