How to make $slot and $fill palatable

#7

Yeah, it looks like you’ve found a use for /widget, and it also looks like you agree that it’s over verbose. Before v5.3.x, I would have done something like this:

<<list-report "[tag[TableOfContents]]"
header:"""

!!Your report header
"""
footer: """

<small> Your report footer</small>
""" >>

Funny thing is, even though I’m committing the cardinal sin of putting wikitext into attributes, this works just fine. I use patterns like this all the time (and it’s less verbose).

What I would love is if the pattern I described above would work. I think that would be a super clean solution. E.G.

\widget $list.header() <$fill $name=header><$slot $name=ts-raw>Empty</$slot></$fill>

If that could work, then this would be a neat feature. I guess the widget doesn’t unfold enough in the parse tree or something? Not sure why the outer $list.report couldn’t find that buried $fill.

#8

I don’t think it (blocks in procedure calls) is a sin, I just find it fragile and also hard to explain. I also think it looks ugly.

  • I am not sure I follow your example.
#9

My idea is that the <$fill $name=header>Content Here</$fill> could be wrapped in another custom widget, so then you could call <$list.header>Content Here</$list.header>.

I think that provides something nicer to end users. Plugin developers could develop a small suite of widgets designed to be nested within each other, and it’s a lot easier than instructing end users to use stuff like <$fill $name=...>... when they probably won’t even know what $fill is. (I think we can all agree it is not a widget for beginners.)

#10

Agreed, perhaps we can use the Genesis widget to redefine the fill widget?

  • I/we will have to experiment.
1 Like
#11

Here is my first attempt, not working any ideas?

\procedure section(name content:"default")
<$genesis $type="$fill" $$name=<<name>>><<content>></$genesis>
\end
\widget $test.widget()
<$slot $name="test"/>
\end $test.widget

<$test.widget>
<<section test "section content">>
<!-- <$fill $name=test>
Content
</$fill> -->
</$test.widget>
  • I suspect since the fill widget is only valid in side a widget, using the genesis widget to redefine it outside the widget, it will not work?
  • Wonder if we could dump the fill/slot widgets and somehow use html sections and arbitrary tags?
#12

I think you’re hitting the same problem I did. You’re right that unless the fill widget is directly inside the widget it’s trying to fill, it won’t work, which is disappointing.

Using html sections and arbitrary tags I think would introduce the potential for conflicts without much more benefit. Imagine that your \widget uses a slot for the tag section. When people use your widget, they could use section as a fill, but they can no longer use section as it was originally intended under HTML5. The \widget could just as easily explicitly define another widget to be used alongside of it using the $ syntax, and that would be exactly as verbose as using html5 tags, but more maintainable I’d think.

Too bad none of these ideas work though.

Multilanguage tiddler - a use case for the new $slot and $fill widgets
#13

Yes, the only way I can thing of to reduce the verbocity of fill widgets is to reduce it from <$fill $name="headder">...</$fill> to something like <$.header>...</$.header> but then it becomes “bespoke”, or if there were some special symbols like &header& … /&header& (just a guess) that automagicaly creates a fill widget the slot could access.

#14

I have to say, it’s a shame this wasn’t brought up in the lengthy discussions during the lead-up to 5.3.0.

Perhaps this is a lesson for the future, Github isn’t enough.

#15

Yeah, I would have brought up a lot of things in that discussion, but I wasn’t really involved in the community for a few months. I’d have had some things to say.

But even so, the thing we’re proposing here would just be an elaboration on what’s already done. It shouldn’t be too hard to implement now (I hope). It wouldn’t break any backward compatibility (I think), and it’s an intuitive application of the \widget (I believe).

#16

My personal view is in github it was a large body of work undertaken by developers and the proposed changes where never documented maturely enough that super users could understand it enough, to then provide feedback, let alone do any user testing.

  • I did my best to contribute but then it was not easy as every attempt needed hours of prereading and trying to understand, let alone forecast how it will look as a user, was next to impossible.
  • There was a lot of motivations in the core team to make changes, all good and well, but every change can have an impact of the users naive or otherwise and it is hard sometimes as a developer in the know, to imagine how others read it, and would use it.
#17

The slot and fill widgets are indeed clumsy within custom widgets because they force the caller to use a generic <$fill> widget which may not be a good match for the semantics of the custom widget.

The intention is to allow transclusions to reach into the parse tree nodes of the contents of the calling transclusion, and find and extract whatever widgets it wants. Thus a custom widget could define its own custom sub-widgets. This matches the way that JavaScript widgets are constructed: they have control over how their contained widgets are rendered.

We do already provide access to the parse tree nodes via the <$parameters> widget, but doing this will require quite a bit more infrastructure concerned with manipulating parse trees: JSON treewalking operators that can be used to search for custom widgets, and the ability to transclude a parse tree directly. And a suitable high level syntax.

Those are useful features in any case, and will enable us to address some other long-standing concerns.

2 Likes
#18

I must admit, I’m having trouble understanding what you’re trying to say.

I mean, even with the <$parameters>, it looks like someone has to resort to using <$fill> widgets in order to fill slots. But it sounds like you’re saying (and correct me if I’m wrong), that end users are never expected to do this??? That all this intricate transclusion is designed for plugin developers to make… elaborate templates, or widgets?

