[TW5] Instantiate a list widget in custom widget

[Tobias Beer]

Hi there,

Anyone willing and able to tell me how I would I basically go about

creating another (list) widget in my own widget in terms of :

1. passing it the appropriate attributes
   
2. rendering it

I first wanted to implement the reveal widget but then I thought

I'd rather prefer the templating capabilities of the list widget.

Actually, I think I want to do both in the end, a list nested inside a reveal.

So, here's actually what I want to do in my widget:

1. create a ButtonWidget
2. create a RevealWidget
   
1. create a ListWidget as a child to it
3. parameterize all the above and render
4. store references... to:
• access and manipulate those "kids" from some event handlers later
  

Best wishes,

Tobias.

[Tobias Beer]

Hi again,

Wanting to create a reveal, a parseTreeNode expects me to define the type property as the name of the widget.

However, the reveal widget has a type property of its own. How to initialize?

Does that also mean that any widget should better avoid to have a "children" attribute (for the same conflicting reasons)?

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

Wanting to create a reveal, a parseTreeNode expects me to define the type property as the name of the widget.

However, the reveal widget has a type property of its own. How to initialize?

Does that also mean that any widget should better avoid to have a "children" attribute (for the same conflicting reasons)?

The “type” attribute for the reveal widget is passed within the “attributes” member of the parse tree node, entirely separate from the “type” property on the parse tree node.

A good example of a widget that generates other widgets is the edit widget:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/widgets/edit.js#L52-L61

Best wishes

Jeremy.

Best wishes,

Tobias.

--
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/c026123f-2119-4652-a6b6-a95d88cbbeb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

Hi Jeremy,

 

The “type” attribute for the reveal widget is passed within the “attributes” member of the parse tree node, entirely separate from the “type” property on the parse tree node.

Ah, of course. I overlooked that bit. Thanks for the pointers.

Best wishes,

Tobias.

[Tobias Beer]

@Jeremy,

(How) Would I be able to access the child widgets that get created via makeChildWidgets from the creating widget? ...or is it that I (simply) need to initialize them according to the specified attributes, before creating them.

Best wishes,

Tobias.

[BJ]

Hi Tobias,
you can access child widgets thru

this.children

which is the array holding the child widgets

[Tobias Beer]

Hi Matabele,

 

this.children

which is the array holding the child widgets

Ah, of course. Sometimes, when things are new, there's that veil. ;-)

Sometimes you read that code but the ways things work just haven't sunk in yet.

I'm all new to widget-land and thinking it will be a grand, enjoyable journey.
Please bear with me as I do these toddler steps.

Best wishes,

Tobias.

[Matabele]

Hi

Was BJ's post, not mine :-)

I'm not sure as to your final objective, but widgets may already be nested like so:

<$button tooltip="Modify All">
<$list filter="[tag[MyTag]]">
<$action-setfield $tiddler=<<currentTiddler>> tags="[[tag one]] [[tag two]]" caption="something"/>
</$list>
Modify All
</$button>

The enclosed action-widgets will all get triggered by a click of the button. Another approach is to use BJ's $click widget to add a listener to trigger the event, but I find action-widgets to be the simpler approach.

regards

[Tobias Beer]

Hi Matabele,

 

Was BJ's post, not mine :-)

Oh, well, sorry 'bout that BJ ...thanks for chiming in anyway, Matabele. :D

 

I'm not sure as to your final objective, but widgets may already be nested like so:

I know we can (try to) achieve complex wikitext constructs to make ends meet with (sometimes a plethora of helper-)macros, but what I am trying to do here is to make that much simpler for both the end user... as well as for me, the dev. Those wikitext macros are quite horrible to both develop and maintain. So, a widget that instantiates the right lower level widgets may just be a good thing to (know how to best) do.

QUESTION

To force a child widget being a reveal into either block or inline mode, do I simply set isBlock: true / false?

Best wishes,

Tobias.

[Matabele]

Hi Tobias

I agree -- and widgets tend to be more easily found and re-used, and better documented. On numerous occasions I know I have seen/used a snippet of wikitext to solve a similar problem, but can't lay my hands on the snippet.

Too many widgets will, however, bloat the codebase. It's a matter of designing a few 'clever' widgets which are generally useful. In this regard, I believe many of the existing widgets need redesigning and consolidating. The redesign of my button widgets ended up with only three widgets (and I am working on reducing this to only two.)

The major constraint -- backward compatibility :-(

regards

On Friday, 11 December 2015 12:32:25 UTC+2, Tobias Beer wrote:

I know we can (try to) achieve complex wikitext constructs to make ends meet with (sometimes a plethora of helper-)macros, but ... Those wikitext macros are quite horrible to both develop and maintain. 

 

QUESTION

To force a child widget being a reveal into either block or inline mode, do I simply set isBlock: true / false?

The handling of the 'mode=' attribute of the $transclude widget may suggest some ideas

regards

[Tobias Beer]

Hi Matabele,

 

To force a child widget being a reveal into either block or inline mode, do I simply set isBlock: true / false?

The handling of the 'mode=' attribute of the $transclude widget may suggest some ideas

Trial and error has me believe that I can set, even override this.parseTreeNode.isBlock

no matter what the parser initialized it with. So that's great.

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Tobias

Trial and error has me believe that I can set, even override this.parseTreeNode.isBlock

no matter what the parser initialized it with. So that's great.

Please don’t do that! The parse tree for a particular tiddler is cached and shared so if you make modifications to it then any other code that tries to parse the same tiddler will get the modified parse tree.

Perhaps we can move this particular discussion to GitHub; it’s much easier to talk about code there.

Best wishes

Jeremy

Best wishes,

Tobias.

--
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 https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0bcda88e-a162-40cb-b87c-487bb0ea6eca%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

Perhaps we can move this particular discussion to GitHub; it’s much easier to talk about code there.

I'll show you what my widget does shortly and why it is necessary that it's not the parser that gets to decide (for the widget!) if it's meant to be block or inline mode ...solely based on whatever inner content the widget may hold.

Best wishes,

Tobias.

[Tobias Beer]

Also, let's say my widget has an attribute "mode" and I set it to "inline". Whatever the parser thinks it is, if my widget decides, based on this attributes that it is indeed configured to be an inline element... then it should be given that authority, or rather... a user should be given that authority, no matter what the parser may think it looks at.

Best wishes,

Tobias.