Idea: Cascades for Save Button, Close Button, Edit Button, etc

#1

Cascades in TiddlyWiki are essential tools allow to customize the user interface with just WikiText knowledge, so average users can create their own effects.
The idea here is to use Cascades for actions, here the save button.

Can we have a cascade action to be performed before save button? If so without JS knowledge you can customize the save button.

Example:
When taking note from a book, I want to keep focus on reading and do not put too much time for creating fields, adding tags, etc…
In the plain text, I write the note and then some actions like:
#test
#best of year

$f desc: a good note
$f color: #ff0000
$f field-name: field-value

A Cascade action before saving, scans the note, and creates tags from line starts with #someword and create fields from line starts with $f

This is a crude idea, we can think about the format and actions.

2 Likes
How do I give a hint when the body content of different tiddlers is exactly the same?
#2

@Mohammad interesting idea, I have thought of similar things in the past including slight variations;

  • The ability or encode a list of field/value pairs that can be applied
  • A command zone, - an edit field in which you can type such things and have them actioned
  • A separate text field containing similar that can have such “requests entered”.

Happy to help you realise something like this;

  • I presume after processing you would remove the rows?
#3

It might be a good idea to think through the aspect of mis-spelling an existing tag and so accidentally creating a new one when you intended to use an existing one - I often fall close to this error especially as I have not always been consistent in my rules of capitalisation in a tag name.

The existing method of adding a tag gives the nearest options in the pull down as you type in each new character, I find this useful to try and avoid creating new tags when targeting existing ones.

If you find a notation that distinguishes between creating a new tag and re-using an existing one then you could maybe choose not to remove the # tagName line so that at least you can see that one of your intentions was not executed successfully most likely because of a mis-spelling?

2 Likes
#4

Having a cascade for toolbar buttons in general is a good idea. So users basically can do what ever they want. It should probably be implemented independently of the described specialised usecase in the OP

The main problem for hastags is that #something already is a valid wikitext rule for ordered lists. So you may have false positives and existing ordered lists will be converted to tags if a tiddler is edited and saved again :frowning:

$f color: red on the other hand would be something new.
$# tag with spaces IMO would be OK too.

As far as I can remember very early discussions in TW development, Jeremy was not very keen on manipulating the wikitext source “on save”

Also as jonnie45 pointed out, there is the problem of miss-spelled tags …

Alternative approach for “fast-tags” and “fast-fields”

We do have an existing button eg: CTRL-L create new link, which gives us a popup that can insert links into the wikitext and then continues writing at the same text position.

It should be straight forward to create a CTRL-T button, that creates a “fast-tag” input for new tags, instead of using the existing tag-picker.

A similar thing ALT-F could be used for a “fast field” input.

The advantage of buttons like this, would also be, that we could “select” some text and then hit CTRL-T to toggle tags

Selecting some text and hit ALT-F would use the selected text as the field value. … and so on.

New toolbar buttons can be easily created as plugins.

2 Likes
#5

@joinnie45

The existing method of adding a tag gives the nearest options in the pull down as you type in each new character, I find this useful to try and avoid creating new tags when targeting existing ones.

The Autocomplete plugin does this for you! When type #, it will show a list of existing tags, you have the same behaviour as tag pills.

1 Like
#6

@PMario

Good catch! Yes # is not a good candidate.

@TW_Tones

It would be nice to have the cascades for toolbar buttons, as @PMario also supports this.
Yes, it can be implemented independently.

#7

I love the specific idea for text-based input of tags and other fields. This would be great. (And I wonder if @Maurycy’s Autocomplete Plugin could be used to allay @jonnie45’s concerns about mistyping field names; I’d have to look into that.) This sounds like a great productivity enhancement.

I’m less certain about using the cascade mechanism for that. At least as I’ve used them, cascades allow you to choose a single handler for a situation. If you want to also use a built-in default at that point, you would have to include it specifically.

I think it more likely we would prefer a transformer/middleware approach, where we could write such transforms of a tiddler, and order them with the same UI we used to order tagged element or with list-before-style fields. Each successive step would get a tiddler that is the output of the previous step. (Anyone who has coded with Express.js’s middleware framework would recognize the pattern.) Although they’re working at the level of the whole wiki, I image $:/tags/StartupAction has something of this process.

The point is that we might want a number of such transforms before the final save, and we would want to create and maintain them independently.

However, I have no idea how feasible this is in TW’s architecture.

#8

Thanks for bringing this to my attention. I have a piece of work to provide the ability to add actions to any standard (or custom) tiddlywiki button via a tag driven approach. Most existing buttons do not yet use the actions parameter and most use cases just need the action to occur, it’s not usually that relevant in which order.

  • I see that done, save and export buttons may be the exception with before and after actions needed.
  • I will need to find a code pattern to do this and it seems a message catcher, a pre-actions tag the key action and post-actions tag maybe needed.
#9

Hi Scott,
If not using Cascade, we need a JS plugin to do the job! There is a plugin to create tags on save from #word. @PMario or @TW_Tones may remember the name of plugin.