It still seems like however it’s cut, whether for custom widgets or transcluded templates, it’s still this clunky syntax that requires users to have the documentation open.

And about that, is there an effort underway to improve the documentation? Because I’m trying to update Relink and Uglify, and so I’m having to make myself abreast of all these new features, like <$slot>, <$fill>, and <$parameters>, (and $depth), and I still have no idea why anyone would use these things.

#19

I guess I should ask how anyone would use these things. I can see the benefits of having custom widgets (parameterized tiddlers, not so much).

But I have yet to think of a use case that wasn’t already covered by existing TiddlyWiki techniques.

#20

In the 5.3.2 prerelease we have the introduction of

support for <$list-template> and <$list-empty> as immediate children of the $ListWidget widget to specify the list item template and/or the empty template.

  • Personally I am not sure of the value, including the <$list-join> because I personally have what I feel are better ways to do the same.

However It makes me wonder, if inside the custom widgets, the naming of the slot widget could itself look for a matching fill widget, but a custom one, by the name used in the slot widget.

<$slot name=reportbody/>

Would then “look for” <$reportbody>something</$reportbody> rather than the fill widget, instead a automatically named custom widget.

I am sure it depends on the way the code works but this would be an acceptable approach, to me.

However I think an additional feature could be made to support this, have a more powerful feature added. I will update this reply soon.

[edited]

Perhaps someone here has some ideas but could we perhaps define custom widgets that can replace a generic fill widget, perhaps using the genesis widget that can replace the use of generic fill widgets with specific named ones, not unlike the list-template/list-item/list-join templates?

So then we can call our custom widget, containing custom fill widgets?

<$my.widget  params
   <$name1>a</$name1> 
   <$name1>b</$name1> 
</$my.widget>

and within $my.widget

<$slot name=name1/>
<$slot name=name2/>
  • part of this motivation is while making our custom widget is in “design time” and we can cope with obtuse widgets like $slot, but calling $my.widget is in “author time”, when we use and apply our development work. And we do this authorship multiple times, so the value of ease of use and reading, is much more valuable in the calling widget.
#21

Are they seriously adding even more widgets to add to widget verbosity without even having finished the discussion on how to make the existing new features practical?

Seriously? $list-empty???

So now our lists will look like this?

<$list filter="[tag[myTag]]">
<$list-template>
Stuff to be repeated per item.
</$list-template>
<$list-empty>
There are no items in this list.
</$list-empty>
</$list>

Just rolls off the tongue, doesn’t it? Meanwhile the list widget will have special handling to look into itself to see if either of those widgets to decide whether to have its pre-v5.3.x behavior or its post-v5.3.x behavior.

But we haven’t finished the discussion on whether <$fill> widgets should render by default (which they shouldn’t), which would completely eliminate the need for these.

These are not features end-users will ever use. They hardly understand how <$list> widgets work to begin with. No one is going to be slot filling except for plugin-developers, so why are we introducing all this syntactic sugar for them?!?

#22

Where the hell are they talking about this feature? Am I actually in time to stop a trainwreck this time?

These are bad features.

#23

On the pre release click on a hilighted word next to a feature and it usually takes you to the related GitHub issue.

Please try and be a little more specific in your critisisiums. This thread is about the verbosity of the $fill widget. Perhaps a new thread is needed for these new list sub widgets. I too think they are unnessasary and if I want something similar we can use a custom widget and the genesis widget.

@jeremyruston we need to start a discussion.

There is currently a weakness in user requirements acceptance testing meaning we get solutions driven by developers and insufficent contributions from superusers. We just get to work out how to use it.

  • As a result tiddlywiki is getting more complex than it need be.
  • It’s important to solve platform issues but not at the expense of creating user issues.
#24

I admit. Trainwreck was harsh. I’m frustrated because new features are already going in again and I haven’t even finished bringing Relink and Uglify up to date for 5.3.0. I’ve moved my criticisms of those ideas to more relevant pages.

With regards to your suggestion:

That’s not bad. I think we’re fundamentally in agreement about what sort of syntax the end user should be using/seeing in documentation. I’m in a knee-jerk mode to dissuade new features, so I’d rather see existing features work the way you’d intuitively expect them to instead of introducing more features. Which is why I pushed for

\widget $my.reportbody()
<$fill $name=reportbody><$slot $name=ts-raw /></$fill>
\widget

I’m not saying what I’m suggesting is better, only that it’s using existing functionality in a way that you’d THINK should work, but doesn’t. It’s almost more like a bug report to me than a feature request.

Your system would be cleaner, (albeit more features), and might be nice for the five people in the world actually using \widget with custom slots.

Edit: Grammar fixes. Trash sentence-fragment removal.

#25

Ha. Me, too. Frequently. Wondering why it seems to be happening more, lately. Perhaps I’m in too much of a.

(see what I did there? :wink: )

1 Like
#26

I recently raised in Github the idea that once defined the ts-raw, proposed ts-body and the named fill widgets be available as simple variables inside the custom widget with or without using the slot widget.

  • This would be much more functional allowing the slots to be referenced as variable and used as attribute values/ parameters and more.
  • At least the slot widgets would be more palatable this way.