Hi TheDiveO I've gone ahead and made some modifications along similar lines to allow the visible edit fields to be configured:
https://github.com/Jermolene/TiddlyWiki5/commit/d357e1706c91d17a72fb19fedf43e57071fc7dd6 To hide "myfield" one would create a tiddler called: $:/config/EditTemplateFields/Visibility/myfield with the text "hide". Best wishes Jeremy. On Thu, Jul 31, 2014 at 11:57 AM, TheDiveO <harald.albre...@gmx.net> wrote: > Around TW 5.0.6 we had discussed what would be a good way to selectively > suppress certain fields in the default field editor template part. At that > time Jemery proposed to introduce some support in the underlying mechanics, > namely the new filter operators "prefix" and "removeprefix". > > Since I now took the time to upgrade my existing TW5 from 5.0.6/7 to > 5.0.13 I would like to bring back this topic for further discussion, and > hopefully TW5 support for the missing final piece. My impression then was > that the overall idea is of greater interest so that there is a change of > adding it to the TW5 core without making it too bloated. For this reason > I'm now bringing forth this discussion. > > *Background* > > I need to work with RFC documents a lot. TW5 is simply great for such > tasks of organizing and structuring huge heaps of information as to get > some grip on a particular field of knowledge. Alas, I have tiddlers tagged > as "RFC" which then show a dedicated RFC document data field when they got > edited. The RFC document data gets stored as tiddler fields, such as > "rfc-title", "rfc-cat", and so on. > > So in order to reduce clutter, I want to hide only these fields > "rfc-title", ... from the standard edit template field part. > > *Implementation* > > Based on the technical discussion and the current implementation of TW > 5.0.13 I'm building on the core list sorting functionality as well as on > the filter operators "prefix" and "removeprefix". But I need a minor change > in a core component in order to get field hiding support ... and this is > what I'm asking here for... > > In $:/core/ui/EditTemplate/fields we currently have a list widget that > lists all fields, but with the exception of the well-known built-in fields > which need to be treated differently: > > <$list filter="[all[current]fields[]] -title -tags -text -creator -created > -modified -modifier -type -[[draft.title]] -[[draft.of]] +[sort[title]]" > variable="currentField"> > > On the basis of our older discussions I would like to propose this > addition (maked in bold/yellow) here: > > <$list filter="[all[current]fields[]] -title -tags -text -creator -created > -modified -modifier -type -[[draft.title]] -[[draft.of]] > *-[tag[$:/tags/EditTemplateFieldEditorHide]removeprefix[$:/config/Fields/]]* > +[sort[title]]" variable="currentField"> > > So what does this do? After we've fetched the list of tiddler fields and > trimmed it down we next look for field configuration data that signals to > hide a particular field. From the previous discussion my understanding of > Jemery's overall idea here is to use such generalized field configuration > tiddlers. Due to the way the removeprefix filter operation works, field > configuration tiddlers need to live below $:/config/Fields. I understand > this limitation to not be a real limitation as my impression then was that > Jeremy wants to concentrate field configuration in a single branch of the > name space anyway. In contrast to my first proposal some time ago, this new > proposal solely bases on the removeprefix filter operator. > > In order to suppress a field, say, "rfc-title" I thus create a tiddler > such as $:/config/Fields/rfc-title and then tag it with > $:/tags/EditTemplateFieldEditorHide. This then causes this field to be > removed from list of fields the field edit template uses. Please note that > all field configuration tiddlers not living inside $:/config/Fields will > be silently ignored (and removed by removeprefix). > > To sum up, I would like to ask for this change to be added to the TW5 > core. To the best of my limited understanding this does not cause any > noticeable performance penalty, yet it adds to the modularity and > extensibility of the TW5 core. No further changes to the TW5 core are > necessary. > > *Verdict* > > So ... what's the Jury's verdict on this matter...? > > Best regards, > TheDiveO > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to tiddlywikidev+unsubscr...@googlegroups.com. > To post to this group, send email to tiddlywikidev@googlegroups.com. > Visit this group at http://groups.google.com/group/tiddlywikidev. > For more options, visit https://groups.google.com/d/optout. > -- Jeremy Ruston mailto:jeremy.rus...@gmail.com -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywikidev@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
