Request for Comment: Extended button actions and Autotag

[TonyM]

Folks,

(Minor edit)

I am working on a way to add custom actions to any button in the core and that you create. 

I want this to result in the smallest change possible to see if it is worthy of core inclusion or plugin.

I have also designed an approach to make this reusable, and set some standards.

This post is not for the faint hearted but those keen to extend tiddlywiki, set new standards, new users please don't bother with it. I will share any results. 

If you have any suggestions for a better way for me to communicate such ideas please let me know.

I have come up with a strategy and I want to call for your comments

• Each new or existing button will have the actions=actionreference specify a template tiddler. 
• The template tiddler will then respond to a "tag name" if it exists and transclude all tiddlers so tagged into the actions= parameter.
• Thus it it will be easy to add additional actions to any button by placing them in a tiddler so tagged.

Why would I do this?

Because tiddlywiki needs a trigger for a range of actions. Buttons allow this but we often have to make a button to just to cause an action to take place. 

This often demands an additional step by the user when often the standard buttons provide the ideal opportunity already. For example I could trigger an action on closing a tiddler, on saving the wiki, on importing something to mention a few.

Why a request for comments?

I want the following concepts considered, perhaps to set de facto or de jure standards. 

• This solution includes two concepts, one is the concept of actions in "action tiddlers" that would become part of the core to support hackability of core buttons ;
• We may as well also have a generalised form for other transclusions by tagname 
• A concept called autotags, where by a tagname is defined and used only if a tiddler exists with that tagname.

For example $:/core/ui/Buttons/edit would have the following actions parameter `actions={{edit||$:/actions}} `.

My Current Strategy is to 

• create a tiddler called $:/actions which is transcluded as follows `actions={{actioname||$:/actions}}` as needed. 
• This template could then transclude a tiddler (if it exists called $:/actions/actioname) but first let us consider autotags.
• You can have more than one action name in one button tiddler eg `actions={{fold||$:/actions}} and actions={{unfold||$:/actions}}`

Autotags: because multiple designers/developers may wish to add additional actions and not impact other macros and plugins using extended actions for the core buttons, I want to add another feature called autotags.

• The $:/actions template can assume a tag name from the actioname such that as for the above edit example it would be $:/actions/edit
• Any tiddler tagged $:/actions/edit will be transcluded into the actions parameter of the edit button, 
• the actual tiddler  $:/actions/edit need not exist, although I would create one with an explanation for each core button. see [prefix[$:/core/ui/buttons]] and others such as $:/core/ui/EditorToolbar and more.

It is useful to have action templates of the form `{{actioname||$:/actions}}` because they must contain actions however we could provide a generic transclude solution as well.

• create a tiddler called $:/transclusions which is transcluded as follows `actions={{transclusionname||$:/transclusions}}` as needed. 
• The $:/transclusions template can assume a tag name from the $:/transclusionsname such that for example it would be $:/transclusions/transclusionsname 
• Any tiddler tagged $:/transclusions/transclusionsname will be transcluded where `{{transclusionname||$:/transclusions}}` is used, 
• for example the tag $:/transclusions/chapter in {{chapter||$:/transclusions}}

In closing

A key advantage of taking this approach is we can share actions or transclusions freely without requiring more than a tiddler and a template transclusion in our own code.

The order of actions can be set in the tagpill (list field) of each tagname, and use list-before and list-after fields.

The autotag concept can be extended further.

NB: I am aware of some work by Jeremy 

Allow message handlers to be written as action strings #4265 that need to "understand each other".

See my own issue Hackability of default triggers - "Buttons" #4272

Regards

Tony

[TonyM]

Post script

When using a transclusion of the form `{{actioname||$:/actions}}` the currentTiddler will become "actionname", if you want to refer to the original "display" tiddler use the `<<storyTiddler>>` variable.

Regards

Tony

[bimlas]

TonyM,

Thus it it will be easy to add additional actions to any button by placing them in a tiddler so tagged.

I like this kind of hook mechanism, but I can't say any real use. Could you give an example of when a button should do more than one thing at a time? I find it somewhat more useful to change the operation of a button instead of expanding it (as Override Navigation plugin does with internal links and tabs) or maybe prevent default operation under certain circumstances.

[TonyM]

Bimlas

I am happy to illustrate the value in adding additional actions to core buttons. I am writing now as I sit in a hospital waiting room. The two general approaches are to intervene at appropriate times and add features while simplifying interaction. The proposed solution is designed to be extended with multiple solutions being able to add actions without overwritting other additional actions.

An example I used as a test was any action on every button was recorded in a log of actions. This is a way to track activity to create an audit trail or potentially add an undo feature.

An action on tiddler done, close and cancel can stop a timer and log elapsed time.

An action on edit could throw a dialogue if no current user is set.

An action on save wiki could store the last modified date and user.

Any button could record its use in a data tiddler e.g. theme switch and permit an undo.

A project tiddler could set the current project then revert to the previous one on close.

Open in new window button could set an indicator in the main window.

An additional dialogue could be generated on encrypting a tiddler advising the password be recorded.

The close all button could trigger a save wiki and prompt for a new user name.

Closing a specific tiddler could trigger a custom actiin like disable a plugin.

Using the settings icon could trigger a warning message or backup current settings.

New here could also set a parent field

The home button could open default tiddlers plus a specific tiddler based on other values.

And many more....

[TonyM]

Bimlas

The existing buttons are used to perform key actions in a wiki such as saving or reloading, closing tiddlers or viewing the sidebar. By permitting additional actions the designer can add actions that add functionality at the exact moment they are needed with no additional user triggers. Its easier to make something automatic rather than leave it to users to intentionally trigger something.

All I want now is a way to action on navigate to tiddlers matching various filters.

Regards
Tony