actually, the task of parameterizing the code over a whole data tiddler's
indexes set is not challenging in itself, I already did and pasted above.
What is challenging, better said: impossible! , is to complete this latter
chunk of 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>
with a (sub)filter step -possibly stored in a variable- that parameterizes
it so it can work over the whole set of a dictionary entry's indexes...
Anyway the subfilter's way is a winner, I'll stick to it.
On Saturday, November 20, 2021 at 3:51:12 PM UTC+2 CarloGgi wrote:
> 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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/f8470af2-b30b-4d69-b577-a79bff579b45n%40googlegroups.com.
