Alex,

What changed with the plug ins?

I really don't want to lose another weekend, so I need to go with what is out there now.

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Sorry, I didn't get the docs as finished as I want. The main change is what plugin hooks return. There is no change if you aren't using hooks, but any function that is a hook needs to get updated.

You should have:

use GT::Plugins qw/STOP CONTINUE/;

and then if your plugin wants to STOP and not run other hooks or the main code, you call:

GT::Plugins->action ( STOP );

The main difference is what is returned. For PRE hooks, you must return the same argument you got passed in. For instance in YahooSubcats, you get passed in an array ref of subcats. You can modify it to suits your need, but must return it. Whatever you returned gets passed in to the regular code.

For POST hooks, you must also return what you get passed in. For example, the SearchLogger gets passed in a hash ref of data that will go to the search_results template. It can modify, add new tags, etc, but it must return that hash ref so search_results can do the proper thing.

This was different in beta 5, where plugins returned STOP or CONTINUE to signal what was going to happen. We made this change as we developed more plugins, as it was to limiting the way it was setup.

Hope this helps explain things, let me know if you have any questions..

Cheers,

Alex

--
Gossamer Threads Inc.

This STOP/CONTINUE action is only checked on function return -- it can be called at any point, and a single function can return either STOP or CONTINUE based on what happened within it? ie: The last value set into GT::Plugins->action ( STOP ); is what is checked on return. It's not a 'return' or 'exit' in and of itself?


PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Hi,

Functions that are hooks now must return whatever they get passed in. They signal Links SQL if they don't want the main code to be run by calling:

GT::Plugins->action ( STOP );

However, the return from hooks, must always be what was passed in (although it can be modified).

Cheers,

Alex

--
Gossamer Threads Inc.

Ok,

I think we are saying the samething, but something is still missing.

1) the subroutine sets STOP or CONTINUE somewhere in it, and returns what was passed in, as well as setting the STOP or CONTINUE flag.

2) the return values from that subroutine are checked by the dispatch, and if STOP, execution stops at that point, and returns to where the hook was initially called (the line after the plug_in dispatch call). No further plug-ins or main code is executed after a "STOP"

3) if CONTINUE is set, then the next plug-in or main code is executed.

Ok..

On a pre-hook, if STOP is called, the main code ie:what was hooked (such as add_modify_form) will not be called. Neither will any further pre-hooks be run.

What about post-hooks? STOP in a pre-hook prevents any post- hooks from running either?

On a post-hook, STOP just prevents further plug-in processing?


Also, if every plugin is registered as "FIRST" there is no way to really know what order things are being called in.

So, it's of tantamount importance that each plug-in behave by the book, and not return values that could crunch or overwrite an other plugins functioning....

Eeek.

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Hi,

The default behaviour is to continue, so you only need to set STOP if you want to stop further processing. STOP in a pre-hook just stops the main code, post hooks will still be processed. You should add a post hook as well if you want to prevent other post hooks.

There will be plugin incompatibilities, that's inevitable. Also, I do plan to add the ability for users to change the order in which plugins are run.

But yes, plugins must return the proper value. Not so much because of other plugins, but because the main code is depending on having that value their. So if search_results is expecting a hash ref, and your plugin returns a scalar, boom it will fatal on you.

Cheers,

Alex

--
Gossamer Threads Inc.

Did anything change with the Install.pm ?? (besides the headers)

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

No, no changes to the installation.

Cheers,

Alex

--
Gossamer Threads Inc.