Saq,
Am I correct ? I think this is behind the problem you have of
simplification. Otherwise this would be sufficient
[tag[Widgets]get[caption]else[title]]
Typically a filter returns a list of titles, even if they are virtual,
strings that are not actual tiddlers. operators permit references to other
values such as tiddler content, variables and fields. These allow complex
conditional selections or titles to be generated. The filter functionality
has being developed much further so the output of run can be numbers,
modified strings and titles etc... The result of filter in the list widget
is returned via the currentTiddler/named Variable or the emptyMessage ONLY.
>From the above we can process each title and reference each titles
additional content using the title as a key. For example we can access the
caption in side the list {{!!caption}} this is the display process.
Since filters are so rich in functionality we can generate other lists, one
may be a set of tiddlers with caption OR title as the output, this is
returned as the title via the currentTiddler/named Variable ONLY. Currently
when you make this decision to extract secondary data in a filter you may
loose access to the key (the tiddler title). The feature to do this is
great but it is mixing the selection process with the display process. This
is fine but presently the original tiddler title if present is lost as the
display is the caption/title output not the always the title of the
tiddler, you may loose the key.
Prerelease shows how a second value can be returned for each item in the
list, in this case the counter number. In some filters it would be good if
an additional variable that passed on the original tiddler title, in your
example all [tag[Widgets]]. sure some of these tiddlers will be
eliminated, and there name not accessible, because the list never displays
them, but the ones it does it would be useful. Sometimes the titles are
virtual strings, but making these available may also be helpful.
If you are prepared to split selection and display (in your case no) or
nest lists there is not problem. We could write a macro with two filters,
one selection one display and this would not be an issue.
Is this in your problem scope?, or divergent?, What do you think?
Tones
On Tuesday, 15 June 2021 at 21:12:40 UTC+10 Saq Imtiaz wrote:
> @Tony
>
> Could you give some idea of how/why* It is going to be used in a context
>> where other wikitext cannot be introduced. ?*
>>
>
> Explaining my specific use case would be quite complex as it is part of a
> much larger application. The filter I've described in this thread is a
> simpler one that presents an analogous issue, where you want to replace an
> input title with one if its field if that field exists, otherwise retain
> the original title. All without changing the list order. It could just as
> easily be get[parent] instead of get[caption] if that helps with
> conceptualizing the problem.
>
> There are plenty of general use cases where a filter needs to provide the
> necessary output independently of other wikitext. For example:
>
> - As input to a widget that accepts a filter attribute.
> - In a configuration tiddler that accepts a filter. See for instance
> $:/config/syncFilter or $:/core/ui/DefaultSearchResults.
> - As a filter meant to be used elsewhere via the subfilter[] operator
> - When trying to optimize refresh performance in a large and complex
> widget tree and wanting to use as few widgets as possible.
>
> I am interested in the challenge.
>>
>
> A good way to frame the constraints is that it should be possible to type
> the filter directly into the Filter tab in AdvancedSearch.
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/81729bea-d24c-4a1b-b04d-24dcf28c47dan%40googlegroups.com.
