Edit multiple values in a field

[clsturgeon]

I have a field named “aka”, where users can enter mutliple string values, such as:

[[John Smith]] Tony [[Stands Firm]]

This is like a list field, but does not actually reference existing tiddlers… the content, in this example, is simply three strings.

Instead of the user having to enter the value in the exact format shown above, I want to provide a single-line text box (for each string) where the user can edit each entry/string. Each text box requires a “remove” button to delete the specific entry/string. In addition, there should be an “add” button to add a new empty text box for the user to add a new value.

Does this make sense? How would I go about it?

I suspect I need to start with this to get the existing values, but now what?

<$list filter="[enlist{!!aka}]">

</$list>

Can I use the edit text box widget somehow? Thanks indvance.

[clsturgeon]

I think I’m close. Still need suggestions. I need to clean up the look (and code), but this presents it. The remove and add buttons work, but I want the text box to auto-update the aka field without an update button.

<$list filter="[enlist{!!aka}]" counter=counter variable=entry>
<div style="width:100%"><label>AKA (<<counter>>)</label> <input type="text" value=<<entry>> />
<$button tooltip="remove aka" style="font-size: 10px"><$action-listops $field="aka" $subfilter="-[<entry>]" $tiddler=<<currentTiddler>> />Remove</$button></div></$list>
<br/><br/>
<$button tooltip="new" style="font-size: 10px"><$action-listops $field="aka" $subfilter="[[new aka]]" $tiddler=<<currentTiddler>> />new aka</$button>

[TW_Tones]

There are a few way to do this, one is to make use of the fairly new listField parameter on the check box to list and remove/uncheck items. Typically you can use a temporary edit field tiddler and provide an add button that would trigger a listops action to add the title to the list field. You could use format:titleist[] to ensure titles with spaces.

• You may use multiple temp fields then on a click use the set multiple fields widget.

[Springer]

@clsturgeon

I want the text box to auto-update the aka field without an update button.

If I understand correctly, you want each keystroke to update the list field, without waiting for an enter button to perform the action of changing the list field.

I think @CodaCoder’s example in the recent thread about inputActions within the edit-text widget would give you the path you need:

Documentation tiddlers on TiddlyWiki.com in need of work (please contribute to the list)

@Springer \define onInput() <%if [get[temp]match[springer]] %> <$action-confirm $message="hello springer!"/> <% else %> <$action-confirm $message=<<actionValue>>/> <% endif %> \end <$edit-text inputActions=<<onInput>> field=temp/> Drop that into a new tiddler at tw .com.

[clsturgeon]

@TW_Tones

Typically you can use a temporary edit field tiddler and provide an add button that would trigger a listops action to add the title to the list field

@Springer

I think @CodaCoder’s example in the recent thread about inputActions within the edit-text widget would give you the path you need:

Thank you for replying. You are confirming the approach I suspected I needed to take, but I’m struggling with the implementation. The requirement is to display a text box for each item in the list field, populating each text box with each entry. As the user modifies a text box the list field is automatically updated.

I can get the text boxes populated, but when a given text box has changed the action has to update the single entry in the list field to change. How could this be done?

[TW_Tones]

Making the choice to allow seperate edits for each value in that list is introducing the complexity here. You can build this according to your requirements however choosing a slightly different interface would make it much simpler. For example;

• Allow the user to edit the list field directly
• Do the above with the full editor and editor toolbar buttons.
• Many more

[CodaCoder]

@clsturgeon

The requirement is to display a text box for each item in the list field, populating each text box with each entry. As the user modifies a text box the list field is automatically updated.

I’ve done this:

… display a button for each item in a global list field. If the item has already been chosen (is present in the chosen-list), display the button as grey. If the item has not yet been chosen (is not present in the chosen-list), display the button as blue.

When user clicks a blue button “X”, add the item “X” to the chosen-list. When TW rebuilds the UI, button “X” becomes gray.
When user clicks a grey button “Y”, remove the item “Y” from the chosen-list. When TW rebuilds the UI, button “Y” turns blue.

In essence, the buttons are acting as radio buttons.

Not exactly the same as your requirement, but pretty close.

Implementation note:
All buttons are actual HTML buttons: <button.... A delegate handles clicks via $eventcatcher. You might want to do the same for your input elements, which, if you have a ton of them, might prove more efficient.

---

If you’re interested, I’ll try to dig out the base code from the surrounding noise – let me know.

[Springer]

@clsturgeon

I can get the text boxes populated, but when a given text box has changed the action has to update the single entry in the list field to change. How could this be done?

