[TW5] Force refresh a widget

[Tobias Beer]

Hi everyone (possibly @Jeremy),

How can I force-refresh a child widget from its parent?

I have changed the content / children of my button widget via...

childButton.children = this.wiki.parseText(
    "text/vnd.tiddlywiki",
    newLabel,
    {parseAsInline: true}
).tree;

...but then calling:

childButton.refresh();

wouldn't work since, the ButtonWidget refresh handler doesn't appear to check for any changes to its content.

So, I tried to run:

childButton.refreshSelf();

...but that didn't work either.

Any ideas how I can force-refresh my childButton without having to refresh my entire widget?

Best wishes,

Tobias.

[Felix Küppers]

Hi Tobi,

I think you are looking for:

this.refreshChildren(changedTiddlers);

-Felix

--
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 http://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/d2e86207-ab3c-4809-b1d9-d10697269c17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Felix,

Yes, I just realized today what is meant with "widgets are stateless" and changedTiddlers kinda hints at it. If there are none of those there's no refreshing. So, I'll entirely stop manipulating child-widgets from the parent widgets via event handlers and instead have my child-widget structure pretty much duplicate what I would have been doing in a macro, however ...in a widget ... with well structured code rather than a whole bucket of trial and error macro magic that is close to impossible to decipher later.

Best wishes,

Tobias. 

[Felix Küppers]

Yap, TW really behaves like an agent system where each widget delegates the refresh to the child widgets and the child widgets decide for themselves. The only exception is when a widget fully restarts (refreshes) itself and newly creates all children.

-Felix

--
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 http://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0c3b5028-7de2-41ba-a711-320d20a06b4b%40googlegroups.com.

[Jeremy Ruston]

Hi Tobias

If you want to change the attributes of child widgets that your widget has created, then you must re-execute the child widget(s) so that they are recreated from the updated parseTreeNode.

Again, it would be useful to see some code :)

Best wishes

Jeremy

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/BLU436-SMTP745D94FAE47BB0677EE933CEEC0%40phx.gbl.

[Tobias Beer]

Hi Jeremy,

 

Again, it would be useful to see some code :)

I'll push some of that, possibly tomorrow, up on GitHub... and link to it from here.

Best wishes,

Tobias. 

[Tobias Beer]

@Jeremy,

 

Again, it would be useful to see some code :)

As promised, here's the demo:

http://appear-demo.tiddlyspot.com

And here's the commented widget code:

https://github.com/tobibeer/tw5-appear/blob/master/src/appear.js

Some code for the absolute popup handling will eventually be thrown out,

once the core popup / button widget supports it.

As for the state I am writing to when rendering my widget,

I'll only ever write to the state, should the corresponding parseTreeNode(s) change.

In other words, once in most all cases.

Also, "handler-states" are written to $:/temp, so they're not pesisted, ever.

Best wishes,

Tobias.

[Matabele]

Hi Tobias

Nice :-) However I'm going to introduce further complications.

I tried to use the widget to create sticky notes -- like so:

Sticky1: <$appear>
<$edit-text tiddler="MyTarget"/>
</$appear>

Sticky2: <$appear>
<$edit-text tiddler="MyTarget2"/>
</$appear>

There are two problems that might be worth having a look at:

-- the refresh mechanism makes editing problematic (even though I am editing a field in another tiddler)

-- the two calls use the same state reference by default (and open together)

Would it not be preferable to automatically generate a unique state reference by default each time the widget is used?

Is it necessary to refresh the widget after each keystroke?

regards

[Tobias Beer]

Hi Matabele,

 

Would it not be preferable to automatically generate a unique state reference by default each time the widget is used?

Is it necessary to refresh the widget after each keystroke?

Currently, the refreshing is watching for any attributes changes, which should not be problematic though.

However, a little investigation has me believe this bit of code is the culprit:

// Any children changed?

if(!this.handle && this.refreshChildren(changedTiddlers)) {

// Refresh the appear widget => needed for lack of core support for absolute popups

this.refreshSelf();

return true;

}

The problem is, that I need to force-recreate the button because it would otherwise lose the hacky click handler I throw onto it ... so as to make absolute positioning work.

For now, I think I will need to skip "remote handlers" so long as PR 2128 is not merged and available with the next release.

Best wishes,

Tobias.

[Tobias Beer]

As for...

 

For now, I think I will need to skip "remote handlers" so long as PR 2128 is not merged and available with the next release.

What I could also do is discard using the ButtonWidget altogether and only replicate the subset of code I need with:

<$appear button absolute popup state="$:/state/foo" class="bar" tooltip="baz">label</$appear>

...massaging my widget to have a "button-mode" and have it create the exact button I need it, under the hood.

Then I can give the actual domnode being the button whatever custom-click handler I want.

A bit more code, however with full control and no need to wait for potential future core compatibility with respect to absolutely positioned popups.

I won't do the same with the reveal, though. :D

Best wishes,

Tobias.

[Tobias Beer]

Hi Matabele,

Would it not be preferable to automatically generate a unique state reference by default each time the widget is used?
Is it necessary to refresh the widget after each keystroke?

I did two things:

1. removed an obvious bug in the refresh handling which was the very last line
2. the widget now only refreshes with child-refreshes under well defined conditions

As for editors inside a popup, they are currently not supported by the core.
So, I created an issue for this:

#2134 sticky popups 

https://github.com/Jermolene/TiddlyWiki5/issues/2134

A bit weird, I would have thought popups would not close if I clicked inside one.

I think the default behavior should be changed accordingly.

Also, I fiddled a bit with the below and decided that I will definitely not do it...

 

What I could also do is discard using the ButtonWidget altogether and only replicate the subset of code I need with:

...simply too much code replication, after all.

Best wishes,

Tobias.