[TW5] Setting field values and/or pre and post process in tiddlers?

[TonyM]

Folks,

This question may be from a place of ignorance, however can you tell me why it appears fields can only be set from inside a triggering process such as a button?

No need to go into DOM trees and All that, I understand that at a high level.

I was wondering if there is a reason I can NOT set a value in a tiddlers field using a macro, list, set or other method if only when a tiddler is rendered. without user intervention such as a checkbox, button etc...

Or have I missed something?

If it is as I suspect, could we not have a trigger that occurs as a tiddler is rendered, such that it may evaluate some conditions and assign a value to a field, before continuing to render the rest of the tiddler, now using the new field value?

It would seem a little like StartupActions for a tiddler. However I have not worked through the amenity and practicality of this.

I imagine one could cause multiple actions to occur on the opening of a given tiddler. Such that the opening a tiddler is a button that will launch some actions.

Perhaps another way to think of it is a pre-processing step. I could imagine a block of wikitext could be evaluate (eg; Some variables determined and actions executed) before the rest of the wiki text is evaluated in a given tiddler) as a result this pre-processing will never be rendered only the result of its actions prior to rendering. Of course a timeout may be needed, set globally, overridden locally.

Use cases?

• Evaluate various values or determine if other values match various conditions before rendering
• Allow tiddlers to respond to pre-conditions evaluated for them alone with simple flags
• eg; If tiddler expiration date has past set status field = expired
• Allow tiddlers to carry with them some logic and processing normally found in accompanying macros/plugins and user buttons. Increase share-ability.
• Allow the generation of a log entry on opening a tiddler (I have being here), update a last read date.
• Allow auto timing or start and end time logs (Would need a post process)

I was taught not to raise a problem without suggesting a solution!

Perhaps we could provide a way to specify a special kind of macro that is pre-processed without output (unless in error) eg:

\defineaction onopen()

<$list

set field to result

</$list

\endaction

In closing I suppose what I am suggesting is not only considering tiddlers as the atomic storage unit but also allow them to be the the process or function atomic unit.

Regards

Tony

[PMario]

On Friday, March 30, 2018 at 3:56:51 AM UTC+2, TonyM wrote:

Folks,

This question may be from a place of ignorance, however can you tell me why it appears fields can only be set from inside a triggering process such as a button?

That's right. TiddlyWiki is event-driven, because the browser is event driven. ...

Eg:
 - clicking any element on the browser viewport will create a "click-event" ...
 - This event starts at the element that is clicked. ...
 - If the element doesn't handle it, it "bubbles up" to the parent ... and so on.
 - If there is some code, that handles the event, something happens. ...

A very common pattern for user interaction is clicking buttons. ... Handling button clicks is "cheap" since it only needs to happen on user interaction. Since users are "slow" compared to modern CPUs, "button based" interaction doesn't slow down the site performance. ....

A second common pattern is scrolling. ... Handling the "scroll-event" to see if something is visible is "expensive" eg: With my mouse wheel changing it 1 raster, creates about 40 scroll events. That's a page movement of 4 lines. ... So handling very little things is ok. .. But going through the whole tiddler store and do something, will slow down the UI interaction.

.... That's why there is no user facing generic widgets, that uses the scroll event. .. They are always very specialized, to do exactly one thing fast!

eg:
TiddlyMap has a "hotzone" widget.
TW plugin "dynaview" handles "load, scroll, resize" events

Since working with those events can have a bad performance impact modern browsers created "native" observer functions. .. Most modern browser can use this mechanism. ... but as usual IE does not. ... So doing it the "compatible way" .. is not really suited for most users.

have fun!
mario

[TonyM]

Mario,

I have come to understand this, but my question is can we initiate actions on opening, or clicking the link to a Tiddler, that is specific to that tiddler? 

Imagine 

• I append a date and Time to a subtiddler on opening the tiddler, and again on closing?
  
• Evaluate and Set a range of variables and field values which are then available to the tiddler including actions.

Perhaps I am saying what about an on-click event for opening and closing a tiddler? Surely this does not break the model? and happens on user interaction?

Regards

Tony

[PMario]

On Sunday, April 1, 2018 at 3:40:02 AM UTC+2, TonyM wrote:

