there is not a performance problem with messages but with updating the ui via the refresh process as there can be thousands of widgets and a refresh is at present global - I have a plugin that allows local refresh to get round this problem. In general, where real-time matters, applications should avoid re-creating the widget tree to make changes to the ui and keep the logic inside the widgets (making changes to the dom via handler functions in response to dom events/messages/invoking actions). In my media application I use both action widget and messages - I have a controller widget and some slaves widgets, the slaves are controlled via 'actions' and send messages to the controller. For drag and drop operations I am using messaging and am developing a collection of widgets that catch messages - I have a 'ondrop' widget which generates messages.
On Saturday, March 7, 2015 at 1:14:50 PM UTC-6, PE Pat wrote: > > Thanks BJ, your explanation that you linked to was very helpful. I am both > concerned with ease of coding (on my end) and response time (on the user > end). > > Let me see if I understand this correctly: by invoking an action, a new > child is created, so the control gets passed to the new child directly. But > by calling a message, the message gets passed up the tree until it is > caught by the widget that is listening for it (most likely in my case, the > Navigator widget) so it is slower, because it might have to pass through > several nodes on the way. > > A few more questions: > > What about memory usage? Does creating a new child widget use up any > appreciable amount of RAM? > > Does it take time to create a child widget? > > If we could ensure that a message would be caught by the first parent > node, or that it could be caught within the widget itself, would this solve > the performance problems associated with widget messages? > > Thanks, > Pat > > On Saturday, March 7, 2015 at 1:42:56 PM UTC-5, BJ wrote: >> >> HI Pat, >> when you are writing a widget which response to some event, it is >> possible to cause other events. Action events (at present) are children - >> so the control passes in the direction away from the root of the widget >> tree, conversely messages travel in the other direction, toward the root, >> and are caught by a widget that is listening for that type of message. I >> talk a little about it here: >> >> https://groups.google.com/forum/#!searchin/tiddlywikidev/design/tiddlywikidev/et0wVg-J6Gw/TjAdeVUhyGMJ >> >> cheers >> BJ >> >> On Saturday, March 7, 2015 at 12:21:01 PM UTC-6, PE Pat wrote: >>> >>> Hi all, >>> >>> As I learn more about TW, I am coming into more contact with its core >>> structure, but I still don't really understand it. What is the difference >>> between action widgets and messages, in terms of how they are handled and >>> how they can be used? >>> >>> My usecase: a unit planner app, which is essentially a program that >>> manages a bunch of different lists. Currently, I have action widgets called >>> <$append> and <$remove> which add or remove a tiddler/tiddlers to lists in >>> other tiddlers, but I am starting to think that those might be more >>> appropriately implemented as messages. >>> >>> Here's why: I see that I can dispatch a message within the Javascript >>> code of a widget, but I don't know if I can call a widget from inside >>> another widget (or if that even makes sense in TW). So I guess my specific >>> question is: does it make more sense to define common list operations as >>> messages so that they can be dispatched as necessary in other, more >>> complicated widgets? >>> >>> Thanks, >>> Pat >>> >> -- 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 http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