I thought about sitting down to code this out, but I realized that the sequence of edit-text widgets might do odd things if a user deleted all text for value #1 as a first step to typing the replacement value, because suddenly value #2 would become value #1, etc… It’s all solvable, but… I then realized I have questions and/or worries about whether this basic design is something I’d recommend or reuse in my own projects (which is one consideration when I think about sitting down to puzzle out the nuts and bolts of a solution).

My worry is this: usually when there’s a list field with natural-language values (especially ones that need to be tracked with double-brackets), it’s because there are connections to be tracked.

I know you said:

@clsturgeon

[My] field named “aka”… is like a list field, but does not actually reference existing tiddlers…

In your case, since the field is called “aka” it probably doesn’t make sense to have a dropdown to select existing values (as drawn from other tiddlers with same field). If anything, you would want to have an easy way to alert folks if two tiddlers do overlap in the values appearing in their aka field, yes?

At any rate, whatever values appear in the aka field, surely these might interact with values in some other field for other tiddlers — if not now, then down the line? (For that is the point of an aka field, to connect things, yes?)

I’m imagining you might have, say, tiddlers for people, and also tiddlers for documents… Suppose you have a birth certificate document for Edda van Heemstra Hepburn-Ruston (any relation to her father Joseph Ruston, @jeremyruston?) and also a signed autograph by Audrey Hepburn, you want to be able to have both of those documents “show up” as connected to Audrey Hepburn (or whatever the home tiddler for her is called), so this is a good reason to have an aka field in Audrey Hepburn’s main tiddler…

(Side note: Even if if there’s no tiddler at the node for Edda van Heemstra Hepburn-Ruston, that string in the story river might yield an empty-node view template that points out that this name is an aka for Audrey Hepburn, and is the document name-of-record for a certain birth certificate document, etc. Such an empty-node view template would also be the ideal place to help people disambiguate between the three people with the aka value “Jack” (etc.))

Suppose someone suddenly realizes there’s a typo, and they had overlooked the double-e, and had typed the aka field entry for Audrey Hepburn as Edda van Hemstra Hepburn-Ruston by mistake (and at that earlier time, say, they had copied that same mistaken string into the birth certificate record). Wouldn’t you want the kind of granularity in your solution that would prompt user to decide — when they go to fix the aka field — whether the related field value in the birth certificate tiddler should also be changed? A mere edit-text widget is not going to help highlight those connections and relink as needed.

Suppose someone is entering in a new document tiddler. Do you want them to be always typing a name from scratch, or should they be invited to enter existing values, so that they’re at less risk of a typo in locking into the Edda van Heemstra Hepburn-Ruston connection correctly, if that’s what they’re trying to do? Making tiddlers for those aka values, even if they’re somehow hidden (and certainly displayed differently from the “home” tiddlers for their humans), might help them be more useful and open to troubleshooting. (Field values can also be used to populate drop-downs, of course. But tiddlers can help, if there’s ever more to say about the origin or importance of an aka relation.)

I’ll stop here. I realize you may actually have great reasons for wanting a “simple” solution that treats the aka list field’s values as simple strings, disconnected from the rest of the wiki. But I’m curious about your response to all of the above.

[clsturgeon]

@Springer

If anything, you would want to have an easy way to alert folks if two tiddlers do overlap in the values appearing in their aka field, yes?

No. I don’t think so. In think you have understood my use of aka. But, i have no relationship between aka field values with any other person.

@Springer

Suppose someone is entering in a new document tiddler. Do you want them to be always typing a name from scratch, or should they be invited to enter existing values, so that they’re at less risk of a typo

If I understood this correctly, my project does not work this way. I do not expect a user to type in name in this way. Rather, for the document Tiddler to be associated at any person the user is presented with a search box that filters and provides a list of people tiddlers based on a search. The search looks in multiple fields (title, caption, aka) to find the person tiddler. When the user selects the one they want the associated person is assigned to the document.

The aka field for person (I also have an aka field for a place) are simply alternate names or alternative spellings.

This field was implemented this way from day one, when I was less experienced with TW. No excuse, but true. I have other things that I implemented very differently. Eg. You can assign 1 or more occupations to a person. But you can only select/enter an occupation you have already defined (a tiddler tagged as occupation). Again, user does not need to type in the name and guess the title of the occupation. They select it from a list of previously defined occupations.

I felt no need to define a dedicated tiddler for each aka. Actually, I don’t think there should be.

Perhaps there should be some sort of “sidecar” tiddler that houses aka fields for a person. Any person with 1 or more aka strings gets a sidecar. In this way I get around the need for square brackets. Or, should I use data tiddlers.

So, is my current implementation a poor choice?

What I have coded, so far, to do what I want is close, but fails on a few points. If the user changes 1 aka value, the aka field updates and therefore the entire set of text boxes refresh, and user loses control of their selected text box.

So, back to my question. Wrong implementation to house multiple (array of) text strings for a tiddler?

