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

On Tuesday, April 3, 2018 at 7:01:40 PM UTC+10, PMario wrote:
>
> 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 
> <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 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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to