subfilters are key! I just came across 'filter' operator and I'm pretty
much confident it can do what I want.
So far I was able to implement this test code
<$set name="subf" value="[getindex[IT-01]split[,]trim[]match<keyword>]">
<$list filter="[tag[dict-AR]filter<subf>]" variable="entry">
<<entry>> <br/>
</$list>
</$set>
which behaves the way I want because the filter in the inner <$list> scans
ALL the dictionary entries (tag[dict-AR]) and outputs those whose IT-01
index's content matches the keyword dominantly appending them -that's the
word I was missing- to the output, so ridding the output of any duplicates.
Now the problem is to parameterize the code so to have it run on ALL the
indexes (IT-01, IT-02, IT-03, ...) of every data tiddler, and this last
step, once again, is CHALLENGING.
On Saturday, November 20, 2021 at 2:20:38 PM UTC+2 PMario wrote:
> On Saturday, November 20, 2021 at 12:12:54 PM UTC+1 CarloGgi wrote:
>
>> Hi PMario, thanks a lot, indeed my code is inconsistent because in an
>> attempt to give a generic example, not tied tho the specific issue, I tried
>> to simplify it (and I ended up to over-simplify it).
>>
>
> I thought about this, that's why I did try to create something that could
> have been a possibility and shows how TW filters work. .. Filters are the
> powerful thing in TW.
>
> If you come from a programmers background, TW is different and needs a bit
> of a different thinking, because it is targeted to non-programmers ...
>
> The whole TW UI is built with filters and wikitext templates and makes
> heavy use of recursions especially in the core code.
>
>
>> Lots of stuff to reply to, let's go through it point by point:
>>
>> 1. indeed widgets are no programming language, that's why I used the word
>> 'environment', not 'language';
>>
>
> Widgets don't have a return value ... They manipulate the DOM ... eg:
>
> ```
> <ul>
> <$list filter="[tag[todo]]">
> <li><$text text=<<currentTiddler>> /></li>
> </$list>
> </ul>
> ```
>
> From a programmers point of view, you'd probably want to "add" some
> variables inside the "list -loop"... But
>
> Let's say I have 2 tiddlers "a" and "b" tagged "todo"
> `[tag[todo]]` returns a list and the list widget internally assigned the
> element to an internal variable named `currentTiddler`, then it iterates
> over the list and outputs the dom elements in the "list-body".
>
> The "list-body" is between `<$list filter ...> list body is here
> </$list>` which looks similar to a function, but it isn't...
>
> The resulting HTML code will look like this:
>
> ```
> <ul>
> <li>a</li>
> <li>b</li>
> </ul>
> ```
>
> So widgets don't calculate variables, they are used to manipulate the HTML
> output ....
>
> ```
> <ul>
> <$list filter="[tag[todo]]">
> <li><$link /></li>
> </$list>
> </ul>
> ```
>
> This example uses a lot of shortcuts with TW default values. `<$list
> filter="[tag[todo]]">` is a shortcut for: `<$list filter="[tag[todo]]"
> variable="currentTiddler" >`. `<$link />` is a shortcut for `<$link
> to=<<currentTiddler>> />`
>
> The HTML output is
>
> ```
> <ul>
> <li><a class="tc-tiddlylink tc-tiddlylink-resolves" href="#a">a</a></li>
> <li><a class="tc-tiddlylink tc-tiddlylink-resolves" href="#b">b</a></li>
> </ul>
> ```
>
>
>> 2. .... it is frustratingly difficult to output a number of text entries
>> (filtered out from a db made of data tiddlers) excluding duplicates, and
>> this because in TW you cannot assign to a 'variable' other than at
>> declaration time, so you cannot incrementally append your entries to a
>> 'list' variable for post-processing.
>>
>
> That's right from a programmers point of view. ... But it will be very
> elegant, once you understand the mechanism. ...
> As I wrote TW uses sensible defaults for widget parameters, that's why it
> is important to have a closer look at the docs. ..
>
>
>> Acknowledging that TW is not a full-featured programming language, I'm
>> pretty much sure that it was conceived to enable users to do such kind of
>> stuff: filter out and manipulate chunks of text;
>>
>
> As I wrote it's built to manipulate text. .. As above it's designed to
> manipulate the DOM ... May be this view will make it clearer for you.
>
>
>> 3. filters have if-then-else logic but only to a limited scope. Filters'
>> if-then-else statements can only output text strings;
>>
>
> Not really, they can also be used with variables eg:
> `[tag[todo]get<variable>]` or `[tag[todo]get{reference}]`
>
> With the *first* example if you $set variable to eg: `hugo`, it will read
> the content of the `hugo` field.
> The *second* example will use the 'text' field of the tiddler
> 'reference', reads the content of that field and uses this value to read
> the value of the "todo" tiddler. ... So it's similar to a "pointer".
>
>
>
>> 4. filters indeed create and deal with lists, so the only place where
>> hopefully I can do my processing is within a filter, but it is quite
>> difficult to write a one-liner that does what I want,
>>
>
> Yes, filters can become complex. So sometimes it is needed to define
> several variables upfront, that contain "filtered" elements already. ...
> It's also a bit of the speed advantage, because wikitext is "interpreted",
> but heavily cached. ...
>
>
>
>> let me paste my true code below (I'm sure that a better developer could
>> write a more elegant, more synthetic one merging some of the <$list>
>> widgets together into a single one)...
>>
>>
> I'll have a closer look at the code and write a new post ...
>
--
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/46e7f601-370c-4327-92b6-0d3fc2976ba8n%40googlegroups.com.
