Extending the core edit macro

[Saq Imtiaz]

I would like to propose that the core edit macro be extended to allow text area's for fields other than the tiddler text. Currently it defaults to inputs for all fields other than 'text'.

Now I realize that we can't accommodate all possible needs in terms of input for fields, but in the case of text area's all the necessary code is already in place. A simple change like an optional second parameter to override the default assignment would do the trick, while maintaining backwards compatibility.

Something like this: (changes in red)

	var field = params[0];
        var inputType = params[1]? params[1] : "input";

	if((tiddler instanceof Tiddler) && field)
		{
		story.setDirty(tiddler.title,true);
		if(field != "text" && inputType != "textarea"
)
			{
                         var e = createTiddlyElement(null,"input")
                         ......
                         }
                 else
                      //create text area

I'll create a ticket if the consensus is that this change is worthwhile.
Cheers,
Saq


--
TiddlyThemes.com : a gallery of TiddlyWiki themes.
LewcidTW (http://tw.lewcid.org): a repository of extensions for TiddlyWiki

[Clint Checketts]

I'm for this, but the change would affect the storage mechanism.

-Clint

[Jeremy Ruston]

I'd be happy to see this in the core, but I'm not sure what you mean,
Clint, about affecting the storage mechanism?

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[Saq Imtiaz]

I'll ticket it shortly.
And Clint, I don't quite follow either. What do you have in mind regarding the storage mechanism?
Cheers,
Saq

[Clint Checketts]

Jeremy Ruston wrote:
> I'd be happy to see this in the core, but I'm not sure what you mean,
> Clint, about affecting the storage mechanism?

I'd assumed the current behavior was because tiddlers are saved like
so:

<div tiddler="SomeTiddler" modifier="JeremyRuston"
modified="200508181424" created="200508181424" tags="features
options">Stuff from the text area</div>

So, if we can have multiple text areas, where would that text be
stored? In fact, I seem to remember that if I didn't have a text area
then the tiddler save would fail. I could be remembering old data
though.

-Clint

[Jeremy Ruston]

> I'd assumed the current behavior was because tiddlers are saved like
> so:
>
> <div tiddler="SomeTiddler" modifier="JeremyRuston"
> modified="200508181424" created="200508181424" tags="features
> options">Stuff from the text area</div>

Ah, I see. In fact I guess the current behaviour is because the body
text is the only field that can contain newlines and hence requires a
textarea.

> So, if we can have multiple text areas, where would that text be
> stored? In fact, I seem to remember that if I didn't have a text area
> then the tiddler save would fail. I could be remembering old data
> though.

I interpreted Saq's request as to be able to, say, put the tag listing
in a multiline textarea instead of a singleline input box, rather than
being able to have multiple bodies for a tiddler.

But you have reminded me of an issue that we need to take care of:
making sure that newlines are somehow stripped from the textareas for
storage.

Cheers

Jeremy

> -Clint

[Saq Imtiaz]

I hadn't realized the issue with newlines etc. While it would be terrific to be able to store multiline text in extended fields using text areas, even the ability to put single line fields into text areas would be a welcome one I think. Should I still go ahead and ticket this?

Also, any suggestions for how I could get multiline text working in a field in a plugin for instance? Would escapeLineBreaks and unescapeLineBreaks do the trick?

If it would, it would be quite simple to add that in for all text areas except the text in both the edit and the view macro.

On 1/4/07, Jeremy Ruston <jeremy...@gmail.com> wrote:

[Jeremy Ruston]

> I hadn't realized the issue with newlines etc. While it would be terrific to
> be able to store multiline text in extended fields using text areas, even
> the ability to put single line fields into text areas would be a welcome one
> I think. Should I still go ahead and ticket this?

> Also, any suggestions for how I could get multiline text working in a field
> in a plugin for instance? Would escapeLineBreaks and unescapeLineBreaks do
> the trick?

Yes, that would be the way to do it, I think. There will be some
tricky rules for which fields get escaped; in 2.2 we will no longer be
escaping line breaks in the body text, thanks to the new support for
<PRE>s in the storeArea.

Cheers

Jeremy

[Udo Borkowski]

But you have reminded me of an issue that we need to take care of:
making sure that newlines are somehow stripped from the textareas for
storage.

At least since 2.1 with the introduction of the MetaData feature (ehmmm, I mean the "custom fields") adding newlines to a field (either standard or custom) should not be a problem.

Udo

On 1/4/07, Jeremy Ruston <jeremy...@gmail.com> wrote: