Some time ago I asked for suppressing certain user-defined tiddler fields from the generic field editor view template. Jeremery was so kind as to implement this function already in the beta TW 5.0.x series. Please note that the current mechanism is static: you can selectively hide fields based on their name, but if you do so, then this field won't be shown in the field edit template anymore. This is fine when you are using custom fields that use uncommon names so that there is no chance that another tool uses a field with the same name for a different purpose.
While working on a plugin meta data editor I've now in the situation where some plugin-relevant fields have common names, such as "author", "description", and some others. Hiding such fields would hide them also from tiddlers in other contexts where these fields should and must not be hidden. So, would it be possible to implement selective hiding of tiddler fields into the core? My first rough idea is to have a first filter expression (part) that is used to decide whether to remove a set of fields specified in the second filter expression (part). The first filter part would allow to conveniently filter not only for tags but also for certain other fields and field values. For instance, "[is[current]!field:plugin-type[]]" would "fire" when the current tiddler to be edited is a plugin tiddler. In this case, the second part of the filter expression would specify the fields to remove from the general field list for editing. But where to store the individual filter expressions? Since we probably could have multiple sources for such expressions they cannot be field-centric, in the sense that today we can statically hide a particular field. Instead, plugins would bring in their own tiddlers when needed, so a system tag would probably the way to go here, say, $:/tags/FieldVisibilityExpression. What I'm not clear about: what would be the best way to enhance the existing field edit template so that it can now iterate over the field visibility filters installed? Would it make sense to implement this through a filter operator? Would this work when the installed filter expressions change? Or would it make more sense to implement a new widget that is able to iterate over expressions returning a modified field tiddler result set? 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
