Fields other than the default text field being able to be treated also as a textarea?

[Cade Roux]

I was wondering if anyone has done anything like this where a tiddler has another field "promoted" to a "textarea"-type of field like the main text field so that a tiddler has two text areas when it's in edit mode, where one is the text of the tiddler and one is the field denoted to be edited in a textarea instead of a textbox with all the other (shorter) fields.

In my particular use case, the second field is directly related to the first, but an alternate rendering or similar.  In my case, one is HTML and the other is raw XML or some other related data but they differ such that they aren't realistically directly transformable from one to the other within the browser.

In the past I have put that text in a separate tiddler that is directly linked to the first, but I have found over time, that that technique has grown unwieldy and I have moved many things back into fields in the main tiddler (including these large bits of text/data - which are just very difficult to read in edit mode in their fields - they are obviously fine when transcluded or otherwise used).

Thanks in advance,

Cade

[David Gifford]

I can't speak to the issue of linking or the relationship between the fields, but if the issue is just the small side of the edit box, you could try the editwidget. I use the following in one tiddler to adjust the content of a custom field of a second tiddler.

<$edit tag="textarea" tiddler="yourtiddlernamehere" field="yourfieldnamehere" class="tc-edit-texteditor"/>

For your case scenario, it would be a matter of changing tiddler="" to a 'currentTiddler' filter, adding it to a tiddler, and tagging the tiddler $:/tags/EditTemplate . Not sure what you would need to put. But that would give you a bigger area to work with for that field / those fields.

[TW Tones]

Cade,

I have a solution I am proud of that uses all the mechaisiums you are asking for. It is attached. Let me know if you need more instructions.

I am yet to polish it for publication but it is a tool to have local view templates specific to a tiddler, it works by only allowing you to edit the local-viewtemplate field in a multiline editor in edit mode. It gets hidden from the field in edit mode otherwise the you loose the line breaks.

• Drop the package local-viewtemplate on a wiki. It does nothing without further action.
• Edit a tiddler and add a field "local-viewtemplate" with or without a value, click add
• Now the multiline editor of the local-viewtemplate field appears in edit mode.
• In this case there is a local view template that will display the fields contents in view mode.

Not only does it demonstrate multiline fields it provides a quick and easy test bed for writing view Template tests that will not appear everywhere.

There is a possibility tiddler may not be saved correctly on node implementations. But I checked right now on Bobexe and it survived a save and reload.

Regards

Tones

[Cade Roux]

Thanks, I will check that out once we get through this current release.

We started with TW just being a great way to output a single HTML file of data dictionary/build status/testing results to be shared and approved instead of Word/Excel document artifacts.  But we treated it as a target document output until we had enough time to play with it, see how stakeholders responded and learned how to use it.  We wanted to be able to pivot away from it if users weren't happy with it.

But now, Instead of treating it as a target where we generate all the lists and tiddlers fully formed the way we want them to be presented like you might generate multiple HTML pages on a site, we've moved to really using it more "natively" in the sense of only exporting very simple data-like tiddlers and using filters and macros within TW tiddlers to generate information from them.

Thanks,

Cade