Re: [Tiki-devel] A default for the list of plugins, whose bodies should be indexed

On vendredi 13 janvier 2023 07 h 33 min 10 s EST Jonny Bradley via TikiWiki-devel wrote:
> Hi Benoit, Volker and all
> 
> That's some pretty impressive feature creep, i was going to just add that list:

Well, that's a good reason to talk about it ;)  To me at least:

- Even having a global "Include plugins" and "Exclude plugins" in preferences is kind of 
feature creep, because I can't see a case where it's the clear and logical answer to any 
user's need (To illustrate: when is the answer to "Should this be indexed" be "because it's 
been affected in some unknowable way by PluginDiv").  It's not even a list of defaults, it's 
an all-or-nothing thing!

- Having default indexing behavior by plugin is clearly not feature creep (Clearly this 
thread struck a nerve...).  

- A specifier at the syntax level is not either, for multiple reasons (PluginList probably 
being the best example, hard to imagine a non-trivial site that NEVER  doesn't want to 
index anything, or one that ALWAYS wants to index everything.  It wouldn't be urgent if 
only a handful of plugin initially support it, except for the fact that without it effort is more 
likely to be sunk into the global, class based list.

> One issue i foresee is nested plugins, what if you have a non-indexed plugin
> containing an indexed one? Plugin code rapidly gets quite complex
> sometimes.

The  nested indexed one wouldn't get indexed (for usability reasons I outlined previously, 
but may be wrong on).  Plus it's significantly simpler to implement that way, and has 
performance benefits.

> Also, we still don't have a default/abstract class for all plugins, part of
> Project Fluffy which has never properly got off the ground
> (https://dev.tiki.org/Project-Fluffy - very stale experimental branch here
> https://gitlab.com/jonnybradley/tiki/-/tree/project-fluffy-2) This would
> make handling of common parameters that all plugin share more manageable i
> think...
> 
> However, we can always interpret `! isset($param['searchable'])` as meaning
> 'n' when parsing/indexing the plugin so maybe we can aim to do this for
> 26.x and even maybe 25.1 or 2?

Ah, I see, we don't have a clear place for this common handling to live and be 
manipulated yet.

I haven't played with the plugin processing code at all.  But having a plugin class that 
initially handles just the default indexing behaviour and one custom syntax parameter 
(the "searchable" override), just for Plugins that implement it seems to lead itself really 
well to the strangler pattern.  

It's clearly bounded, already add significant value, wouldn't hurt anything for other 
plugins, and porting most of the display plugins Volker mentioned would be trivial as they 
basically wouldn't do anything different except be ported to the new class.

Looking at project fluffy, it's clear that the need for an abstraction won't go away.  May as 
well start somewhere.

As I'm going to work in indexing related stuff in the near future, I definitely volunteer to 
help...  

-- 
Benoit Grégoire

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel