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

On samedi 8 avril 2023 10 h 01 min 41 s EDT Volker Wysk wrote:
> Am Montag, dem 03.04.2023 um 18:16 -0400 schrieb Benoit Grégoire:
> > > Here is my thought:
> > > - Add an option to each plugin (searchable="y|n"). Give the value
> > > searchable="y" to all the plugins that we want to index by default.
> > 
> > Please don't call it searchable, that was the name of the future
> > "searchable"
> > parameter in plugin syntax params, which is NOT the same thing.
> 
> I don't find it confusing. Anyway, what about "searchable_by_default"?

You wouldn't  find it confusing that the plugin would receive:

1- A Boolean configuration parameter at the top level of the plugin info array that 
determines if the plugin is indexed, barring any other configuration.  The one Adrien is 
about to code.  
Called "searchable" in your scenario.

2- An object parameter one level down in the plugin info array (in "params") that 
documents the usage and default values of a parameter
Called "searchable" in your scenario.   But NOT documenting the parameter above.

3- The actual value of the parameter, in the $params argument of the main function, 
possibly empty, representing if the page author wants the output of that indexed for that 
specific plugin instance.  Not the one Adrien is about to code.
In your scenario also called "searchable"

?  Maybe you wouldn't find it confusing, but I would think there is only one parameter 
who's value I have to deal with!  And on the oft chance I notice or remember there is two, 
I'd have a hard time figuring out which one of the two  "params/searchable" is 
documenting/setting defaults for.

> This sure is confusing. But we don't need all this, when we introduce the
> "searchable" (or "searchable_by_default") setting for the plugin info
> functions. We only need two settings which override the defaults. Perhaps
> call them "include_plugins" and "exclude_plugins". Or "include_in_search"
> and "exclude_from_search". Or whatever.

When I'd read "include_in_search" I'd think that everything in the list will always be 
included.  At the very least, I'd think that it works the same way as exclude_from_search.  
Neither is the case here, but since in the early implementations it would effectively be, it 
would create even more confusion or incorrect expectations in the future!


So since the two of you seem to like searchable in every name, I propose:

1- Add "searchable_by_default" (name of a plugin info array key).  Default indexable value 
for that type of plugin.

2- Add "searchable" (name of a plugin syntax parameter representing the desired 
indexability of a plugin instance) and "params/searchable" (plugin info array key path that 
contains it's documentation/defaults).  Adrien can ignore that for now (probably I'll be the 
one coding it).

3- Keep but modify "unified_included_plugins" (name of a pref)  We can't change it's name 
without throwing away people's currently working list of indexed plugins, unless 
someone volunteers to write a migration.)  Makes all plugins in the list act as if 
searchable_by_default was true.  We can name it's effective value something different 
inside the code (such as  unified_additional_default_searchable_plugins), but there is no 
need to agree on it here.

4- Keep unified_excluded_plugins  (name of a pref)  We keep that one, it prevents plugins 
from being indexed no matter the parameters of searchable_by_default, searchable, OR 
unified_included_plugins.  We need this to globally disable plugins that prevent the 
indexing process from finishing or otherwise damage the index, without destroying user 
configuration for when a plugin is removed from the list.

None of this is academic.  It should be pretty obvious that an author may want:
- To exclude a plugin (such as PluginDiv...) in one place, but include another PluginDiv it in 
another place, on the same page.
- To include the results of computations  (such as a specific instance of PluginList), but 
never all of them by default!

-- 
Benoit Grégoire

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