[BUG] Field Editor: Switching field name also clears the field value

[AnthonyMuscio]

Unlike previous versions of tiddlywiki, in tiddler edit mode, if you paste a value into a new field dialogue then enter/select the fieldname, the value field is cleared and you have to provide it again.

To Reproduce Steps to reproduce the behavior:

1. Go to TiddlyWiki.com
2. Click on + New tiddler
3. Scroll down to "add new field", enter a value in the "field value"
4. Now enter or select a "field name".
5. Notice how the content of "field value" is erased (as soon as you type or select a field from the dropdown)

Expected behavior The field value entered is retained until the user hits ''add'' or clears the content.

Screenshots Not illustrative, please follow above instructions.

TiddlyWiki Configuration

• Version v5.2.2

Desktop (please complete the following information):

• Windows 11
• Browser Chrome, Firefox and Edge
• Latest general releases

Smartphone (please complete the following information):

• expect same on all platforms

Additional context I would expect this error should be fixed in the next release, however I would appreciate a workaround in the meantime. A workaround may forestall the "rushing to another release". Perhaps tiddlywiki.com should have "errata" messages for such circumstances?

[pmario]

I can confirm, that this problem wasn't there in v5.2.1 .... It's probably part of the keyboard handling for dropdowns. We need to check, what changed

[pmario]

@AnthonyMuscio .. It would be nice, if you add a proper title to your issue

[pmario]

This is related to: Allow the rendering of fields within the Edit Template to be extended #6511 especially: https://github.com/Jermolene/TiddlyWiki5/pull/6511#issuecomment-1080693028

[Jermolene]

Thanks @AnthonyMuscio, well spotted, and a very clear bug report.

It does indeed appear to be related to #6511. @FlashSystems could you comment?

[pmario]

I think it's caused by the new-field-actions() ...

But I think the underlaying problem is, that the keyboard handling uses 2 different temp-values to manage the "value" field. .. This causes "syncing problems" everywhere it is used in the UI ...

So I think we need to fix the main problem, otherwise we will only start to "fight" the symptoms all over the places.

I needed to create a "hacky" workaround at: https://github.com/Jermolene/TiddlyWiki5/pull/6534/files ... which imo is caused by the same issue: 2 variables, that do 1 thing ... Problems will happen

[pmario]

As the keyboard dropdown handling was developed, the keyboard widget didn't allow a different approach. Now that we have more functions in the keyboard-widget and we have the eventcatcher widget, I think the "dropdown" handling should be rewritten.

[FlashSystems]

I had a quick look regarding this bug. I think the problem is, that creating a field works differently than updating one. When creating the field, the same field must be used for storage to allow the described use case. When editing, the data must be stored within different fields. While unifying the approaches to integrate the cascade, I missed this detail. You can verify this by selecting different field names and putting a value in each of them. The value will be saved "per field" and return if you select the last field value again.

I'll look into this bug this evening.

[AnthonyMuscio]

@AnthonyMuscio .. It would be nice, if you add a proper title to your issue

Sorry, I tried to fix it but can not see how.

[AnthonyMuscio]

Until now I have not explored using the Field Editor Cascade, nore being involved in any discussions about it.

I hope I can leave it to those involved.

The Field Editor Cascade is a useful addition and I look forward to exploring its use, Where should I mention the related idea of permitting, ideally through a cascade, a list of ordered fieldnames, whether they exist or not which the editor (and view template for that matter could use) to present the fields in the order specified. This would allow a "form" layout to be provided to the editor, for different functional tiddler types. So we could create a field-list for "contact tiddlers" with a name address etc..." placed in logical order.

I have in the past called this a field-list.

I mention this now because I can see with the select on fields etc... are related, especially If "a form" in the editor may list a set of fields found in a field-list that do not yet exist, but on providing a value will be created.

This will touch the same code needed to fix this BUG and those others referenced by @Jermolene

[pmario]

The Field Editor Cascade is a useful addition and I look forward to exploring its use, Where should I mention the related idea of permitting, ideally through a cascade, a list of ordered fieldnames, whether they exist or not which the editor (and view template for that matter could use) to present the fields in the order specified. This would allow a "form" layout to be provided to the editor, for different functional tiddler types. So we could create a field-list for "contact tiddlers" with a name address etc..." placed in logical order.

I think I did post a solution for this somewhere. ... May be at talk.tiddlywiki.com or at GG ... not sure. As Saq mentioned in the other PR comment. You should crate a new issue as a Feature Request

[FlashSystems]

Hello @Jermolene, @pmario, @AnthonyMuscio, this one is easy to fix but hard to get right: Historically, keeping the current value when switching fields was no problem because all field editors were able to show the text that is already there. Using the new Field Editor Cascade that's not the case any more. This makes keeping the value problematic. Consider the following events:

1. The user types "not-a-date" into the field value of a simple text field.
2. The user now selects a field name that uses a HTML5 date editor. The Editor will show no date because the value cannot be parsed.
3. The user saves the tiddler by clicking the checkmark.

Now the date-field contains the value "not-a-date" but the user was not aware that this will be added. The edit control showed no date (because the value was invalid) and the user assumed the field was empty and won't be added to the tiddler. The current implementation - by accident - prevents this, by saving the current value for each field individually. But this breaks @AnthonyMuscio's workflow.

