Action on any button Proof of Concept

[TonyM]

Folks,

Please find attached a json bundle of tiddler demonstrating a proof of concept for an Action on any button tool.

You can drop this on tiddlywiki.com then look at the recent tab and you will see the LogTiddler is updated with most uses of the existing buttons. 

Most page and tiddler buttons have being changed to demonstrate this. No reload is needed.

See $:/PSaT/Custom-actions for a few more details.

The idea is any tiddler containing some action widgets can be tagged with tag(s) of the form $:/tags/custom-action/buttoname eg $:/tags/custom-action/edit

These actions with be actioned when clicking on button name eg the edit button.

Why?

Because triggers are required to get actions to occur, but there are already a pile of buttons in tiddlywiki which can now be used to trigger additional actions.

For example write to a tiddler with "now" to record when the save button is triggered, your last saved date/time

Love your feeback

Supporting GitHub Issue https://github.com/Jermolene/TiddlyWiki5/issues/4272

Regards

Tony

[Mat]

So do I understand this right:

The idea is to be able to remotely add actions to buttons, including to already existing buttons, so that these actions are (also) performed when the button is clicked. And this is achieved by creating a new tiddler containing the extra actions and then tagging that "actiontiddler" with e.g "$:/tags/custom-action/edit", i.e a special tag with the prefix "$:/tags/custom-action/". 

...so to use this, one is to include this in ones buttons <<custom-actions "...mytiddlerwithactions...">>

...and your attachment has all core buttons modified to include this.

Do I understand this right so far?

I don't quite understand what the tags on the actiontiddlers is for, if the actiontiddlers are listed in the maro call anyway?

<:-)

[TonyM]

Mat

The idea is it uses the one macro with a tag name to locate the actions to apply. Adding an action to any existing button requires you taging a tiddler containing the additional actions.

The key is that any number of action tiddlers can be used on any button. Any single action can be used on any nUmberto of buttons.

In the demo, a log action tiddler is tagged with all buttons custom action tag. As a result every button is using the additional action.

if a simlar solution is placed in the standard distribution, you do not need to modify core tiddlers to add custom actions. just place a tag on your custom actions. This allows multiple macros and plugins to use this mechanisium without clash.

Building your own buttons and other widgets with actions you can use the same mechanism. Rather than hard code actions use the tag mechanisium.

With tags you can add and remove them. You can have a run once by using an action tiddler that removes its own tag. You could even have a chain of such actions.

Does that help?

Tony

[coda coder]

That's pretty cool, Tony. Something like this (meaning, "if it's there, use it") should be in the core. It adds extensibility to the core and increases hackability.

Mat - what Tony has done is something akin to the LinkCatcher widget https://tiddlywiki.com/#LinkCatcherWidget.

Tony - you might want to look again at LinkCatcher - maybe workout how to remove the need for tags?

[TonyM]

Coda

Working with link catcher is important to be able to place custom actions on opening tiddlers and the various ways you can.

I can visualise a few ways to do this without tags but this is a standard mechanisium for exposing hackability in tiddlywiki. The view and edit templates, sidebar and sidebar tabs and more use this.

Please tell me more why you think I should not use tags.

If you think that its important we not use tags do you have a design pattern that achieves the same result? E.g. any tiddler, any number, ordering, cumulative changes possible etc...

Finally if I deliver this as a plugin in the interim, I wonder how plugin shadows interact with core shadows?

Thanks for your feedback.

[coda coder]

On Saturday, September 28, 2019 at 5:27:09 PM UTC-5, TonyM wrote:

Please tell me more why you think I should not use tags.

Sorry, Tony. I completely misunderstood how you were using them. Now that I've played around with the POC more, I can see better what you've done.  Good stuff. Me likey. Lots!

[PMario]

Hi Tony,

I think your POC is very well thought out! ... I do see some inconsistencies, but most of them are inherited from the core.

The inconsistencies come from the ongoing development of the <$button> widget, late adding of "actions" parameter and adding the <$action-xxx> widgets.

So I think, the first step would need to be, that we "clean" the existing core/ui/buttons/xxx from the message-parameter. This parameter can be replaced by defining the button "actions" parameter using action-widgets.

The same thing can happen with <$action-xx> widgets in the button-body. They can also be moved to the "actions" macro. Which also has some advantages. eg: <<now>> macro is re-calculated on button click and not on button rendering. ...

As I wrote at the GitHub issue, we have several action "insertion points". Every single one of them can be a valid usecase for different type of users. With the core, we need to be as open _and_ generic as possible. This can lead to more complexity as we want.

With all actions in the "actions-macro" definition, there are only 2 insertion points left. ...

 - pre-actions and

 - post-actions

This mechanism makes everything predictable and much simpler as 4 possible insertion points. ... BUT ... It also means that we need to rewrite the existing core buttons, make them "predictable" ... AND ... 100% backwards compatible.

Compatibility _may_ be hard part here.

just some thoughts.

mario

[coda coder]

On Tuesday, October 1, 2019 at 12:25:21 PM UTC-5, PMario wrote:

 - pre-actions and

 - post-actions

