Least bad strategy to change template in Advanced Search results?

#1

I want to change the behaviour of Advanced Search so that the search result list titles are shown via a modified template. (Basically, each title should have a little button next to it).

What’s the best way to do this? I see two strategies but both seem to have rather costly downsides. Which of these is the least bad:

First idea
Modify the original template, i.e the shadow tiddler, $:/core/ui/ListItemTemplate that TW uses to display each search result list item.

Original: <div class="tc-menu-list-item"><$link /></div>

Modification: <div class="tc-menu-list-item"><$link />{{||mod}}</div>

This works well but:

  • other core title lists also use this template, e.g the sidebar lists! So, I’m using CSS display:none to hide the mod in everything that is not the AdvancedSearch lists.
    - Is this bad? It does behave as desired but the inspector tool shows that each listed sidebar title still brings the modification with it albeit hidden. (I guess this means that it exists in the DOM)
  • on the plus side, I think this shadow tiddler is unlikely to be updated in future TW releases.

Second idea
In AdvancedSearch, modify all four tab tiddlers (Standard, System, Shadow, Filter) to not call for the native $:/core/ui/ListItemTemplate but instead simply call for a custom template (with the contents as shown here above). Might seem to be the proper way but:

  • Four overwritten core tids
  • The chances of these being updated in future TW releases is quite big

Other thoughts
I know there is talk about “hooks” in the core (even if I only vaguely know what that means). Would it make sense to request a such in the $:/core/ui/ListItemTemplate ? I can’t be the only one who wants to manipulate the display of native list items?

Is there a “code alternative” to css hide:none that conditionally prevents stuff from showing in the DOM, and that doesn’t require user interaction? (RevealWidget? But how can it be made to sense if it is inside an AdvancedSearch tab vs elsewhere?)

Again, it is for a plugin so the consequences will affect anyone installing the plugin.

Thank you.

1 Like
#2

I have come up with the following idea. It relies on the discovery that the $:/AdvancedSearch tiddler provides a variable - resultCount - that is accessible within the four tab tiddlers (Standard, System, Shadow, Filter) but not from lists outside of the AdvancedSearch.

<div class="tc-menu-list-item"><$link />
<$list filter='[<resultCount>then[$:/AdvancedSearch]]' variable=curr>{{||mod}}</$list>
</div>

It works, but is it a decent strategy?

#3

Coincidentally I had just started doing the same thing. But I’ve just started this morning and so for now I have no ideas other than those you proposed; my approach was your second, that is to modify all four Standard, System, Shadow, and Filter tabs. The only different idea I had was to create a copy of AdvancedSearch and the four tabs, to be used only in the context of a single tiddler (although I haven’t delved into this idea much, because it’s probably not convenient or feasible)

Could you explain better how you would apply the idea based on resultCount? Looks interesting. I did some experiments on it but I didn’t understand it, so I can’t tell if it’s a good strategy

#4

Well, I was hoping to find something that distinguished the AdvancedSearch lists from the lists outside of AdvancedSearch that also use the same template (i.e $:/core/ui/ListItemTemplate) to display the title list items (for example sidebar > More > System also uses this template)

The idea is to use this distinguishing aspect as a qualifier for if the titles should also display my special thingy or not.

Skimming through $:/AdvancedSearch I was hoping to find some variable like is-in-advanced-search="$:/AdvancedSearch" or “is-a-tab-in-advanced-search=true” …but, of course, no such perfect variable exists there. I did however find that resultCount variable and AFAICT(!) this is only used for the various lists inside the AdvancedSearch tiddler. I guess it is only relevant to count the results in AdvancedSearch and nowhere else.

If you understand CSS: My initial strategy was to, inside my special {{||mod}} wrap the content with some style class, e.g <div class="foo"> ...</div> because the AdvancedSearch tiddler does uniquely wrap its contents with .tc-advanced-search so I could then target the non-AdvancedSearch contents and display:none. The problem is that in the inspector tool it seems that a div with display:none still exists so I figure it still calculates the contents of my {{||mod}} but just doesn’t display it, and this steals system resources. Just an amateurish guess.

Hope that clarifies it.

1 Like
#5

Now I understand it better, thank you. I will do some tests also with regard to the inspector tool. But I’m beginning to understand that I won’t be able to tell which strategy is best, that’s out of my reach

#6

I have addressed similar requirement’s in the past. The simplest and less intrusive is to clone $:/core/ui/AdvancedSearch/Filter creating a new tab, and modifying the caption (to tell them apart).

  • Then modifying the new tab to use a custom list item for the desired outcome.

However this common desire to alter the list item templates used in tiddlywiki has led me to starting this thread Making the list item template more hackable.

  • I already have a package of tiddlers modified to use an alternative list item template if provided.
  • I have support for the idea from @jeremyruston and others
  • So in your desired approach you would just clone $:/core/ui/ListItemTemplate
  • rename it $:/config/ListItemTemplate/AdvancedSearch/Filter and modify it as desired.

see my plans for

  • “Extended functionality”
  • and later in the thread;
    • Easy select from existing list item templates
      *Requires “list item template ‘tiddler standard’”
#7

Thanks, but I want the same different template for all the advanced search tabs, not just the Filter one. Anyway, I posted a proposal in your thread. Ironically, my proposal there does not solve the wish I have here for an all-in-one solution for all the Advanced tabs using my custom template. But my proposal there wouldn’t overwrite any core tids, which is my greater wish :slight_smile:

#8

Actually I noticed that in $:/core/ui/ListItemTemplate the variable <<currentTab>> is available if you are listing through any of the tabs in $:/AdvancedSearch so you could test for prefix[$:/core/ui/AdvancedSearch/]

  • This is somewhat of a hybrid between our two approaches.

This highlights that perhaps an additional cascade may be the best approach. I will see how hard it is to introduce.

1 Like
#9

Brilliant! I can even test if <currentTab>tag[$:/tags/AdvancedSearch] to ensure “per definition” that it is located there! Thanks Tony!

#10

Two minds are better than one, joint effort.

#11

hmm, A cascade for every list item may be heavy in terms of speed. Long lists are already problematic. Cascades can be expensive too, depending on the filter and how many of them are used. So a combination of those 2 mechanisms doesn’t look too promising.

Imo it could be compensated by using long lists with the event-catcher instead of the list-widget. … Which I think would be a welcome improvement for the core. … And if the core is changed the list-item handling could be improved there, which imo would benefit every user

#12

Actually @pmario here the cascade would determine the tiddler name to use as the list item template, not for every item so listed. That is the list widget would just provide the list item template obtained by a previous cascade.

  • This will only be as complex as the interventions someone adds
  • The default would be most commonly resolved