[TW5] Suggestions for the $action-mangletags widget

[Matabele]

Hi

I proposed that my ActionMangleTags widget might be suitable for the core -- Jeremy suggested that I modify the code such that the widget could be used to add/remove strings from any field to be used as a list (rather than only the 'tags' and 'list' fields.) This was not difficult to achieve.

However, this option opened a can of worms -- it seems that one of the primary purposes of user lists involves controlling the order of the list. Removing a string presents no problem, but where in the list should a string be added? Should options be provided for prefixing and appending the string? Should options be provided for inserting before and after another string?

I came up with another idea -- to provide the facility to apply a filter after appending the new string to the list. This idea may be explored with my $x-mangletags widget available here (the mechanism works, but is a little clunky to use in its present form.)

Another possibility is to provide a facility to add/remove multiple tags. This idea may be explored with my $x-setrefs widget, also available here (the mechanism works well however, true search/replace is lost.)

Anyway -- I am lost as to which direction to develop the widget, and would welcome any ideas as to:

-- what do users need user lists for?

-- applying filters after adding the tag(s) seems to work, but are there sufficient filter options available for users? 

-- how can the lists be used? A simple equivalent of:

<$list filter="[tag[one]]"/>

-- may be obtained with:

<$list filter="[[one]listed[tags]]"/>

-- however, this doesn't work:

<$list filter="[[one]!listed[tags]]"/>

Appears that the existing set of filters need modifying and extending before user lists are truly useful. All suggestions are welcome :-)

regards 

[Jed Carty]

I was working on some stuff that would probably go best as an extension of the action-setfield widget, I have a working example wiki here.

It should still be extended so that it can remove the nth instance of an item in a list instead of just the first or last and there has been some debate about the best way to actually specify the action.

[Matabele]

Hi

I had a look at your contribution -- I think a special purpose widget for the manipulation of lists would be preferable to  extending the $action-setfield widget. There is clearly a need for multiple lists with functionality akin to that of the 'tags' field -- but how to best implement this is unclear to me.

There are many different possibilities for order in a list -- my proposal is to use filter expressions to order the list, rather than using complex attributes in the widget to control the point of insertion (how could this work when adding multiple strings?) As an experiment, I appended some of the code from my $x-setrefs widget to the $x-mangletags widget -- this allows the list to be operated upon by a filter expression, after manipulation of the strings. The idea works quite well for simple ascending/descending order -- but:

-- how many other possibilities for order are desirable?

-- can the existing filters be modified/extended to achieve this?

-- are multiple instances of the same string necessary in a list (currently only one is permitted)?

-- if so -- what for?

-- would users prefer the widget to allow for the addition/removal of multiple tags (like my $x-setrefs widget)?

I became bogged down with possibilities and needed some feedback.

regards

[Tobias Beer]

Hi Metabele / Jed,

 

I had a look at your contribution -- I think a special purpose widget for the manipulation of lists would be preferable to  extending the $action-setfield widget. There is clearly a need for multiple lists with functionality akin to that of the 'tags' field -- but how to best implement this is unclear to me.

As you have seen, I'm all for extending the action-setwidget as the codebase is basically the same and then some... so big chunks will need duplication. Except, I have not studied yet as to how one widget can use another as a base class... then that might be an option, albeit all the more complex.

There are many different possibilities for order in a list -- my proposal is to use filter expressions to order the list

That sounds like an interesting idea, especially for persist-sorting.

-- how many other possibilities for order are desirable?

Whatever core filters are available.

 

-- can the existing filters be modified/extended to achieve this?

What needs extending? Afaics, you simply work the filter on your list items and that's it.

-- are multiple instances of the same string necessary in a list (currently only one is permitted)?

I would perhaps not start with that for now.

Maybe later if someone truly needs a basket: coffee coffee coffee field.

-- if so -- what for?

It could be a sequence of sorts, e.g. some log of what happened or some instructions of what to do, like moves, e.g. UP UP RIGHT UP LEFT UP.

-- would users prefer the widget to allow for the addition/removal of multiple tags (like my $x-setrefs widget)?

With a simple syntax to do that, sure.

Perhaps it can be designed to begin with having more of a VarsWidget than a SetWidget approach in mind.

For example, if it had a $remove attribute this could, by default be interpreted as a bracketedList, so you can tell it to remove a number of items, same with $add. Actually, perhaps it could even be filter strings as well, e.g: $remove="[prefix[#]]". I think that's the most flexible... and clean, e.g. "remove any status tags".

I became bogged down with possibilities and needed some feedback.

:-)

Best wishes,

— tb 

[Jed Carty]

-- are multiple instances of the same string necessary in a list (currently only one is permitted)?

I would perhaps not start with that for now.

Maybe later if someone truly needs a basket: coffee coffee coffee field.

