Discussion:
[twdev] [TW5] Setting field values and/or pre and post process in tiddlers?
(too old to reply)
TonyM
2018-03-30 01:56:51 UTC
Permalink
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
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/fd0aeca1-adde-4601-b927-df9fc8d691c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2018-03-30 08:33:31 UTC
Permalink
Post by 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?
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, user
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
<https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API>.
.. 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
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/ceb9e5c1-9baa-410c-9804-f09544da284a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
TonyM
2018-04-01 01:40:02 UTC
Permalink
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
Post by PMario
Post by 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?
That's right. TiddlyWiki is event-driven, because the browser is event
driven. ...
- 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!
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
<https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API>.
.. 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
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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.
PMario
2018-04-01 09:37:52 UTC
Permalink
Post by TonyM
- 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
<https://wikilabs.github.io/editions/uni-link/#%24%3A%2Fplugins%2Fwikilabs%2Funi-link%2Funi-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 ...
Post by TonyM
- 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.
Post by TonyM
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
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/f53a3c9c-ba80-4eb3-b0c5-1f39b1b7e3f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jeremy Ruston
2018-04-01 09:43:03 UTC
Permalink
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
***@jermolene.com
https://jermolene.com
Post by 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
Post by 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?
That's right. TiddlyWiki is event-driven, because the browser is event driven. ...
- 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!
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
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
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.
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/A75214A1-406F-43E1-9A79-AD6E07EB01D7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
TonyM
2018-04-02 00:44:30 UTC
Permalink
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
Post by 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
<$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
https://jermolene.com
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
Post by 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?
That's right. TiddlyWiki is event-driven, because the browser is event driven. ...
- 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!
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
<https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API>.
.. 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
--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/tiddlywikidev/37e60174-9969-4e4e-a699-929cb7994b17%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/21e5f32a-e249-41de-b022-ec4279852577%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2018-04-03 09:01:40 UTC
Permalink
Post by TonyM
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
<https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate>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
<https://github.com/Jermolene/TiddlyWiki5/blob/52319ee88afbbca96d5084d92c2b63eecd4ab4f7/core/modules/widgets/tiddler.js#L40>
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
Post by TonyM
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 englis ;)
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/54e48cf5-6378-44cb-907a-268c45e2f6a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
TonyM
2018-04-03 23:03:57 UTC
Permalink
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
Post by PMario
Post by TonyM
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
<https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate>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
<https://github.com/Jermolene/TiddlyWiki5/blob/52319ee88afbbca96d5084d92c2b63eecd4ab4f7/core/modules/widgets/tiddler.js#L40>
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. ..
In keeping with this idea we could have* pre and post actions fields* in
Post by TonyM
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 englis ;)
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/682b54b3-bec7-4350-b8ce-4bf86600fc33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
TonyM
2018-04-03 23:40:07 UTC
Permalink
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
Post by 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
\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
--
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 tiddlywikidev+***@googlegroups.com.
To post to this group, send email to ***@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/fc4ec7db-0777-4d02-8af5-0dca0a6fc576%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...