Hi My approach to writing widgets was to start out with a widget from the core with the desired behaviour (my prototype: the LinkCatcher widget) -- then modify this prototype with snippets of code from other core widgets. This approach would not be possible for widgets that include entirely new functionality.
The exception was my MakeTid widget -- which includes a large chunk of code from the NewTiddler widget. Hopefully there will soon be an implementation of NewTiddler in the core, which will either render the MakeTid widget redundant or permit me to clone this code from the core for the MakeTid widget. thus maintaining compatibility (the key difference: the MakeTid widget intercepts the 'tw-new-tiddler' message from the button and creates a new tiddler which can subsequently be modified by other widgets in the outer stack.) My plan was to keep the interaction between widgets limited to widget messaging (which should be a transparent process) and to make use of core functionality wherever possible. For example, the MakeTid widget uses the functionality of the Button Widget rather than including its own code to create a button, as in the case of the NewTiddler widget. The problems I faced, therefore, revolved around controlling the messaging -- that is, controlling the scope (container) of the message to prevent multiple calls of the same widget from messages 'bouncing' around the stack. To avoid conflicts with other widgets, I created new messages that would be ignored by other widgets -- this should limit my problems to making my widgets work together in the way intended. All in all -- a trial and error process rather than a top down design approach. regards On Tuesday, June 3, 2014 5:16:10 PM UTC+2, Andreas Hahn wrote: > > Hi, > > I am more or less new to TW and I may not have a good overview or a good > understanding, but there is something I have been wondering about and > maybe your answers will help me to deepen my understanding of TW. > > From what I can tell widgets are a way to enhance WikiText with the > goal of displaying content that it would not normally be able to display > by default. A good example would be the list widget. Many of these > widgets also provide a little bit of functionality that would otherwise > not exist. Examples here are the widgets that provide the typical > HTML-Form elements like a button, a checkbox/radiobox, textareas, etc.. > > But I notice that an increasing number of widgets just exist to do a > purely functional task which mostly does not involve rendering things or > doing something with the child elements of that widget. And most of > these are not designed to play exceptionally well together. > > For example the checkbox widget works on tags, the edit widget on > fields. To use them for something else, you usually have to do something > extra, like transcluding the field or checking for tags. > Also widgets make use of different concepts, the $mangletags widget from > Matabele follows his stacking mechanism where high-level functionality > is archieved by wrapping AROUND a source element, which propagates the > target UP the stack. Other widgets like the core set widgets propagate > variables DOWN the stack and are used to provide the necessary > parameters for the high-level functionality INSIDE the stack. Some use > messages as parameters, others solely rely on their attributes as input. > > Now my question: Is there a guideline or a core concept which is meant > to ensure that widgets work well together ? Are widgets even supposed to > work together ? (How will they do this in the future ?) And finally: > what was the idea/purpose behind widgets when TW was created ? > > I would love a short explanation of the more or less theoretical > background and concepts of this part of TW. > > Thanks > /Andreas > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