#10

I’d love to see it!

I’m hoping for a somewhat different pattern, and I don’t know if there is already something in place in TW to support it. It would act like $:/tags/StartupAction. With startup actions, you can add new bits to run at startup by giving them this tag, and if you choose, you can order the tagged item to choose the order in which they will run. I would love to see something similar here, not so much tied to buttons but tied to major life-cycle events: the current startup, tiddler saving, tiddler deleting, wiki saving, tiddler(s) exporting, and likely at least a few others. The current behavior would be captured in a tiddler with the appropriate $:/tag, and you can drag your action before or after $:/core/lifecycle/SaveTiddler/default (or whatever) in the $:/tags/ActionSaveTiddler list.

So for the suggestion in the OP, we could image this SaveTiddler lifecycle collects all the tiddlers with the given tag, and applies them one at a time, assigning currentTiddler to the tiddler being saved. Mohammed’s is first, and it parses the text field to find any line beginning $f, for each one grabbing a field name and a value and setting that in the tiddler, removing that line from the text. The next (and
for now final) action is the default save behavior. But if we wanted to do additional work, we can simple add more appropriately tagged tiddlers, and sort them where they belong.

I also can imagine the default behavior might be split into several pieces, offering the user a chance to insert behavior more granularly.

I’d be curious to see how it works. My imagination has run off in a slightly different direction.

I know cascade offer a great deal of flexibility that wasn’t available before they came along, but there are many ways in which they’re still rigid.

2 Likes
Patterns for handling default values for inputs
#11

Cascade is a much a description of a logical process as it is a filter run. There are plenty of ways to use a similar pattern on filters for a similar result, Typicaly the first non blank. Perhaps what we are describing here is a series of actions. If we use a tag to drive a series of additional actions they will be triggered in order, and can be reordered as desired.

  • the key words here is “additional” action

My previously designed solution was based on adding additional actions to all current code buttons. Most core buttons trigger a single action often defined in the button parameters with a message parameter.

  • I would simply provide a macro to the actions parameter.
  • in the vast majority of cases additional actions need only occur around the same time a the trigger #1
  • a few buttons need a little more redesign because they already use the actions parameter.

As this thread has highlighted a subset of buttons, by there nature, need pre and post primary action options.

  • I suggest this calls for a different code pattern
  • we may even need to resolve issues about sufficient time for an action to complete.

The code pattern you raise @Scott_Sauyet may be suitable.

#1 remember these are in fact action tiddlers and within them multiple actions, conditional logic and strict order can be enforced.

I will respond further to your @Scott_Sauyet last reply further soon.

@Mohammad i cant recall the plugin name :frowning_face:

1 Like
#12

@Mohammad there is a plugin called Hashtag2tag found at Hashtag2tag — http://tesseract-index.bitbucket.io/ also AutoTag found at at AutoTag 4 TW5 — Tag your tiddlers effortlessly..

Regards hSteve

1 Like
#13

Thank you. Yes this is the plugin converts #word to tag.
@Scott_Sauyet, @TW_Tones

#14

Ahh, the AutoTag plugin has this line:

$tw.wiki.addEventListener("change",autotag);

I didn’t realize that was available anywhere public. I can see it in the source, although searching for addEventListener on the main site gets no hits.

But this means that my idea of lifecycle events no longer sounds particularly far-fetched. There’s a mechanism in the underlying JS, which we should (presumably?) be able to expose to wikitext, to tap into certain lifecycle events.

In the source, I see change and lazyLoad, not much; most other instances of dispatchEvent have to do with DOM nodes. But change is what we need for the current suggestion. This has been added to my ever-growing list of TW ideas to investigate.

1 Like
#15

The “change” event is activated, whenever a tiddler changes in the tiddler store. It activates all event-listeners, that are registered to listen to it. Usually the change event triggers the widgets “refresh” mechanism. Within widgets, there is a lot of logic going on, to only trigger a child-refresh, if it is really needed. So if widget parameters are not “connected” to the tiddlers that are changed, there is no refresh needed. …

If we expose the change event to eg: wikitext actions, it’s very likely that users will start to modify tiddler content based on this event. That will cause a “change” event, which triggers the actions, which causes a “change” event, which triggers the actions, which causes … you get the idea … The perfect environment to brick the wiki and loose data.

So we basically would need a <$change-catcher widget, which must define a filter parameter that limits the tiddlers, the catcher is bound to. So we can make it safer to use. The change-catcher widget would only be active, if it is visible and imo it should ignore its body text. So it would look like <$change-catcher filter="[tag[x]]" actions=<<actions>>/>

I think this idea would be worth while exploring, independently from the cascade mechanism in the OP. I will raise an issue at GitHub, otherwise it will be forgotten.

#16

Oh, well, a short-lived hope, I guess!

My concern is broader than this. But I’m not sure it’s really a good fit for TW. I would like to be able to make adjustments to the wiki around major wiki events: tiddler created, tiddler saved, tiddler deleted, wiki saved, and others, ideally more like middleware than like current cascades.