Refreshing a tiddler on any change...

[Tobias Beer]

Hi everyone,

I need some help,  in how to make TiddlyWiki update some tiddler (or parts of it) when changing ANY other tiddler; the tiddler in concern gathers a list of tiddlers that may change by adding new items:
http://namespace.tiddlyspace.com/#Issue

Cheers, Tobias.

[Eric Shulman]

On Mar 1, 7:36 am, Tobias Beer <beertob...@gmail.com> wrote:
> I need some help,  in how to make TiddlyWiki update some tiddler (or parts
> of it) when changing ANY other tiddler; the tiddler in concern gathers a
> list of tiddlers that may change by adding new items:http://namespace.tiddlyspace.com/#Issue

http://www.tiddlytools.com/#AutoRefresh

This transclusion adds some special attributes to the viewer DIV of
the tiddler, so that the TWCore refreshElements() handler can
recognize it as a 'refresh-able' item.

<<tiddler AutoRefresh with: force>>

enjoy,
-e

[Tobias Beer]

Hi Eric,

thanks for the tip. However, I fear I wasn't precise enough. What I really try to achieve is is this: My plugin renders a list and when any tiddler is changed I want that list (or the tiddler in which it is rendered) to be updated.

Is there a standard way for making a macro 'refreshable' like that? Or would I rather need to hijack something?

Thanks, Tobias.

[PMario]

You can borrow the mechanism from the core list macro, which starts
here:

https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Macros.js#L41

If you need more info just post.
-m

[PMario]

The .refresh should be what you need.

https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Macros.js#L50
-m

[Tobias Beer]

Hi Mario,

 

So, doing that, the actual macro magic is deferred to a refresh method first invoked when the macro is called.

 

What (mechanism) exactly triggers a refresh in this case?

 

I mean, do these DOM attributes simply mean "Dear TiddlyWiki, whenever you refresh (anything), please rerun the macro referenced via these attributes with these params." ...which then fires the macro handler again?

 

But then, why is the refresh handler given a list - one which has not existed before the macro handler was called? Is a macro refresh handler always passed the DOM element from which it was fired? In other words, are these attributes somewhat markers that indicate "this output (wrapper) has been contructed by macro xyz"? If yes, would it be best practice to always add this stuff to a macro that renders something?

 

Cheers, Tobias.

[Yakov]

Hi Tobias,

воскресенье, 3 марта 2013 г., 16:49:01 UTC+4 пользователь Tobias Beer написал:

Hi Mario,

 

So, doing that, the actual macro magic is deferred to a refresh method first invoked when the macro is called.

 

What (mechanism) exactly triggers a refresh in this case?

 

I mean, do these DOM attributes simply mean "Dear TiddlyWiki, whenever you refresh (anything), please rerun the macro referenced via these attributes with these params." ...which then fires the macro handler again?

 

But then, why is the refresh handler given a list - one which has not existed before the macro handler was called?

Not sure what do you mean, but probably this will help:

* on wikification, .handler is called

* .handler calls the .refresh and .refresh is called by config.refreshers.macro (usual refreshing mechanism)

* .handler creates the list element and .refresh refreshs its content

* config.refreshers are used by the refreshElements function which, in turn, is used by refreshPageTemplate and refreshDisplay (and config.refreshers.tiddler), which, in turn, are called by refreshAll and are present in config.notifyTiddlers

* all functions of config.notifyTiddlers are added to store via store.addNotification on startup, those and others store.namedNotifications are called by store.notify and store.nofityAll which, in turn, is called by

** store.removeTiddler

** store.resetTiddler

** store.setTiddlerTag

** store.addTiddlerFields

** store.saveTiddler

** store.setValue

which means that the .refresh methods of macros are called at least each time[*] one of these 6 methods is used which should be enough.

So, to make any macro refreshable, just use .refresh method. Likewise, tiddler are refreshed on those store methods' calls as config.notifyTiddlers contain refreshDisplay as well.

To investigate this further, you can take a look at Refresh.js [1] and TiddlyWiki.js [2], but some things are more useful to search right in a TiddlyWiki code (I open tiddlywiki.com for that sometimes).

 

Is a macro refresh handler always passed the DOM element from which it was fired? In other words, are these attributes somewhat markers that indicate "this output (wrapper) has been contructed by macro xyz"? If yes, would it be best practice to always add this stuff to a macro that renders something?

 

Cheers, Tobias.

Best regards,

Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Refresh.js

[2] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js

[*] I may be wrong here as when I quickly looked up I haven't studied the conditionals carefully

[PMario]

On 3 Mrz., 13:49, Tobias Beer <beertob...@gmail.com> wrote:
>I mean, do these DOM attributes simply mean "Dear TiddlyWiki, whenever you
>refresh (anything), please rerun the macro referenced via these attributes
>with these params." ...which then fires the macro handler again?

It seems to work that way.
There are some issues, if the tiddler is outside the story view. eg:
right sidebar in some special cases.

> ... If yes, would it be best practice to always

> add this stuff to a macro that renders something?

imo yes.

I would need to search the source, to see how / when refresh is
activated. Yakov did it :)

-m

[Tobias Beer]

Hi Yakov (& Mario),

Thanks for the very detailed summary. I have take the liberty to add the essence of our discussion as a kind of draft to @developers [1] because this topic sure interests others [2].

Cheers, Tobias.

[1] http://tiddlywikidev.tiddlyspace.com/#Refresh

