Text area Fields proof on concept and feedback requested

#1

Folks,

This package textarea-fields.json (640 Bytes) adds an additional Field editor cascade so any field ending in -textarea can be edited in the tiddler editor and retain new lines ie it’s a multiline text area.

  • Install and create a field such as test-textarea to see how easy it is to use.

It seems to export and import correctly via JSON as long as you dont edit the field without the above package installed.

Questions

  • Can you think of a better suffix to use for such fields?
  • Can you test it on a node install?
  • What happens if you edit the tiddler in an external editor?
  • Does this inspire any other ideas?
2 Likes
#2

There has been some discussion that core field-names should start with a single underscore or double underscore, to avoid name clashes with user fields. But it wasn’t implemented that way.

I have seen some plugin naming conventions that already use a single underscore similar to the _canonical_uri … which is used by the core …

May be for user plugin settings we may use a _text- prefix for multiline field: _text-some-name

So anyway there should be some discussion and a documented convention after consensus is reached.

2 Likes
#3

Thanks for your comments Mario. Here I am more interested in a user friendly naming standard, the first below, for users to introduce non-standard multiline fields. This could be divided into three audiences.

  • New to intermediate users introducing a multi-line text field.
  • Solutions developer and plugin writers
  • If the core was to include additional multiline text fields.

Personally I no longer think we need to decide on particular prefix or suffix now as it can be whatever is desired deployed via the Field Editor cascade as in my above package, and alternative handling is visible in
Control Panel > Info > Advanced > Cascades > Field Editor not that we shouldn’t suggest a naming standard.

  • I like the use of a suffix because the first part of the name is specific and functional and the format is but an attribute of the field, secondary information.

    Snag_2bf839
    Snag_2bf8391878×609 49 KB

  • But now I think we can abandon the use of the fieldname indicating it as follows.

However even better than using something in the name, I think we need to start defining “optional” fieldname tiddlers, just as we have tag tiddlers. Such tiddlers could exist as is eg: myfieldname or behind a name space eg $:/fields/myfieldname and within these tiddlers we could set an optional/rule in, field specific editor/viewer.

Until this field level definition is established users will install a multiline text solution with its self documented standard.

I am now looking at introducing some decent field definition and handling solution, which I have built a number of but now to integrate into the cascades.

  • I Think we should include a Field Viewer Cascade but I will post on that later.
#4

Hi Tones

This is really helpful! Thanks!

“Does this inspire any ideas?” Just one. Not sure if this is easy to work around, but it would be nice if somehow the field title and the delete button were on one line, and the text area on the next line. That would allow classes like textarea.wideedit {width:98%;} to work, expanding it across the width of the tiddler.

But that suggestion is not to take away from the positivity of this tool. As I said, this is really helpful. Blessings.

#5
  • Thanks for the feedback, I agree totally.
  • Despite my experience in this area I was not consulted (even although I stuck my nose in) on the introduction of this “field edit cascade” and the change was not the best in my view, the field edits are trapped inside a table, but I expect I can find a trick to do as you suggest.
  • I also believe we should introduce a field definition mechanism - which I am doing my 10th Proof of concept on, now based on cascades.
#6

FWIW, I do something quite similar and use a prefix ta-

#7

Hello! This is very useful, thank you very much. I am using TiddlyWiki to store records from a historical archive and have a lot of tiddlers where long descriptions are saved in a custom field rather than in the “text”.
I tried it on local node installation, seems to work as expected. The new lines are preserved in the field itself, but gone when it is transcluded. After changes from VSCode it is still working as before.
Is it possible to implement text area without appending suffix/prefix to the name field? Daria

#8

Rather than test for a range of fields, in my case that with a particular suffix. You could just test for a specific file name, or a list of filenames. It is the fieldname itself that is available for the filter.

Eg rather than [suffix[-textarea]then[$:/PSaT/EditTemplate/fieldEditor/textarea]]
try [match[fieldname]$:/PSaT/EditTemplate/fieldEditor/textarea]]

  • untested.

Otherwise tell us what test you want.

#9

Fantastic!

snip_textarea
snip_textarea861×116 7.19 KB

I would probably test the length of the field value and switch to text area above certain length, but this is just a wish, not sure if it is actually doable and not too expensive computationally…

#10

Along with length perhaps we could test for the existence of line feeds in the field eg "regexp \n "; however these would involve looking into the content of every field. This is far more processing than just determining text fields from their fieldname.

These questions are in fact a subset of a bigger set of questions of how to best handle both custom tiddlers and custom fields and whilst I have no interest in changing what “can be done with tiddlywiki” I think we can provide prebuilt mechanism’s so that much more can be done easily.

  • Its a matter of taking common requirements currently left to users and plugins to handle and providing a prepared set of tools for this tiddler/field handling.
  • I don’t think it is self aggrandising for me to say someone with my skills is in a position to do this based on decades of building IT solutions, the issues is the time it takes ands socialising the ideas with the community. I have also found it hard to get people to collaborate with me.
    • Also I have already done a lot of work on this, and have a wealth of techniques anbd tricks to apply.
    • If have observed a gap in understanding between superusers like my self and the developers on the “design issues confronted by tiddlywiki designers”, who are not developers.

I think I will enhance the solution posted here for users to simply designate a field as a text area (or other field type) and apply the appropriate editor, just as created and modified are already handled by the system.

Thanks for the feedback its helping.

#11

I am seeking more feedback from the community, this tool is already useful but how can it be improved?

#12

If just a suggestion for a suffix, what about just adding a + at the end of the field? I can’t think of a reason why someone would do that without a specific intent.

field:biography for single line, field:biography+ for multiline. (I don’t know if ending it in a plus could cause conflicts with filtering though.)

also, how possible would it be to create a button to toggle between normal and multiline? having something like a 3 line hamburger icon that turns to a - when you’ve switched could give a good visual indication that the field you are using is now a textarea.

#13

It should be possible to use this mechanism https://tiddlywiki.com/#Customizing%20EditTemplate%20field%20rendering … So no new core code should be needed.

#14

Hey all, I’d love to see the option to include or exclude fields from this expanded-text-area treatment in a more dynamic way.

Perhaps in an early phase of project, we inherit data that comes in through multiple bulk JSON import batches. Perhaps we need to troubleshoot the potentially verbose contents of one imported field (that already has a name without + at the end), and so we want to flag it for expanded text-area handling.

Perhaps later in developing that same project, that long field may no longer need the same screen real-estate; it’s now background noise (or we have a sophisticated ViewTemplate for it, whatever). It would then be nice to un-flag it for this special handling within the fields area, without needing to rename the field.

In general, I think that field-naming conventions can be tremendously useful, and we can all learn from “best practices” discussion… but we should be wary of building them into the TW or plugin architecture, largely because of (1) inherited data structure, and (2) evolving use needs.

-Springer

2 Likes
#15

Springer,

That is an importiant point. We should not dictate the field name and allow any to be set as a text area in part because these fields could be in an incomming tiddler.

It is possibly better to hide the field or set it as one row than to defeat the text area editor because to do so mean the field will loose its new lines if edited.

However the prefix or suffix on text area fields idea is about quickly creating a new field on demand that is a text area.

1 Like
#16

I did create 2 plugins which are introduced at: [Intro] Field Editor Plugin and [Intro] Field Visibility Plugin

It should be possible to extend the field-visibility settings with more options

1 Like