Thanks Mario. I had similar thoughts but couldn't find a way to express them. Notionally, in my head I had something like this:

<$pre-actions>

<$button ...>

<$post-actions>

which is obviously unworkable. But now I'm seeing:

<$button preactions=<<pre-actions>> actions=<<my-actions>> postactions=<<post-actions>> ...>

I also like this, but I don't know if it's feasible:

\define my-button-pre-actions() ...
\define my-button-actions() ...
\define my-button-post-actions() ...

<$button data-id="my-button"  ...>

[TonyM]

Mario and Coda, Thanks for the feedback. 

• I wonder how these alternates stand against my suggestion of hackability through patchability.
• Please note for the "action on any button" I propose does not demand any differentiation between pre/main and post actions. It is simply used as a trigger.
• Can you explain further when and how one would want to differentiation between pre/main and post actions

On refactoring to handle pre, body and post actions

• I must say I acknowledge this depreciation of action widgets in the button widget body.
• I do not understand the technical reason for this and have expressed my dissatisfaction with this because it stops buttons and their actions being able to be a self contained piece of code, but I also see now it will be difficult to do a number of things we can do now. 
• You can see this even more when you want to apply conditional actions inside the button, or additional actions or if you are trying to apply actions inside a list to operate on sets of tiddlers. 
• Imagine if we were no longer permitted to code action widgets inside buttons how would we address my design, your suggested pre and post actions, conditional and bulk actions?
• The idea that buttons can only be designed to work by reference to external definitions of macros/variables containing the actions is to me retrograde at least for the average user.

I stand to be corrected but it seems to me deprecating actions widgets inside buttons is causing more problems than advantages and solves a "problem" not visible to most users and designers.  When this happens in other aspects of my life, when the cure is worse than the disease, my usual strategy is to return to the original problem and revisit it to see if there is an alternate way to address it. Perhaps the system code can be refactored to address any perceived technical issues while retaining the current outwards functionality.  The problem is because I do not understand the problem this is supposed to solve I can't  try and find a solution.

You are both already talking about fundamental changes to the button widget so it seems revisiting this is almost necessary anyway.

Perhaps another strategy would be to build a new widget, perhaps action-button that has the additional subtlety encoded. Perhaps designed from the ground up so that it works equally well with actions inside the button widgets, so this need not be deprecated.

I know you are both quite capable of creative thinking, and deep knowledge, so I would hope you can give this suggestion a little more thought.

Thanks heaps

Tony

[coda coder]

On Tuesday, October 1, 2019 at 6:29:40 PM UTC-5, TonyM wrote:

Mario and Coda, Thanks for the feedback. 

• I wonder how these alternates stand against my suggestion of hackability through patchability.

If you're talking about your tagging idea to extend hackability of core buttons... that's on another level entirely. The pseudocode I mentioned is nowhere near as powerful. And really, my proposal is only a "nice to have" kinda thing.  To a coder (cough) it would "feel right" (well, it does to this coder, anyway ;))

 

• Please note for the "action on any button" I propose does not demand any differentiation between pre/main and post actions. It is simply used as a trigger.
• Can you explain further when and how one would want to differentiation between pre/main and post actions

I stand to be corrected but it seems to me deprecating actions widgets inside buttons is causing more problems than advantages and solves a "problem" not visible to most users and designers.

That's true. But I wasn't proposing deprecation of the old method, more an "as well as". And it's similar to your tagging approach - if the pre-* exists, call it, otherwise do nothing. And of course, when I say "exists", it can exist anywhere in the current scope, not necessarily in the same tiddler body (much like we approach macros like currentTiddler, for example).

And Tony, remember how your tagging method works - the extension mechanism you've provided would pull in code from anywhere given a tag match.

 

You are both already talking about fundamental changes to the button widget so it seems revisiting this is almost necessary anyway.

Always. Again, "as well as" not "instead of".

Perhaps another strategy would be to build a new widget, perhaps action-button that has the additional subtlety encoded. Perhaps designed from the ground up so that it works equally well with actions inside the button widgets, so this need not be deprecated.

No. Extend, not replace.

[PMario]

On Tuesday, October 1, 2019 at 9:12:28 PM UTC+2, coda coder wrote:

..

which is obviously unworkable. But now I'm seeing:

<$button preactions=<<pre-actions>> actions=<<my-actions>> postactions=<<post-actions>> ...>

Hi,

That's _not_, how it was meant. Now you have 6 insertion points.

There will be only 1 "actions" parameter. The macro, which is connected needs some logic similar to what Tony did in the POC.

-mario

[PMario]

Hi,

On Wednesday, October 2, 2019 at 1:29:40 AM UTC+2, TonyM wrote:

Mario and Coda, Thanks for the feedback. 

• I wonder how these alternates stand against my suggestion of hackability through patchability.

I did see that post, and will respond in more detail there.

Short version here:

With TWclassic we used "monkey patching", which creates a lot of problems. A patch always makes assumptions about how the code, that needs to be patched looks like. ... If a different, poorly written plugin has completely invalidated those assumptions, that approach will fail.

The biggest problem will be debugging and maintainability.

-mario