Using textareas instead of inputs for fields?

[Justin_H]

So I’ve been tinkering with the fields in the editTemplate (with the previous help from @EricShulman in my other post), and was curious of a few things (also, here is my early works on using textareas in place of inputs, use at your own risk- its a bit hacky and probably not stable IDK, I recommend putting it into an empty TW)

TextAreaFields.json (2.2 KB)

1. Is there any sort of problems with using textarea input types rather than normal inputs when it comes to fields?

2. is there a way to keep the field name input and add btn inline with the first line of the textarea, rather than the last one?

3. How can I get the textarea to expand more in the editTemplate? Seems to stop after a certain width and height, and I haven’t found a workaround just yet.

4. Am I doing anything that could potentially break the tiddler?

My goal is to have each field contain whatever text, and to have a btn next to the textarea that uses the show/hide icons that toggles if that specific field displays in that tiddler (I don’t know if this is possible yet, but I’m certainly going to try haha)

[TW_Tones]

Thanks for sharing.

I think the main place to test this, going on past efforts is to check tiddlers containing such fields can be exported and imported in the various formats including that used on node, to check it does not give rise to lost data.

• I think this is less an issue now that tiddlers are saved internaly as JSON

I could comment in more detail if I had a little more time, I have taken a somewhat different approach but I will share this use and you can explore the functionality local-viewtemplate.json (5.0 KB) ince imported go to any tiddler and add the field local-viewtemplate.

• A new text area editor appears, the field is hidden from the standard field editor
• This is “what it says” a local view tempate, and the content becomes a local (this tiddler only) viewTemplate.

[Justin_H]

I think I can learn from how you’re able to import and use the editor toolbar and how you’ve displayed your custom fields. As I am right now, I’m not really sure how to have specific fields appear per tiddler.

I’m wondering if I can look into how the tiddlers related to $:/config/ShowEditPreview/PerTiddler do this with the edit preview

[TW_Tones]

I have in the past exposed existing (unused) previews inside the Editor preview and in fact added new ones. One is in fact is a standard editor when using CodeMirror so you can use the browser based spell check, which does not work in codemirror.

• Are you thinking to leverage the preview layout to introduce an editor for such text fields?
  • I think the edit field approach of yours above, or mine above, would be more appropriate, It would confuse what preview is about, since at present it only operates on the text field,
• unless you had a seperate button to the preview to open a seperate editor, but it could be done.
  • That sounds like a good project, especialy if it was generic, letting the designer choose what appears in the preview panel space. Eg Guide notes, special field editor, view hiddlen notes…
  • The dropdown could instead allow to to select from a list of text area fields, but what about a switch to replace the default text editor, to operate on a selected field?

@Justin_H

As I am right now, I’m not really sure how to have specific fields appear per tiddler.

• The simpler approach is to use the view and or edit template mechanisiums
• Althernativly use the cascade mechanisums, particularly the View/Edit template Body cascades. But this is more complex that a new user will like.
• Perhaps start a topic with this specific question and a description and an example of what you want.

[Edited] Fixed a typo

[Justin_H]

@TW_Tones

Are you thinking to leverage the preview layout to introduce an editor for such text fields?

At the moment, maybe- however this wasn’t my initial idea.
Originally, I had the desire for a dropdown that showed all fields of the tiddler, and it wass defaulted to the text field, but if you had a field for description for example, and you picked it in the dropdown, it would switch the main text preview preview to edit that field, so that you could just, use the editor toolbar and multiline text that way.

Unfortunately I wasn’t really able to work out how to do that, so I’ve been playing with other methods, such as the expanding textarea field idea this post is about

@TW_Tones

but what about a switch to replace the default text editor, to operate on a selected field?

Actually that sounds a lot like what I had tried to do in the past, funnily enough.

@TW_Tones

Althernativly use the cascade mechanisums, particularly the View/Edit template Body cascades. But this is more complex that a new user will like

Yea… I might be in deeper waters than I know how to swim in at present if I go that route haha

@TW_Tones

Perhaps start a topic with this specific question and a description and an example of what you want.

I may need to go that route, I think this could be a pretty useful plugin or set of tiddlers for those who would like to use their fields for other purposes than the usual usecase.

[TW_Tones]

@Justin_H

@TW_Tones

Althernativly use the cascade mechanisums, particularly the View/Edit template Body cascades. But this is more complex that a new user will like

Yea… I might be in deeper waters than I know how to swim in at present if I go that route haha

Actualy I think if you go the idea to have a dropdown to switch which field the editor using the casecade method would be better thn modifing the default edit mechanisium.

• I we can help, here of course,
• in fact sometimes the ideas that come from people who dont yet know how to implement it are valuable because they are from a different perspective that a long time user may not think of because they are used to the “normal” way.
• Still we need to question if it does add value and/or if we can add more value another way.

[Justin_H]

@TW_Tones

Still we need to question if it does add value and/or if we can add more value another way.

The first and simplest thin I can imagine it being better than a standard input field at is that you can use it for bodies of text that are related to the tiddler but not significant enough to merit it’s own tiddler.

an example that comes to mind for me is making a character sheet / character dossier, where each field could be referenced in the body text in a table to look similar to a fandom character wiki, where lets say there is an aside section for “Aliases” you can have a field called “character-aliases” and inside it, have a bulleted list of aliases, rather than having to separate each alias within the fiedl with a <br> or as their own field.

