[geeklog-devel] Configuration tooltips

[Tom]

Hmmmm, I am just thinking out loud here.

PLG_getConfigTooltip is a clean way to do it (and we can incorporate using
COM_Tooltip) and it still allows core to use the hack though it means
another plugin API and potential duplication of documentation for plugins
(ie the language files and a document file, Wiki page, etc..). Plus it is
backwards compatible meaning if it doesn't exist we can fall back to
PLG_getDocumentationUrl  

Adding a new document type to PLG_getDocumentationUrl  like I suggested
would work as well though I am not sure how many plugin developers would use
it.

Looking at your code again I just realized we could just scrap
PLG_getConfigTooltip and the configuration could just look to see if the
language array exists and if it does then it can use the data from it.

Tom




-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello
Sent: April-05-11 11:08 PM
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Configuration tooltips

Would it be so hard to not make a new API PLG_getConfigTooltip($plugin, $id)
that calls plugin_configtooltop_[plugin]($id) and let plugins handle this
any way they want? Move the "hack" into an internal function used by core
and whatever else wants to use the hack and have a clean implementation
going forward. Most plugins would end up looking like this:

function plugin_configtooltip_foo($id)
{   global $LANG_MYTOOLTIPS;
    if (array_key_exists($id, $LANG_MYTOOLTIPS)) return
$LANG_MYTOOLTIPS[$id]; 
    return false;
}

Create a CFG_GetTooltipFromHelp($file, $id) function to put the hack into
and let core, calendar, links and polls use that function if they want to.
(Core would call it from within PLG_getConfigTooltip, of course.)

  Joe

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel