How to make $slot and $fill palatable

#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.