Edit: To add onto above, having them all in a single tiddler allows for easy editing without the need for opening other tiddlers

Or maybe using it to store the styles of a tiddler within?

Just brainstorming some use-cases, I just did not enjoy how if I had a decent amount of text in a single field that meant I would have to scroll horizontally, which isn’t really viable with most mice…

I’m going to go AFK for the night, so forgive me in advance if any future replies aren’t for awhile.

[TW_Tones]

Interesting, but I also see the use of “compound tiddlers” which you may not have come accross.

• Look around, because a lot of people have built game and character wikis.
• I think you will enjoy this journey into the posibilities of TiddlyWiki
• Look up the use of the class field
• List fields similar to the tags field are posible

Night!

[Justin_H]

@TW_Tones

Look around, because a lot of people have built game and character wikis.

I have seen one or two, I’ve been meaning to take them apart haha

@TW_Tones

“compound tiddlers”

they’rethe same as an impure tiddler, right?

@TW_Tones

Look up the use of the class field

Are you referring to this by chance? If so, I’m familiar with them, this is a very handy trick for styling tiddlers, though I mainly use data-tags when styling tiddlers.

[DaveGifford]

Not sure if anything from this discussion would be of help to you: Second text field, best way to do it?

[Justin_H]

Quick note on something I’ve discovered, turns out changing the fields to use the custom textarea has removed the color picker from the color field.

I’m not entirely sure if I know how to remedy this, any suggestions? I don’t find it to be a big problem for my personal use since I use hex codes for everything, but I imagine if other users want to use this customization, they would like to keep the color picker

(Also turns out the use of macros does work for normal fields, but not for the color field, so my hopes of using <<colour>> for tiddlers is not available )

[pmario]

@Justin_H

1. Is there any sort of problems with using textarea input types rather than normal inputs when it comes to fields?

There is not necessarily a problem, but there is a side-effect. If you ever use a Node.js version, all your tiddlers with fields names with spaces or lowercase/uppercase field names will be stored as tiddler.json instead tiddler.tid

Also as soon as a field has a linebreak in the “text” area it will also be converted to the .JSON format.

So not really a problem but a side effect, that will make it hard to edit those tiddlers in plain text mode with a 3rd party editor.

[Justin_H]

ah, I wasn’t aware of that, I only ever use a tiddlywiki through a web browser, learning how TW works with node.js has been something I’ve been meaning to look into.

So, I may by misunderstanding this but, the field title and field text will be their own separate json files, if a space or new line is introduced? What prevents the field title from doing that with the default version?

[pmario]

@Justin_H

So, I may by misunderstanding this but, the field title and field text will be their own separate json files, if a space or new line is introduced? What prevents the field title from doing that with the default version?

The whole tiddler will be a tiddler.json file. The problem with the .tid file format is, that it does not understand multiline fields. That’s why we use JSON format at the moment.

The disadvantage is, that JSON format is more complex to edit with a 3rd party text editor.

[Justin_H]

Ah ok, now I follow.
I’ve only ever exported .tid for importing and exporting into other tiddlywiki.

I’ve just exported a tiddler with these custom fields as a .tid, and imported it into a blank tiddlywiki, and on import, any text that was in a field that wasn’t in the first line, became the body text.

This could be potentially kind of bad I think.
Edit: Slight good news, it isn’t replacing the body text, simply adding to it. Still though, not intended behavior.
Is this fixable?
Changing the way .tid’s are formatted is the only thing that comes to mind for me, or having some what of converting the text in the mutliline fields to be single lined…? I’m not sure :\

[pmario]

@Justin_H

Is this fixable?

Not at the moment. We do not have a .tid format, that allows us to create fields with new-lines in it.

There have been some discussions, but we did not come to a conclusion. Not even close.

[TW_Tones]

Single file wikis and importing and exporting one or more tiddlers as json is the preferred approach and there is little reason to export .tid files. Using node and wanting to edit tiddlers as files seperatly is preferred by some perhaps those that dont like touching a mouse and some edge cases. You need a node servers to do smoothly.

• if its is about interwiki or interapplication data sharing there are many different ways to handle this from drag and drop to custom exports.
• The main reason I would not Typicaly ever edit a tiddler outside a tiddlywiki is because I customise my tiddlywiki to be the filesystem, editor, software development platform I need.

[Justin_H]

Revisiting the post once more, with a small question!

Is there a way to exempt a specific field from using the overridden $:/core/ui/EditTemplate/fieldEditor/default that contains the modification to use a textarea in place of an input element?

I admit, I somewhat miss the convenience of the color picker, haha…

For reference, the text within it is:

<$edit-text autoHeight=yes tiddler=<<currentTiddler>> field=<<currentField>> tag="textarea" default="" class="tc-edit-textarea tc-edit-texteditor tc-edit-fieldeditor" minHeight="1.5rem" placeholder={{$:/language/EditTemplate/Fields/Add/Value/Placeholder}} rows=1 tabindex={{$:/config/EditTabIndex}} cancelPopups="yes"/>

[TW_Tones]

@Justin_H I am not exactly sure what you mean here but there is now the Field editor cascade for setting up alternative field editors.