• I append a date and Time to a subtiddler on opening the tiddler, and again on closing?

This would be possible. But you still would need to create widgets, that modify the fields with their "render()" function...

A mechanism that's used in the uni-link plugin may be possible too. Instead of creating a default link-widget it calls the uni-link macro. This macro can be modified, so you can do what ever you want. ...

The alias function uses the same mechanism with the aka-macro ...

• Evaluate and Set a range of variables and field values which are then available to the tiddler including actions.
  

Perhaps I am saying what about an on-click event for opening and closing a tiddler?

This would be possible if you modify the core "close" and "link" functions or toolbar buttons.
 

Surely this does not break the model? and happens on user interaction?

It depends, on what you want to do. Some functions are possible out of the box. Others may need some code.

-m

[Jeremy Ruston]

Hi Tony

I think it would be possible to have some actions that were triggered on navigation.

A nice general purpose way we could accomplish this might be a new <$messagecatcher> widget that intercepts messages and triggers actions for each one:

<$messagecatcher tm-navigate=<<mynavigationactions>> tm-close-iddler=<<mycloseactions>>>

...

</$messagecatcher>

To simplify the navigation actions use case, we might set things up so that the page template triggers navigation actions on tiddlers tagged $:/tags/NavigationActions

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/37e60174-9969-4e4e-a699-929cb7994b17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TonyM]

Mario and Jeremy,

Thanks for the feedback. Perhaps another possibility is custom fields. 

I have being thinking what If there were a pre and Post field permitted in tiddlers to allow <$vars > in Pre and </$vars> in post to wrap the Text field. 

If a multi-line field this would support local macro definition while leaving the text field free for transclusion as content buy other tiddler. This could include CSS definitions and more.

In keeping with this idea we could have pre and post actions fields in a given tiddler that are triggered on navigate to, or close. 

Being restrained to individual tiddlers, the possible errors are also constrained to individual tiddlers, however such fields could be populated with transclusions. 

I am trying to propose a very generic solution such that it becomes a feature (Plugin or core) that empowers mid level users, who are not able to readily access java script functions inside the core.

In the above cases it helps mid level users access more advanced features. 

One application that comes to mind in addition to the log actions, is more advanced field manipulation tools that allow the creation of new fields when they do not yet exist in a tiddler.

The Current method is to tag tiddlers with the view template and test every tiddler but if there were one pre and post tiddler test then this should reduce the amount of testing from the view template by pushing it into tiddlers.

Such opportunities in tiddlers makes tiddlers much more reusable because they can carry all they need in a single tiddler and Cary macros and field info when dragged to other wikis.

Just some ideas, Tell me how To further this if you support the ideas.

Regards

Tony

[PMario]

On Monday, April 2, 2018 at 2:44:31 AM UTC+2, TonyM wrote:

Thanks for the feedback. Perhaps another possibility is custom fields. 

I have being thinking what If there were a pre and Post field permitted in tiddlers to allow <$vars > in Pre and </$vars> in post to wrap the Text field. 

If a multi-line field this would support local macro definition while leaving the text field free for transclusion as content buy other tiddler. This could include CSS definitions and more.

I needed to read this post several times, to understand, what you try to achieve. ... At least I think, I got it ;)

This is exactly, what the ViewTemplate does. It looks like this. (code is stripped and indented, to make it more understandable)

<$set name="storyTiddler" value=<<currentTiddler>>>
  <$set name="tiddlerInfoState" value=<<qualify "$:/state/popup/tiddler-info">>>
    <$tiddler tiddler=<<currentTiddler>>>
      <div class=<<frame-classes>>>
        <$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]]" variable="listItem"><$transclude tiddler=<<listItem>>/></$list>
      </div>
    </$tiddler>
  </$set>
</$set>

As you can see, there are 2 "set-widgets". They set tiddlerInfoState and storyTiddler variable. ...

There is also some "invisible" stuff going on.
The tiddler-widget internally sets several other variables which are "hardcoded". As you can see in the core code link.

So What you propose here is to change the core ViewTemplate and add some new variables, that contain user actions. ...
Or the "tiddler-widget" ...

