Tiddlywiki5: Clean-up List widget and add Story widget

[Jermolene]

We recently attempted to extend the list widget with an additional "iterator" variable that exposes the numeric index of an item. See #1328.

The problem with that approach was that the new iterator variables defeat the list widget logic for selective updating. (This is the mechanism whereby when a new item is inserted in a list, only the new item is rendered, and the existing list items are preserved.)

Another related problem is also emerging with the list widget. It supports an optional "storyview" that is used to animate changes to the list. These storyviews require that there be a DOM element wrapping each element of the list. In practice, the list widget deliberately doesn't insert any DOM elements in the render tree - if it, say, inserted included a parent DIV and a DIV for each item, then those DIVs would interfere with using the list widget to generate UL/LI lists. So the various storyviews have to do error checking to ensure that there is a wrapper div around each item. That's worked OK, but now we're creating storyviews that need to apply styles to the wrapper of the list.

It is proposed to resolve these issues by:

• Introduce a new "story" widget that is based on the current list widget with the following differences:
  
  
  
  • Adds an intrinsic DIV wrapper and a DIV for each item (thus providing the anchor points for storyviews to style the list and its items)
  
  
• Modify the current "list" widget to:
  
  
  
  • Remove support for storyviews
  
  
  • Remove support for selective updating
  
  
  • Restore the iterator variable functionality
  
  

The backwards compatibility implications of this change are pretty specific: it would break any existing code that uses the list widget to render a story list. I don't think that that is a big problem because the list widget is seldom used in that way except by the core.

[Jermolene]

Just to add that subsequently we could add drag and drop functionality to the new story widget. Adding drag and drop to the list widget as it stands would be rather messy because of the lack of intrinsic generated elements.

[tobibeer]

Interesting issue, sounds a sensible approach.

Just to add that subsequently we could add drag and drop functionality to the new story widget. Adding drag and drop to the list widget as it stands would be rather messy because of the lack of intrinsic generated elements.

I'm wondering if any future drag and drop does not imply (re)sorting the underyling story (list), meaning ordering and iterating capabilities.

[pmario]

At the google groups, there is a discussion about dynamically generated TW CSS "code". Imo a js macro will be needed to create CSS code like this. There are 2 dynamic elements. One is an iterator and the second one is a calculation. The number of elements will be defined with tags. ... I don't talk about the calculation, but the iterator variable would be really nice here.

img:nth-child(5){animation-delay:0s;}
img:nth-child(4){animation-delay:4s;}
img:nth-child(3){animation-delay:8s;}
img:nth-child(2){animation-delay:12s;}
img:nth-child(1){animation-delay:16s;}

also see: see: https://groups.google.com/d/msg/tiddlywiki/hMU53wfYysI/hAXrq2cZxfgJ

[EvanBalster]

Chiming in to say that the update performance issue could be solved by some improvements to how variables work in TiddlyWiki. I investigated these while experimenting with using my formula plugin for heavy computation.

Essentially it isn't necessary to refresh an entire widget simply because a variable has changed — only those elements in the widget tree that actually refer to the changed variable need to be refreshed.
Implementing this would require a substantial change to the refresh mechanism, requiring a hefty time investment, but would likely improve overall performance of TiddlyWiki.

[twMat]

@EvanBalster

isn't necessary to refresh an entire widget .. would likely improve overall performance of TiddlyWiki.

That sounds like a huge deal. If you share more insights and code, maybe the other big boys here can come with input for the benefit of everyone.

[AnthonyMuscio]

On Closing Provide an index value in lists #3384 and taking into account Minor but powerful improvement to the Range Operator #3425 can we please ensure we have a mechanism to specify leading zeros in the resultant Index numbers or at least extend the ViewWidget so we can pass it a variable and specify a format=number template="0000" or template="00.00" to specify leading zeros and trailing places?

Indexes and ranges are great but if we want them to generate serial numbers, dates tiddler names we need to be able to control the number of digits output etc..

Should I submit a separate issue for this viewWidget change?

[pmario]

Indexes and ranges are great but if we want them to generate serial numbers, dates tiddler names we need to be able to control the number of digits output etc..

Should I submit a separate issue for this viewWidget change?

... Just a thought!

Please be careful with hardcoding separators in formats like this one: 00.00

01.00 may be language specific! So some separators may change if you switch language. Some don't

[AnthonyMuscio]

Mario,

Good point, not addressing the decimal point would not be too much of a loss, however in this case it would be quite easy to pass through what ever delimiter the user provided 00.00 00,000 etc, the only thing that needs to happen is to honour the zero fill so what ever the delimiter be it supplied or the language setting it is not so important.

Regards
Tony