I do use list-links-draggable with other fields and would like to use it more in some work I am doing. A feature I would to use more is the itemTemplate especially to place some buttons (acting on current tiddler) next to each item. One in particular, a small x to remove the item from the list. Others may be a click to edit item if it is a tiddler.
The tiddler containing the list field, should default to currentTiddler (not sure it does) It is in 5.4.0
Thank you for letting me know. Could you please explain why you donât use the ListField in your use case?
I recommend using the ListField because it has special features. For example, its contents are treated as a TitleList , which allows you to reorder titles directly in the tag pill and automatically updates the parent tiddlerâs ListField. The ActionListopsWidget works by default on ListField, âŚ
I want to use list draggable also for a another title âlist fieldâ, but not that of the âlistâ field and I leave it alone in case the current tiddler is to be used as a tag and reordered from the tag pill.
One example is my no touch method of âflagsâ where I may wish to reorder the list of titles in the flag-list field.
however I can also imagine wishing to reorder a series of strings in a list field as well. Sure I can build a draggable list from the primitives but is is a bit fussy.
This plugin also introduces a list-filter-draggable macro, which IMHO is more flexible than (and could perhaps even replace) the list-links-draggable and list-tagged-draggable macros provided in the $:/core/macros/list system tiddler.
Filters provide the users quite a bit of flexibility in the source of the list items.
I do, quite often, for the same reasons @TW_Tones stated above.
Great news! There have been many requests here on Talk about ways to change displayed information in lists or other contexts, so I think adding this option to a core macro as important as list-links-draggable is good -the code could then be found and reused by TW users!
I do! Feature request, if not already included: make it possible for an item to change its parent tiddler when drag-n-dropping.
Another feature request: make list-links-draggable more mobile-friendly. For example, by providing an example item-template with a âdrag-n-drop handleâ, and an API for swipe-left or swipe-right events actions (user-defined macro/procedure, similar to <$button> widget actions parameter).
Thanks for your work on this topic, modernizing core macros will greatly improve TWâs hackability!
I love working with filters rather than âdumbâ lists whenever possible, so Iâm intrigued⌠but also confused. I donât have time to check out the demo, but perhaps you can answer here:
In the case of a list field, itâs super-easy to understand where the reordering information occurs â the list string itself is reordered. In the case of a filter, how does this work?
The set of items returned by the filter is dynamic (and the filter itself may have an order, and usually would â if I care about ordering the items!).
What does it mean to reorder these? Where is the reordering info stored, and how does the solution cope with the fact that the set of filtered items may change radically at any time?
In some ways, this problem overlaps with the tag-order questions weâve discussed elsewhere (since the tag tiddler has the list field, but doesnât control which tiddlers âclaimâ the tag). For tagpills, my own preferred solution would include an option where the dragging (perhaps with a modifier key or a directional drag-margin) adds a âlist-beforeâ or âlist-afterâ field â a blank one if pulled to the extreme â to the item, rather than to any list. In effect, if I want something first in a tag, I usually want it first (or first-ish*) no matter what else is added to the set, likewise if I want it last.
Iâm having a hard time imagining a filter-based ordering where the order I can about is absolute, but not in an way that I can articulate in the filter itself (as with a Days of the Week sortsub). (Even in a filtered list, ad-hoc ordering would often be based on relative criteria: This has to be before that, or this has to be toward beginning / toward end. Of course this-after-that is especially awkward for a dynamic list. If the âthatâ disappears, what to do with the âthisâ? But in practice, for something like a to-do list, maybe the problem is smaller, because realistically itâs fine if âregister_carâ has list-after field with âadd_car_to_insurance_policyâ, and âadd_car_to_insurance_policyâ disappears from list.)
Of course, with system tiddlers that have system-role tags, adding a list-before or list-after field generally has a really clear central purpose vis-a-vis that tag (ordering in view templates or cascade conditions).
In an all-purpose list-filter-draggable macro, we would face bigger risks of wanting child-level ordering fields to work one way for one filter, another way for a different filterâŚ
Any thoughts? (Sorry if the demo makes it clear; I only found field-based lists in the demo, though it makes mention of filter-based ones.)
perhaps only a partial answer and the points you bring up are all very valid.
This is how it is used in the code. As I understand just looking at it here, it is still backed by a tiddler and field for storage.
(in $:/plugins/phiv/field-based-checklist/main-procedure)
<$set name="filterString" filter="[<sortOrder>!match[userDefined]]" value="[subfilter<topList>] [subfilter<bottomList>] -[subfilter<hideChecked>] -[subfilter<hideUnchecked>]" emptyValue="[<storeTiddler>get<fieldName>enlist-input:raw[]] -[subfilter<hideChecked>] -[subfilter<hideUnchecked>]">
<$macrocall $name="list-filter-draggable" class={{{ [[tw-list-]addsuffix<listType>] }}} tiddler=<<storeTiddler>> field=<<fieldName>> filter=<<filterString>> itemTemplate="$:/plugins/phiv/field-based-checklist/list-item-template" emptyMessage="there are no items in the list" linkifyList=<<linkifyList>> />
</$set>
I was wondering about this as well, how does a filter relate to a dragable list?
I am not sure we need to modify list-links and dragable for this but using a filter may include;
initial population of the list
updating the list with new members in the filter but not yet in the list field
There is an argument that such a filter should not impact the order of a manually adjusted list, but perhaps it could prepend, append or insert new members.
However it needs to be noted that to alter a tiddler or its fields requires a trigger/action. dragging an item is a trigger, but simply listing is not. So this starts to get more complex quickly.
Exceptions may be when using a second list to be used to sortby another list, the sortby remains as is until a single item is moved.
in some ways this is already happening with tags as the list field is in effect a sortby field not the definitive list of tags.
more research on the existing tags methods may throw light on it.
With a filter given what if list links and dragable highlighted the titles not yet in the list field, accepting a drag or simple click to cement them into the list?
should this honour list-before/after?
A hunch I have is could a macro test if the result of a filter contains the same members as the named list field if not append the new members to the list field. this would need a trigger and refresh control.
If it interests you, Iâve created a PR that should in my opinion make drag-and-drop more natural:
The preview page is here:
On the preview page the new drag-and-drop behavior is implemented in the Sidebarâs âOpenâ tab and in the Story River itself where you need to activate dragging of tiddlers by using the Keyboard Shortcut alt-D
I think that depends on the sort of parameter value youâre expecting. My intuition is thatâŚ
displayField communicates that the parameter should be a field name and only a field name.
displayContent implies a wide range of potential parameters, including macros and strings of wikitext. I think this would overlap significantly with itemTemplate â perhaps with the distinction that a displayContent parameter could be provided as inline code, e.g. displayContent:"This tiddler's caption field value is {{!!caption}}", whereas itemTemplate only accepts the title of a tiddler to be used as a template.
To be honest, Iâm not sure how well this (potential) usage aligns with the general TW philosophy of tiddlers. At the same time, I often want an ad hoc list template and donât want to create a separate template tiddler, and the fact that I canât do this with core macros like <<list-links-draggable>> means that I rarely use themâŚ
Iâd avoid altTitle; I think itâs not very semantic, since its contents would be replacing the link display text and wouldnât have any actual bearing on the tiddlerâs title.
To be honest, itemTemplate works wellâeven for the purpose we have in mind with this new input parameter. For example, consider the following itemTemplate tiddler:
What do you think about sticking with itemTemplate ? I know itâs a bit of an overkill in this case, but it would save us from adding an extra input parameter.
If youâre modernizing it anyway, I really think it should have displayField (or equivalent) just for parity with <<list-links>>.
Itâs unfortunate that the two macros use field differently; I wish <<list-links-draggable>> had originally been written to use field for the display field, as <<list-links>> does, and used listField or something similar to hold the list. Of course we canât change that now without breaking backwards compatibility⌠but I do think adding displayField would make <<list-links-draggable>> substantially more useful. It feels very inefficient to have to make a new template just to display a different field, and Iâm sure itâs even more challenging for less TW-savvy users â who are, I suspect, the people most likely to be making use of core macros like this one in the first place.