[2] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/jIeqxkIarN4

[PMario]

Hi Tobias,
I have to say, the work you do with the documentation spaces is
GREAT :)

thx mario
PS: there is only one little thing. The light blue color used for the
eg: "tiddler" links is too light for me. There is not enough contrast,
which makes reading with a gray background quite hard.

[Tobias Beer]

Hi Mario,

Hi Tobias, 
I have to say, the work you do with the documentation spaces is 
GREAT :) 

Thanks ;-)

PS: there is only one little thing. The light blue color used for the 
eg: "tiddler" links is too light for me. There is not enough contrast, 
which makes reading with a gray background quite hard. 

I noticed, you can read it but it's a bit disruptive, too. What would you think if I used the regular link color, yet not in bold... and then use the light color for the hover state? Check out the link above again.

If that's better I think I'll change the defaults for LinkifyPlugin.

Cheers, Tobias.

[Yakov]

вторник, 5 марта 2013 г., 17:10:42 UTC+4 пользователь Tobias Beer написал:

Hi Mario,

Hi Tobias, 
I have to say, the work you do with the documentation spaces is 
GREAT :) 

I'd second this one! I especially like the .. umm I don't see it now, the startup tiddler that introduced 4 "levels" of documentation (beginner/advanced/dev/architect), that looked very convenient (have you deleted it?).

Thanks ;-)

PS: there is only one little thing. The light blue color used for the 
eg: "tiddler" links is too light for me. There is not enough contrast, 
which makes reading with a gray background quite hard. 

 

I noticed, you can read it but it's a bit disruptive, too. What would you think if I used the regular link color, yet not in bold... and then use the light color for the hover state? Check out the link above again.

I'd say, if bold is not used, it's better to make the links darker.

 

If that's better I think I'll change the defaults for LinkifyPlugin.

Cheers, Tobias.

One more thing: in the docs, you wrote

> The DOM attributes added to the list macro wrapper can be interpreted as...

I'd like to point that to figure how it is refreshed, one has to look at only one attribute: "refresh". See the refreshElements function [1], it causes the avalanch of refreshing starting from a root element, it looks for the "refresh" attribue and checks that type among config.refreshers (and applies corresponding refreshers). Then, the refresher itself can look at the other attributes ("macroName" attribute is used by config.refreshers.macro to call the corresponding macro.refresh, "params"), but this can be learned from the code of refreshElements directly.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Refresh.js#L74

[Tobias Beer]

Hi Yakov,

I'd second this one! I especially like the .. umm I don't see it now, the startup tiddler that introduced 4 "levels" of documentation (beginner/advanced/dev/architect), that looked very convenient (have you deleted it?).

Would you mean the table on the startpage [1]? What was the urL by which you tried to find it? Maybe I have removed it as a standalone page.

[1] http://tiddlywiki.org

I'd say, if bold is not used, it's better to make the links darker.

I'd agree too, looks better now as opposed to before (which now is the hover state).

I'd like to point that to figure how it is refreshed, one has to look at only one attribute: "refresh". See the refreshElements function [1], it causes the avalanch of refreshing starting from a root element, it looks for the "refresh" attribue and checks that type among config.refreshers (and applies corresponding refreshers). Then, the refresher itself can look at the other attributes ("macroName" attribute is used by config.refreshers.macro to call the corresponding macro.refresh, "params"), but this can be learned from the code of refreshElements directly.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Refresh.js#L74

I'll see what I can add to the documentation, unless you want to ;-)

http://tiddlywikidev.tiddlyspace.com/#Refresh

Cheers, Tobias. 

[PMario]

On 5 Mrz., 14:10, Tobias Beer <beertob...@gmail.com> wrote:
> I noticed, you can read it but it's a bit disruptive, too. What would you
> think if I used the regular link color, yet not in bold... and then use the
> light color for the hover state? Check out the link above again.
>
> If that's better I think I'll change the defaults for LinkifyPlugin.

I think it's better now.
-m

[Tobias Beer]

Ok, I've swapped them in the plugin code and released a new version.

Cheers, Tobias.

[Yakov]

вторник, 5 марта 2013 г., 19:26:18 UTC+4 пользователь Tobias Beer написал:

Hi Yakov,

I'd second this one! I especially like the .. umm I don't see it now, the startup tiddler that introduced 4 "levels" of documentation (beginner/advanced/dev/architect), that looked very convenient (have you deleted it?).

Would you mean the table on the startpage [1]? What was the urL by which you tried to find it? Maybe I have removed it as a standalone page.

[1] http://tiddlywiki.org

Ah, yes, that's it, forgot that it's another space. 

I'd say, if bold is not used, it's better to make the links darker.

I'd agree too, looks better now as opposed to before (which now is the hover state).

I'd like to point that to figure how it is refreshed, one has to look at only one attribute: "refresh". See the refreshElements function [1], it causes the avalanch of refreshing starting from a root element, it looks for the "refresh" attribue and checks that type among config.refreshers (and applies corresponding refreshers). Then, the refresher itself can look at the other attributes ("macroName" attribute is used by config.refreshers.macro to call the corresponding macro.refresh, "params"), but this can be learned from the code of refreshElements directly.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Refresh.js#L74

I'll see what I can add to the documentation, unless you want to ;-)

http://tiddlywikidev.tiddlyspace.com/#Refresh

Well, anyway being a member of tiddlywikidev space wouldn't be excessive. (currently, I can't edit)

 

Cheers, Tobias.