Hi,

You are missing the bug :)

It's not a common naming convention that is the problem.

A "hook" is a subroutine name. Lower casing all your subroutine names is a problem, especially if there is no warning.

What about routines that are: _get_data and _GET_data, the difference between the big and little get makes sense, but the plugin installer will treat both routines the same, whichever it finds first.

Now, that really isn't much of an issue in general, until you get to the display routines.

'site_html_*' auto generates a subroutine call (which then looks for a template named whatever the '*' is).

So, if you have a template "MyDataDisplay.html", and you make a call to it in your scripts, :

print $IN->header();
print Links::SiteHTML::display ('MyDataDisplay', $results);

When you enter the plugin dispatch call of the SiteHTML module, the generated call would be:

'site_html_MyDataDisplay', but the "hook" has been renamed "site_html_mydatadisplay" during the install, so plugin dispatch will not find a valid "hook" to run. No error is generated, since not fnding a hook to run is a normal state (although an error in this case).

The _converse_,

print $IN->header();
print Links::SiteHTML::display ('mydatadisplay', $results);

will trigger plugin dispatch (I'm pretty sure) but will then bomb and return an error, because there is no template named "mydatadisplay.html" (on Unix systems).

I've been trying to visualize the process, and see how lower casing the 'hooks' can solve some problems, but since Unix and perl are case sensitive languages, and all subroutines will be called with their proper names, I don't understand why this is happening, or why this would be a benefit.

The display hook with "site_html_*" may be the only problem, but it's still a logic 'bug'.



PUGDOG® Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin