Gossamer Forum
Quote Reply
Install.pm bug --
Alex,

It seems that when Install.pm is run, it lower cases all the "hooks".

So, my hook site_html_Multi_attach becomes site_html_multi_attach.

This doesn't generate an error.... but it also never gets called. I've had to manually edit the plugin.cfg, and I thought I had not updated the Install.pm, but I have.

This seems that it would run into a problem if a person had two routines
with the same name, but different case.

If this is a bug, it could be why I've felt like I'm chasing my tail on some things.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
Quote Reply
Re: Install.pm bug -- In reply to
G'Day,

I have to disagree with you here. I'm always in favour of keeping a common naming theme throughout a program. If all the current hooks are lower case, then I would have to strongly suggest that you keep your new ones in lower case.

There is nothing more annoying then using a script where all the variables have the screwiest names. I think it is supposed to be a feature, not a bug. Anyway, wait and see what Alex says - but I think keeping a common naming convention would be the best approach.

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/
Quote Reply
Re: Install.pm bug -- In reply to
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
Quote Reply
Re: Install.pm bug -- In reply to
OK then,

I missed the point of the post :)

Discuss webhosting at
The Webhost Area Forums!
http://www.webhostarea.com/forums/