Hi FND, Indeed a valid point to, in general, encourage avoiding to use fields as first class gui members. However, here come the buts...
For one, using EditTemplateFieldsPlugin already means that one needs to edit in general programatically accessed data. If - for whatever reason - one of these fields contained linebreaks and it were edited in a currently used input element of EditTemplateFieldsPlugin, chances are that one (not even intentionally) saves corrupt data back to the tiddler field. Secondly, I think linebreaks in fields can be quite useful programmatically, not just as separators for its contents but also to improve readability when looking at the standard fields popup. Lastly, if I needed multiline data attached to a tiddler I would not want to create some 'associated tiddler'. Nor would I find structured data (not directly used as displayed content) to be well situated in some vulnerable /%data section%/ in the tiddler's body ...unless, of course, we're talking about 'simple, editable content' in the form of slices or sections transcluded 'as is' (with the occasional placeholder). To conclude, it might be beneficial for EditTemplateFieldsPlugin to also provide an optional 'fields accessor' that made sure that one could only edit fields that have been explicitly declared in some form as being editable ones, e.g. a bracketedList declared in a EditTemplateFieldsConfig, thus: <<editFields config:EditTemplateFieldsConfig>> Cheers, Tobias. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
