[TW5] Collapsing and expanding parts and the whole of a list

[cmari]

Now that I have finally figured out how to expand and collapse separate parts of a filtered list independently of one another,
I'd like to be able to expand or collapse the entire list with one click, and I can't figure out how to do that.
I've put up examples of the brick walls I've run into at
http://cmaritw5.tiddlyspot.com/
I was hoping to come up with a macro that would allow easy substitution of both fields and tags into the filters for the list.
Has anyone done something like this already?
cmari

[Mat]

Simple w css, no?

div..
clicking button sets e.g field to "none" or "block"
display:{{!!thefield}};

<:-)

[cmari]

Hi Mat,
I appreciate your reply, but I have no idea how to implement what you've described, or to use it to accomplish what I'm trying to do. My examples didn't include anything called "thefield", and what I want to display is tiddlers, not fields. I know how to set fields using a button - but what I think I need to be able to do is to <$reveal> tiddlers based on the contents of a field - and I don't know how to do that.

What's frustrating is that I knew how to do this with plugins in TWc. If this is "simple", that confirms my fear that I'm "simply" too dumb to make the transition to TW5.
cmari

[Eric Shulman]

In your 2nd example, you track the state of each reveal using tiddlers named with "$:/state/category/" as a prefix and a <<qualify>> hash number as a suffix.  The values in these tiddlers are either "show" or "hide".  Thus, to show/hide all reveals at once, you can create buttons that act on all the state tiddlers, like this:

<$button> close all

   <$list filter="[prefix[$:/state/category/]suffix<qualify>]">

      <$action-setfield tiddler=<<listItem>> text="hide"/>

   </$list>

</$button>

<$button> open all

   <$list filter="[prefix[$:/state/category/]suffix<qualify>]">

      <$action-setfield tiddler=<<listItem>> text="show"/>

   </$list>

</$button>

Note that the buttons only operate on state tiddlers that already exist.  Thus, you need to manually open each individual $reveal to create the corresponding state tiddler.  From then on, the buttons will toggle the value in that state tiddler (as well as any other $:/state/category tiddlers that exist).

enjoy,

-e

[Mat]

On Monday, January 11, 2016 at 4:43:48 AM UTC+1, cmari wrote:

Hi Mat,
I appreciate your reply, but I have no idea how to implement what you've described,

Sorry for my sloppy post. Anyway, I assume you're happy with Erics reply.

(But I do believe it should be fairly simple with CSS - assuming one knows some of that - using the CSS display property and having it read a value from a field. And that you toggle this field with a button. I'm in a hurry atm so can't test around.)

<:-)

[Eric Shulman]

errata....

I used a variable reference, <<listitem>> that I forgot to define in the $list widgets

either:

A) add: variable="listitem" to each $list widget

or

B) use: tiddler=<<currentTiddler>> in each $action-setfield

-e

[Mat]

@cmari

Proper reply:

But first of all I should say: Take a look at the RevealWidget and the "Accordion or Slider" chapter. Isn't this exactly what you want?

Ok, the CSS way:

<$button set="!!display" setTo="block">Show me</$button>
<$button set="!!display" setTo="none">Hide me</$button>

<div class="display">
Daaay-ooo!
</div>

<style>
.display {display:{{!!display}};}
</style>

That last line might look funny if you're not familiar with CSS. It translates to:

For the class called display ... apply the CSS-property display ... and set its value to the value in this tiddlers display field.

The CSS display property controls whether or not to display a div.

I've made the example as simple as possible which results in two buttons. I guess you can use reveal statuses to show one or the other.

[Tobias Beer]

Hi Mat,

Ok, the CSS way...

This solution is not good in more than one way.

1. For one, the class should be unique in your wiki.
   
2. Then, storing state at the tiddler just to toggle something is really bad.
   
• Every time you click, your tiddler will be modified.
3. I'm sure there's more...

Please use reveals and states.

That's what they're for.

Best wishes,

Tobias.

[Mat]

Tobias, that's valuable input, thanks! Just to make sure I understand;

For one, the class should be unique in your wiki.

Because the buttons are unique, right?

1. Then, storing state at the tiddler just to toggle something is really bad.
   
• Every time you click, your tiddler will be modified.

Why is this a problem? Whichever tiddler that stores it will be modified, no? (...or are perhaps tiddlers prefixed $:/state/ treated differently in this? I can't find info in the docs.)
 

1. I'm sure there's more...

Please use reveals and states.

That's what they're for.

I'm thinking that if something can easily be made with html+css then this is preferred before widgets beause the former is more browser native, no?


Again, thanks for pointing out improvements and errors!

<:-)

[cmari]

@Mat, thanks for the more detailed info! In my examples at tiddlyspot, I tried to make clear that I don't want an accordion and I have multiple sliders in a single tiddler (so the Accordion is not what I want). 

I also don't want the category tiddler to be modified every time I open the slider (so the style solution isn't ideal either).

cmari

[cmari]

@Eric, thanks, this worked perfectly. I had tried suffix, but didn't think about also using prefix. (Oddly, <<listitem>> actually worked as you originally posted it, without changing to <<currentTiddler>>. This was discouraging because I couldn't figure out where it came from and thought it was (yet another) super-secret trick known only to the cognoscenti.)

cmari

[Eric Shulman]

On Monday, January 11, 2016 at 9:02:09 AM UTC-8, cmari wrote:

@Eric, thanks, this worked perfectly. I had tried suffix, but didn't think about also using prefix. (Oddly, <<listitem>> actually worked as you originally posted it, without changing to <<currentTiddler>>. This was discouraging because I couldn't figure out where it came from and thought it was (yet another) super-secret trick known only to the cognoscenti.)

The reason it worked the first time is that <<listItem>> was undefined.  Thus, tiddler=<<listItem>> didn't actually set the parameter, and it defaulted to using the value of <<currentTiddler>> anyway.  Even though this works, it's always better, of course, to have the proper variables referenced to avoid any confusion (or give the appearance of super-secret tricks!)

-e

[Tobias Beer]

Hi Mat,

 

Why is this a problem?

Because it will suggest you actually made edits to it, and you really didn't. You simply wanted to use the ui, rather than change something about the tiddler.

 

Whichever tiddler that stores it will be modified, no? (...or are perhaps tiddlers prefixed $:/state/ treated differently in this? I can't find info in the docs.)

Yes, and that is what states are for: they store states. And yes, they are treated differently. For one, they are system tiddlers and secondly, my wiki is set up to never save any of that. I don't expect, in fact, I don't want my wiki to load "exactly as I left it". I don't expect that from other applications and I won't start expecting to see the popup I didn't close last time.

 

I'm thinking that if something can easily be made with html+css then this is preferred before widgets beause the former is more browser native, no?

There is no intrinsic benefit to "browser native". TiddlyWiki builds on a browser's framework, yes.. well actually, it implements the same stuff a browser does: so both speak the same language. Other than that, we do have "native TiddlyWiki". If we just needed "browser stuff", TiddlyWiki wouldn't be what it is. Yes, if you can do things just using classes and hover states, that's fine. But here we are talking about a persisted state, one that you expect to stay after you clicked... at least for a given life-time, e.g. the tiddler / window / etc being still open.

In TWC we did that doing dom manipulation ..in the later days with jQuery. These methods are, for the most part, a thing of the past. Most things are tiddlers now. But sure, we don't need to tiddlerify a hover-state or a mouse-position. At least that would simply be pointless for most cases. Perhaps it actually isn't. Not sure. Depends on what you wish to model.

The paradigm these days is: make it a tiddler (or part of one)... and as you can actually see in your example: you very much adhered to that paradigm. The one reason not to use and abuse the tiddler you look at is: its state got nothing to do with its content: those are two independent layers. Content (Model / standard tiddlers) <> UI (View / system tiddlers)... and in-between all those TiddlyWiki components being the Controller.

Best wishes,

Tobias.