Hi TheDiveO Apologies for the delayed response. I've been behind a backlog for a few weeks now.
I understand what you're asking for here, and I can see the motivation. I don't think it's doable with the current primitives though. I'd also be a bit worried about performance and comprehensibility. If the core implements complex logic to determine which fields are visible then users will have to be able to run that logic in their heads to understand why they aren't seeing the fields they expect to see. Best wishes Jeremy On Sun, Oct 26, 2014 at 7:14 PM, TheDiveO <[email protected]> wrote: > 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. > -- Jeremy Ruston mailto:[email protected] -- 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.