[TW_Tones]

I think it is reasonable to be able to use a “list field” to store multiple values. The question is how do you implement the standard edit/modification features against this list field?

• This can get a little more complex if the list field has a specific order.

However I would suggest

• to delete an item from the list use my aforementioned checkbox listField approach
• to add a new item a simple edit-text box in which you type then click “add to list” button.
  • One could provide multiple ways to select the value to add to list, in addition to the edit box, such as lookup title, select from existing list, select multiple…
• To edit an existing item you can take two approaches
  • Treat edit as a rename, store the items value, and provide a temp field/tiddler to edit it. Then have a rename button, which replaces the original with the current. search/replace operator?
  • When a user selects an edit button against an item, remove it from the list, and show the edit-text widget in a temporary field containing the removed “title”, when finishing editing the string add it back to the list (use format:titlelist[] but this may be unnecessary with the correct delimiters).
    • This could be designed to have the edit appear in place within the list, not permanently, just once an edit button is hit along side an item.
• You could save the whole listfield in a tempoary field, and provide a restore button if any of this above editing goes foul.

Using this approach one should be able to get smart, and have a single edit-text space that can be used to add a new item, edit an existing item (rename) and perhaps even delete (edit and clear, ie not save back to remove)

[Charlie_Veniot]

A prototype to edit/create/delete comma-separated values in the aka field for the tiddler “Charlie Veniot”.

Download to drag and drop into TiddlyWiki.com (or whatever TiddlyWiki instance) to play.

Note that, being simply for prototyping purposes, I have not put any effort in making this look pretty. It is all about being functional and identifying the necessary parts for an eventual generic design.

Also note: this is designed for TW 5.2.3 and up.

multi-value field editor prototype.json (1.6 KB)

[clsturgeon]

@Charlie_Veniot Thank you. This implementation missed a couple of requirements. I wanted it to work without an Edit or Apply buttons. However, I have not been able to sort out a solution. The comma delimited string does not work for me as a comma is a valid character in my aka. Having said that, you still provided an appropriate solution. By converting this:

<$list variable="this_subfield_value" filter="[[Charlie Veniot]get[aka]split[,]sort[]]" counter=count>

…to…

<$list variable="this_subfield_value" filter="[[Charlie Veniot]get[aka]enlist-input[]]" counter=count>

I am able to enlist the list field instead of using a comma delimited string. To apply/save the changes, I changed this:

<$action-setfield $tiddler="Charlie Veniot" $field="aka" $value={{{ [regexp<temptidregex>get[text]sort[]join[,]] }}}/>

to…

<$action-setfield $tiddler="Charlie Veniot" $field="aka" $value={{{ [regexp<temptidregex>get[text]sort[]format:titlelist[]] +[join[ ]] }}}/>

…to regenerate the title list in the aka field.

Again, thank you, I will be implementing this into my aka fields.