I'd like your suggestions on how to handle this. There is no way to throw away invalid values when switching field names. Tiddlywiki overwrites the value of a field only if the input is changed. Maybe we should just hide the edit field as long as no field name is selected, but this will be an even more breaking change.

Restoring the old functionality is trivial, and I want to solve this problem as fast as possible, but I don't know if this would be a good solution :(

[AnthonyMuscio]

@FlashSystems I appreciate your work on this, but I was not involved in this until now.

In my own tiddlywiki world I have built mechanism's to handle fields, their content display and custom editors. You may see this demonstrated in my ideas presented here https://github.com/Jermolene/TiddlyWiki5/issues/6621#issue-1200071772

My gut feeling would be to suggest stepping back from the current approach and reevaluating. For example in my own work 'field handling" always results in a field definition being created, and each field points to a smaller set of field-types. Field types are what determines how the custom display and editing occurs.

Perhaps we should leave the current editor for non existent fields, and simply defined fields alone, and introduce an alternate path to handing fields with definitions and field types. My idea is to a new strategic solution to extending field handling.

As suggested in #6621 we could separate the edit process for fields that we identify as having particular field types, pickers editors and special display criteria. This is how the core already handles specific core fields anyway. Created and modified are hidden from the field editor and have additional handling encoded. Of course I propose extending this capability in a more sophisticated but minimalist way to addressing more advanced fields.

With this approach users can create fields no differently to now, however when they come to define a field and provide additional handling that field no longer uses the default field editor and we do not need to overload the the existing field editor. Perhaps as someone enters the editor, fields with advanced definitions, pickers and forematers are presented a different way such as via the custom field editors or found in my proposed field-list?

Where should we go now?, your call @FlashSystems @pmario @Jermolene

Post Script, Although nominating myself here I do believe I have some expertise in this area and I would love to collaborate in achieving this.

[AnthonyMuscio]

Just for a little clarity. This how I propose we proceed.

• Revert the current field editor to its previous behaviour.
• Provide a small set of field-type definitions eg: date, text and text area
• Provide a mechanism for users to define a field, and nominate a field-type for that field
• Add a mechanism to the editor to detect fields in the wiki, or the field-list mechanism, that have field definitions and pull in the field handling needed from the field-type (this is where the custom editor, pickers and display formatting is stored).
  • At this point we automatically hide the fields with definitions from the standard field editor, as current core fields do.
• This would all be with the added advantage that the field order can be provided to the editor to craft edit "forms", with the fields arranged appropriately using my proposed field-list mechanism.

Taking this approach would mean the existing behaviour remains in place and developing custom field definitions are freed from a need to sit on top of or within the existing field editor, which does a good job of allowing spontaniouse field creation.

• The separation into fields with and without field definitions will allow more sophisticated field definitions and field-types to be developed free from the constraints of the existing field editor.
• If you look at this as a general solution, with the complexity broken down into unmanaged fields, those with field definitions and a field-type assigned to each field definition you will discover actually the different possible field-types are actually quite small in number and we could pre-provision most common field-types for users.
  • of course being able to create new field-types is also important.
  • as is the value of being able to provide different formatting to display such field-types (when not editing)
• Not detailed here there are other features that this model can introduce for example
  • the field definition can include a filter that determines what values can be selected eg; a list of values, a filter that returns all existing values for that field, a most recently used values filter and much more.
  • The field-list can suggest all the fields a user may want to edit in a particular tiddler. An advanced form of tiddler templating that includes field handling.

Regards

[pmario]

@AnthonyMuscio ... I think almost everyting you describe here can be done with the open PR: Extend the EditTextWidget and fields to allow Date-Pickers and other tags #6377 that will allow us "bind" any kind editor to any kind of field value.

The demo is at: Extend the EditTextWidget and fields to allow Date-Pickers and other tags #6377

There are config-tiddlers like$:/config/EditTemplateFields/Templates/, which contain the "edit-template" for that field.

[AnthonyMuscio]

@pmario thanks for your response. I have always being confident of the ability to write the appropriate edit code for the different field-types as what is suggested here I will comment further in #6621

[FlashSystems]

I've created a fix for this bug in PR #6628. I've updated the Field Editor Cascade Demo to allow testing it. I hope I've covered all corner cases this time 😓 Without modifications to the cascade everything should work like in TW 5.2.1.

Thank you, @AnthonyMuscio, for giving me the idea of splitting the backing store by field editor to prevent the problem outlined in https://github.com/Jermolene/TiddlyWiki5/issues/6618#issuecomment-1095403853. I know, it's not as sophisticated as your idea, but I hope this feature can be used as a building block for your type-based approach.

Thank you for your patience. TiddlyWiki is a complex piece of software, and I am still learning new details every time I try to change something.

[AnthonyMuscio]

I am still learning new details every time

Aren't we all, thanks for your work too @FlashSystems every little bit counts

[AnthonyMuscio]

I note that this bug FIX has not yet being listed or applied in the current 5.2.3 prerelease and think it a bUg that should be fixed ASAP

[Jermolene]

I note that this bug FIX has not yet being listed or applied in the current 5.2.3 prerelease and think it a bUg that should be fixed ASAP

Thanks @AnthonyMuscio, #6628 has now been merged.

[AnthonyMuscio]

Thanks @AnthonyMuscio, #6628 has now been merged.

Thank you. I see it corrected on Prerelease 5.2.3