Changing the ViewTemplate would be easy. ... But filtering the actions, that should actually do something will need a new widget, as Jeremy proposed it. ..

You wrote:

In keeping with this idea we could have pre and post actions fields in a given tiddler that are triggered on navigate to, or close.

See: "triggered in navigate to, or close." ... OK ... navigate or close .. or both ....
It's easy to write it here in a sentence. .. It's just 2 words, but it will produce the same amount of code. .. We have to handle "navigate to" / "close" events or both. ... And how can we decide, if we only need to use one action, or both. ... There needs to be some information about it. ...

So in the end we will need a "myMessageCatcher" as Jeremy wrote, because we will need to have a lot of extra info, what we exactly need to do. ..

Just sorting it out for my own understanding ;)

-mario

PS: BUT I think there is a more general "workflow-problem", that you want to address, with the wrong tools. ... I'm just not sure yet, how we could solve it, without "blowing complexity through the roof". (Not sure, if this is proper english ;)

[TonyM]

Mario/Jeremy,

Thanks for that Information it adds to my understanding. I trust you and Jeremy to know how to implement this. Please forgive my ignorance of terminology and jargon.

I see from your View Template example that we could look for pre and post fields in each tiddler and transclude them and wrap the display of the tiddler in them - this would allow pre and post code to wrap the tiddler text.

I accept a new widget may be needed to trigger an action as a tiddler is opened, but once this is available it would be trivial to transclude into the view template the contents of a field which would list action widgets just as we can inside the Button widget.

I suppose reacting to a Close event would be different because all we need to do is add to the close button a transclude of  a current tiddler field in its list of action widgets.

As I think more about this and with the information you have both Shared could I suggest this?

A new widget such that its contents, of action widgets, are triggered as rendered, the trigger is rendering.

<$actionnow>

Actions widgets

<$/actionnow>

If the above were possible, "wrap tiddler text in content of fields from within the currenttiddler,  "actionnow" and updating the "close button" I can see the ability to extend tiddler functionality substantially.

Regards

Tony

PS: BUT I think there is a more general "workflow-problem", that you want to address, with the wrong tools. ... I'm just not sure yet, how we could solve it, without "blowing complexity through the roof". (Not sure, if this is proper englis ;)

[TonyM]

Gentlemen,

I managed to trigger actions on close as follows by editing the close Button, to add a current tiddler transclusion. To be honest there are other ways to close and we may want a finish button that does this.

<$button message="tm-close-tiddler" tooltip={{$:/language/Buttons/Close/Hint}} aria-label={{$:/language/Buttons/Close/Caption}} class=<<tv-config-toolbar-class>>>
{{!!onclose}}
<$list filter="[<tv-config-toolbar-icons>prefix[yes]]">
{{$:/core/images/close-button}}
</$list>
<$list filter="[<tv-config-toolbar-text>prefix[yes]]">
<span class="tc-btn-text"><$text text={{$:/language/Buttons/Close/Caption}}/></span>
</$list>
</$button>

So as a test my test tiddler triggers a message

created: 20180403230925750
modified: 20180403232809754
onclose: <$action-sendmessage $message="tm-notify" $param="SampleNotification"/>
post: Bye
pre: Hi
tags:
title: Pre and Post tiddler

Also I modified $:/core/ui/ViewTemplate/body to include Pre and Post fields as follows.

<$reveal tag="div" class="tc-tiddler-body" type="nomatch" state=<<folded-state>> text="hide" retain="yes" animate="yes">
{{!!pre}}
<$list filter="[all[current]!has[plugin-type]!field:hide-body[yes]]">


<$transclude>


<$transclude tiddler="$:/language/MissingTiddler/Hint"/>


</$transclude>


</$list>
{{!!post}}
</$reveal>

This works except more needs to be done/understood to get the following to work as an example

pre=<kbd>

Post=</kbd>

So what remains?

• Further testing of above examples for unforeseen consequences
• Learn how to use HTML or CSS to wrap "text" using fields within a tiddler
  
• A Widget to trigger actions on render placed in View template to include the content of a current tiddler field

I now see I could create a start button in tiddlers to trigger actions and even provide a finish button (but it is nice to have this occur automatically on open of a tiddler or close).

Regards

Tony