And, @TW_Tones Thank you for suggesting the `format:titlelist[]’ operator.

Craig

[Charlie_Veniot]

@clsturgeon

This implementation missed a couple of requirements. I wanted it to work without an Edit or Apply buttons

Well, since I personally wouldn’t recommend doing that, I tossed that requirement right to file 13. Somebody else who is on board can help you out with that.

@clsturgeon

The comma delimited string does not work for me as a comma is a valid character

Um, this is a prototype. It isn’t meant to be a prescriptive approach/solution. Use whatever separator you like. I’m particularly fond of “::”

I am never a fan of using brackets and enlist when the items are not meant to be tiddlers.

It is hard to figure out what somebody is looking for without a throw-away prototype.

This was really for me a fun exercise, a small part of something I would put into a proper data-entry form for users, with the edit and “apply Changes” applicable to all of the fields on the form.

[clsturgeon]

I understand that. Much appreciated.

[TW_Tones]

@Charlie_Veniot

I am never a fan of using brackets and enlist when the items are not meant to be tiddlers.

• Each to their own of course, but the idea that filters act on titles, whether or not they are existing tiddlers eg they are actually strings, is somewhat embedded into the tiddlywiki syntax. Then when one is building or manipulating a list, we could call each entry title or a string, without that actually being a tiddler. Curiously, this inter-changability between string <> title <> tiddler title is in many ways a feature.

[Charlie_Veniot]

@TW_Tones

Each to their own of course, but the idea that filters act on titles, whether or not they are existing tiddlers eg they are actually strings, is somewhat embedded into the tiddlywiki syntax. Then when one is building or manipulating a list, we could call each entry title or a string, without that actually being a tiddler. Curiously, this inter-changability between string <> title <> tiddler title is in many ways a feature.

Since you’ve quoted me, it kind of feels like you’re addressing me, so I guess I should explain myself…

That I know like the back of my hand, and it has nothing to do with my problem regarding the use of brackets in a field for things that are not meant to be tiddler titles.

When inspecting a tiddler’s fields (or looking at a JSON export of a tiddler), if I see things inside double-square brackets, I immediately think that the field is all about reference links to tiddlers.

I rely heavily on visual cues to help me parse/decipher what I’m looking at, and the square brackets (which means to me “a tiddler title”) would throw me off.

I can’t handle those types of annoyances that distract me and have me misinterpreting what I’m looking at.

Hence a simple comma-separated (or whatever-separated, double-colon separator being my preference) list. That makes the purpose of the field much more clear to me: “ah, it is just a comma-separated list of plain text.”

[TW_Tones]

That is why I said “to each their own”, these are what we may call personal syntax standards and we a free to use what we want in our own code.

• However when sharing we can do the same but it may be worth noting, for example the tags field can be tested with <$text text={{!!tags}}/> then add tags to see that the result is a b [[c d]], keeping in mind tags need not have tiddlers.
• Although if you use , you may find you need the equivalent of enlist say split[,]

Like you if valid I like comma delimited lists.

[Charlie_Veniot]

Two things:

• to each their own
• quoting people

@TW_Tones

Each to their own of course, but

Well, where I come from, “each to their own” is usually sarcasm, especially when followed by a “but”. (Sarcasm as in “ridicule or mockery used harshly, often crudely and contemptuously” to disagree, to discredit, etc.)

"To each their own" is right up there with “I love you, but” and (Boondock Saints II All Saints Day reference): “With all due respect” said just before outright laying out some disrespect.

I’m not saying that was your intent. (I don’t have the energy for guessing that, nor do I have enough hours in a day for that kind of game.) I’m saying that is how it felt, hence the reaction.

@Charlie_Veniot

I am never a fan of using brackets and enlist when the items are not meant to be tiddlers.

To use me and my quote for elaborating on some educational wisdom without the whole breadth and depth of context/reasoning behind that quote winds up shining a sort of discrediting light on me a bit, which winds up having me needing to follow-up with extra context.

Now, if you had quoted me and asked “Why?” followed up with examples that show why you are a fan of the thing I’m not a fan of, that would have been pretty super. I would have sensed that you are more interested in my “alternative” viewpoint than (my perception) simply just throwing shade on me and the reasoning behind my quote.

[Springer]

@clsturgeon

I can get the text boxes populated, but when a given text box has changed the action has to update the single entry in the list field to change.

I’m more and more flummoxed about how to get an edit-text widget to be fully “live” in its manipulation of the list field, while also displaying only the current value within the edit-text widget.

So I’m back to thinking about your “why” rather than your “what”…

Is your main concern about user-proofing the solution? In other words, you don’t want to require a button to confirm the change (new/edited value), because someone could type the change but forget to confirm it? (And then the list field would remain unchanged…?)

I wonder whether using a modal (a pop-up that needs confirmation), and having the modal present an edit-text widget using a temp field, could solve this problem? You could even have the value confirmed with an enter keystroke…

Of course, if that’s not your “why” then this idea wouldn’t help.

[clsturgeon]

@Springer

I’m more and more flummoxed about how to get an edit-text widget to be fully “live” in its manipulation of the list field, while also displaying only the current value within the edit-text widget.

So I’m back to thinking about your “why” rather than your “what”…

I guess the “why” mostly comes from me attempting to be consistent.

When viewing a tiddler in my genealogical research tool, for the most part, is a read-only experience. E.g. when viewing a place tiddler (driven by view template):

When editing a tiddler I show the typical TW edit controls, but then I show edit fields specific to the tiddler type (a place tiddler in this case). A place tiddler has a well-defined set of fields. So, I provide friendly controls to edit (see ‘Place fields’ group box in the screenshot below). In this way, the user does not need to know all the field names supported by that tiddler type. When the user enters characters into a textbox the field is automatically echoed into the tiddler field. I wanted to be consistent and do that for this aka field.

I have used the approach designed and implemented by @Charlie_Veniot (with a few changes) where the user sees the value as is in the text box but has to click an Edit button to edit each entry individually:

As you highlighted the user has to click Apply to persistent the additions and changes.

I elected to bind this edit session in another group box.

You mentioned a pop-up, which is a good idea based on the reasons you provided.

For standard list fields (those list fields that reference tiddlers) I use a popup, so I could do this.

Example pop-up: in this tiddler, I use a place field that defines the parent location of a place:

So the user does not need to know the field name or the tiddler title of the parent place, the user clicks on a “Select Places” button to pop-up a window to search and find the parent place.

Aside: If the parent place is not found the user can click on a “+” button to add it.

I should try your pop-up idea. Thank you for the comments. Did I answer your “why” question?

Craig