I disagree with this. I think it is very important to support arbitrary ordered lists. One of the bigger problems I had making my demo was that the parseStringArray function in the core removed duplicates from the list. Since the idea is to move toward using polymorphic fields I think that the basic operations need to be as flexible as possible. Trying to code for more restrictive operations and then relaxing those restrictions is going to be harder than going the other way.

A simple example of where this would be useful would be for tracking items sold where if arbitrary lists are supported you would just need to click a button that adds the item name to the list. You could then use the count widget to get display how many of each item was sold.
If this gets added to the core than doing something like that would require almost no knowledge and nothing outside of the core tiddlywiki to create. I think that is important.

[Matabele]

Hi Tobias

I have included one possibility for a syntax to add/remove multiple strings/tags in my $x-setrefs widget. Any uniquely named attribute with the prefix '++' adds a string, and any uniquely named attribute with the prefix '--' removes a string. 

For example, to add a few tags (the default list) to the currentTiddler (the default), and remove one also -- use syntax like this:

<$x-setrefs ++1="first tag" ++2="second tag" ++3="third tag" --1="remove this tag"/>

Seems to be a convenient schema for most situations (these are unconditional - not true search/replace.) I like this schema as it is reminiscent of the '!!' for fields and the '##' for data entires. Multiple fields/data entries can be set in the same widget, like this:

<$x-setrefs !!field1="some value" !!field2="another value" another-tiddler##="add this data index" ++1="a tag to add" --1="a tag to remove"/>

This may be tried out here. What do you think?

I like the idea of: $remove="[filter[expression]]" -- perhaps this option should be offered alongside the schema above? This could not be used for  true search/replace though -- unless all removed tags were replaced with the same tag. Perhaps a $removeall="[filter[expression]]" would be appropriate, as there seems no use for the equivalent $addall="[filter[expression]]".

As to sorting -- I think one additional filter option may be called for: sort this list in the order of another list. For example: sort this list of days in the order of days-of-the-week (unless this is already possible?)

regards

[Matabele]

Hi Jed

It might be the case that two special purpose action widgets are called for -- one to manipulate arbitrary ordered lists, and another to manipulate tag-like lists. It appears these functions are used for for very different things. What must be born in mind in what the list is used for once created - for example, for tag-like lists, the most useful facility is to search for an instance of a tag -- multiple tags are redundant -- and the order is often irrelevant.

I have used standard methods for manipulating lists from the core -- arbitrary ordered lists will require custom coding or modifications to the core. That seems to justify a whole new widget (or set of widgets) for manipulating and using such lists. 

regards

[Jed Carty]

The demo I made can handle arbitrary lists and handle cases where only unique entries are desired. The only problem I had with it was I needed to make a copy of the parseStringArray in the widget that didn't automatically remove duplicates.

[Matabele]

Hi Jed

What do you make of the idea of applying filters to the list after manipulation, rather than having to specify the point of insertion of a string? (this allows for the addition of multiple strings in one step.)

I can see that for some purposes, the list must remain in the order it was created (as in the example of a set of moves "LEFT FORWARD2 RIGHT ..." -- but in such cases there would be no need to sort the list, and the whole list can, in any case, be edited in an edit-text widget.

You appear to be targeting a usage case such as for keeping a set of accounts, or a cashbook, or some such. In this case, each record requires a date, and various other information -- surely this is a case for using one tiddler/transaction (and sorting on date)?

I still fail to see what arbitrary ordered lists may be useful for. I can see that many lists need to retain an order, but there are limits to the number of orders required -- hence my suggestion: sort this list (these days) in the order of another list (days-of-the-week.) A single data table containing these specific orders would suffice for sorting any list.

regards

[Matabele]

Hi Tobias

There seems to be a problem when using the existing filter set for user lists.

An equivalent filter for "[tag[mytag]]" is straightforward: "[[mytag]listed[mylist]]". But the negated equivalent of "[!tag[mytag]]" is difficult to replicate:

 "[[mytag]!listed[mylist]]" seems like it should work, but doesn't.

I haven't tried to replicate more complex filters, as even simple cases appear to fail. Perhaps you have a general method for developing such filters with the existing filter set?

regards

On Monday, 12 October 2015 08:32:06 UTC+2, Tobias Beer wrote:

[Jed Carty]

I believe we may be talking about different things. I was not thinking about sorting at all. I think it is safe to assume that sorting would be done independently of other list manipulations. If someone needed to sort a list then add to a specific point than using two action widgets wouldn't be an unreasonable way to do it.

Ordering a list that wasn't sorted by something like the title would require something complex enough that it would have to be taken care of using logic outside the widget anyway so I think aside from being able to add/remove/insert at a specific point in the list we don't need to worry about it.

[Matabele]

Hi Jed

What are the usage scenarios for inserting a string at a particular places in a list (beginning:end:before:after)? I haven't needed this and am trying to understand the requirements.

regards

[Tobias Beer]

Hi Metabele,

 

What do you make of the idea of applying filters to the list after manipulation, rather than having to specify the point of insertion of a string?

With my suggestion for using core sort filters I implied to only use those as a form of subfilter while feeding it, oviously, the current list as its input.

So there is no negation (of an input set). There only is sort in reverse.

I still fail to see what arbitrary ordered lists may be useful for.

A list (as a collection of items that can be identical) or a set (as a collection of distinct items) ...both have their use cases.

One might want to sort either, and do all the basic operations to manage them,

e.g. insert (, append, prepend), remove, update, and, well, read, too... possibly even multiple at a time.

I would not focus on anything special right now, e.g. a list of "dates".

Leave that to the user who wishes to use a list / set for whatever purpose.
If there's a sort filter missing for dates then that's a different issue.
If we need a sort filter to compare an input list against a predefined list, then that's a different issue.

Trying to code for more restrictive operations and then relaxing those restrictions is going to be harder than going the other way.

Not sure that's true. A well defined set of basic constraints appears to be extensible

while trying to constrain an open playing field later is nearly impossible.

In TiddlyWiki, I think any list field is most often a set (of titles), so that should be default.

Yes, we are well advised to cater for lists (that allow duplicates) ...as an exception to that default.

I would very much hope to see the whole feature set in one widget, not multiple ones.
One widget that provides all the essential set/list operations that are useful.

Best wishes,

— tb

[Tobias Beer]

Hi Metabele,

 

What are the usage scenarios for inserting a string at a particular places in a list (beginning:end:before:after)? I haven't needed this and am trying to understand the requirements.

Dnd would be one.

Best wishes,

— tb

[Matabele]

Hi

Should d&d of a list not have it's own widget (an action widget doesn't seem appropriate)? Some nice syntax might go something like this:

