Cascades and Hide Type and Fields in Edit Mode

[kookma]

Is there a way to use cascades and hide tiddler type and tiddler fields in edit mode?

I know there are other methods like setting visibility of fields to do this, but here I am looking for a cascade method!

Ref

• https://talk.tiddlywiki.org/t/question-hide-a-field-conditionally/2351
• https://talk.tiddlywiki.org/t/gatha-plugin-experimental-release/2272/47

[pmario]

I think cascades are not the right thing to do this.

• First there is an existing mechanism to hide fields, which is tested and compatible.
• Second, a cascade stops with the first filter, that is found.

I think the second point is important here. ... It should be simple, to create a button, that "bulk hides" fields with a special prefix. ...

I did create an experimental Field Visibility Plugin, for the field-editor edition, which allows users to hide special fields, one by one.

But as I wrote it should be simple to create some "batch processing" with a filter using the existing "visibility" tiddlers. The advantage will be that it is 100% core and tested.

Saq pointed out, that "hijacking the info tab" isn't the best way to do it. I found out, that the Field Visibility Plugin also should contain the code and a setting to show the tiddler info-area in the EditTemplate. ... So there is room for improvement.

[kookma]

Thank you Mario. I give a try and back to you with the result.

[Jermolene]

Hi @kookma @pmario – determining whether to show or hide individual fields would actually be a reasonable fit for the cascade mechanism. The chief characteristic is that of multiple independent rules yielding a single result. However, we need to strike a balance: we can't apply the cascade mechanism in every conceivable place in the UI without making everything more complicated, and impacting performance.

[pmario]

..determining whether to show or hide individual fields would actually be a reasonable fit for the cascade mechanism. The chief characteristic is that of multiple independent rules yielding a single result.

That's true. But for backwards compatibility reasons, we would need to include the existing mechanism in the cascade too. So adding the cascade also adds more complexity, as you wrote. ...

.. However, we need to strike a balance: we can't apply the cascade mechanism in every conceivable place in the UI without making everything more complicated, and impacting performance.

It wouldn't worry about the performance implications too much for EditTemplates. ... If a user opens a tiddler for editing, they probably will expect a little bit of delay and in normal cases only a view tiddlers are open for editing at the same time.

---

On the other hand we did implement several cascades for the ViewTemplate to make it more flexible for plugin authors. ... But due to the "forced 5.2.1 release" by some Chrome hickups, we didn't have much time to experiment with the EditTemplate and cascades. ... So it may be worth an other attempt to make that layout more flexible too.

[Alzacon]

I don't know if the cascade mechanism is for this. With cascade we choose a template for the tiddler, this template can have several filter. But we only want to modify/extend the filter when a condition is true.

This reminds me of this thread in GG where there was two solution:

• hack in the template
• hack in the filter

I think that it could be helpful if we can extend the filter inserting a filter expression from field or macro. Then we could think about conditional extensión.

Maybe with a new attribute in listwidget, where we also could also use the cascade to choose that filter expression would be inserted.

<$list filter="[tag[HelloThere]]" extend="[tag[Articles]]">
...

or

\define myfilter() [tag[Articles]]
<$list filter="[tag[HelloThere]]" extend=<<myfilter>> >
...

The final filter will be--> [tag[HelloThere]] [tag[Articles]]

For conditional extension, we could do

<$list filter="[tag[HelloThere]]" extend=":cascade[$:/tags/TheDummyFilter]]">
--> [tag[HelloThere]] FilterExpressionFromCascade