<$drag&drop list="Target!!mylist">
<$link draggable="true"/>
</$drag&drop>

regards

[Tobias Beer]

Hi Metabele,

 

Should d&d of a list not have it's own widget (an action widget doesn't seem appropriate)?

Own widget or not, it would / should still rely upon the same basic list-field operations.

As I see it, the core should provide the codebase for the list-operations that widgets implement.

Best wishes,

— tb 

[Jed Carty]

I think that any d&d functions would work by a two step process, first getting the list item under the cursor at the click event and then the item under the cursor at the release event and then passing that information to an action widget that actually does the reordering. That way as long as the action widget can handle inserting into a list between two items and removing from a list index the two parts could be developed independently.

[Matabele]

Hi Fed

That clarifies things -- the requirement is for:

-- remove this string from here

-- and insert this string after that string over there

I think only 'after' is required -- generally the link will be dropped on top of another link, and the expectation is that the link will insert below where it is dropped.

regards

[Tobias Beer]

Hi Metabele,

 

That clarifies things -- the requirement is for:

-- remove this string from here

-- and insert this string after that string over there

I think it's not strings we're talking about but list-items in an array.

Best wishes,

— tb

[PMario]

On Thursday, October 15, 2015 at 12:03:59 PM UTC+2, Jed Carty wrote:

I think that any d&d functions would work by a two step process, first getting the list item under the cursor at the click event and then the item under the cursor at the release event and then passing that information to an action widget that actually does the reordering. That way as long as the action widget can handle inserting into a list between two items and removing from a list index the two parts could be developed independently.

I think, you are right for the process but you are missing the visual user feedback. As a user I want a preview of my list, how it would look like, if I would release the button at any given moment. .. And imo that's a problem with TW atm.

-m

[Matabele]

Hi

Something like the tag pills at the top of a tiddler in view mode? or something more?

regards

[Jed Carty]

Mario,

I think that even if you got in-progress feedback to show the item under the current mouse  would be mousedown-move cursor-edit list position-move more-edit list to put item at new position-mouseup-edit list the final time, so that wouldn't be a fundamental difference that would be addressed by the list editing side of things.
There may be a better way to do things, but this at least avoids part of the problem caused by dom refreshes mid move. You would get visual feedback and all feedback would reflect actual changes to the tiddler store. There may still be some strange behavior if the dom refreshes at an incovnenient time, but it would be a start.

[Matabele]

Hi

Perhaps a better approach:

-- mousedown (edit list to move item to end of list) 

-- move mouse to wherever (no change to list)

-- mouseup (edit list to move item from end of list to after mouseup position)

This avoids multiple (redundant) edits of the list.

regards

[Jed Carty]

That removes any visual feedback about what is currently happening. If the visual feedback is all done in the dom than if the dom refreshes mid-operation there will probably be weird behavior. Without visual feedback than all we would need is a way to pick out the list item under the cursor at mousedown and the item under the cursor at mouseup.
I like visual feedback, but it may not be practical if it slows things down too much.