Alex,
I'm trying to figure out the plugins. The code you sent helped a lot!
Conceptually, the plug-ins configuration has 4 areas?
1) menu - entries on the plug-ins admin menu
2) meta -- meta info/"about"
3) hooks -- list of connections
4) version -- (not really an area, just a version number)
5) user -- configuration variables --
My real question, is the configuration variables are passed via the $CFG hash? Is that how they are made available to the program?
If so, then module & plug-in conflicts are bound to occur.
Has some convention been developed to handle that?
Because the configuration variables all share the same namespace, some sort of convention has to be agreed because common things such as paths, colors or nams will start to conflict.
One way, I guess, would be to make a new CFG variable PLUGIN, which was a hash of hashes of configuration values. Because it's 2 dimentional, there should be no name-space conflicts, and authors would have to use $PLUGIN->{PluginName}{Key} to get to them.
Another way, is like some of the software development systems have, is to register a prefix for your mods, and all your mods use that as their reserved signature. In my case, it would be pugdog_ It would be relatively easy to trim off anything preceeding the first _ as the author prefix, if you needed to automatically generate "clean" names for the variables.
Right now, I'm still trying to figure out how the plug-ins plug in <G> but I can see that this sort of collision is bound to occur if some development and deployment rules are not used early on.
If a configuration space is going to be shared, like $CFG, even programs and modules from GT should try to adhere to some organizational convention such as Links_, GossMail_, Myman_ etc. That way, as integration occurs, <%db_cgi_url%> would be <%links_db_cgi_url%> or <%GM_db_cgi_url%> etc.
I may be missing something, but the prefix_ option, or the hash of hashes seem to be the only two really reasonable alternatives. When a module initializes, it looks for $PLUGINS->{ModuleName} and takes a slice of the hash with it's associated configuration parameters.
In reality, modules would _NOT_ share configuration variables, unless they knew about each other before hand, and in that case, they will follow certain rules (such as initializing if the $PLUGINS->{OtherModuleName} hash exists), but if the configuration options are being loaded at startup, and $CFG is global, then some separation of the various modules configurations parameters needs to exist, even if it's only relevant at initialization...
Am I making sense, or should I have gone to bed?? <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
I'm trying to figure out the plugins. The code you sent helped a lot!
Conceptually, the plug-ins configuration has 4 areas?
1) menu - entries on the plug-ins admin menu
2) meta -- meta info/"about"
3) hooks -- list of connections
4) version -- (not really an area, just a version number)
5) user -- configuration variables --
My real question, is the configuration variables are passed via the $CFG hash? Is that how they are made available to the program?
If so, then module & plug-in conflicts are bound to occur.
Has some convention been developed to handle that?
Because the configuration variables all share the same namespace, some sort of convention has to be agreed because common things such as paths, colors or nams will start to conflict.
One way, I guess, would be to make a new CFG variable PLUGIN, which was a hash of hashes of configuration values. Because it's 2 dimentional, there should be no name-space conflicts, and authors would have to use $PLUGIN->{PluginName}{Key} to get to them.
Another way, is like some of the software development systems have, is to register a prefix for your mods, and all your mods use that as their reserved signature. In my case, it would be pugdog_ It would be relatively easy to trim off anything preceeding the first _ as the author prefix, if you needed to automatically generate "clean" names for the variables.
Right now, I'm still trying to figure out how the plug-ins plug in <G> but I can see that this sort of collision is bound to occur if some development and deployment rules are not used early on.
If a configuration space is going to be shared, like $CFG, even programs and modules from GT should try to adhere to some organizational convention such as Links_, GossMail_, Myman_ etc. That way, as integration occurs, <%db_cgi_url%> would be <%links_db_cgi_url%> or <%GM_db_cgi_url%> etc.
I may be missing something, but the prefix_ option, or the hash of hashes seem to be the only two really reasonable alternatives. When a module initializes, it looks for $PLUGINS->{ModuleName} and takes a slice of the hash with it's associated configuration parameters.
In reality, modules would _NOT_ share configuration variables, unless they knew about each other before hand, and in that case, they will follow certain rules (such as initializing if the $PLUGINS->{OtherModuleName} hash exists), but if the configuration options are being loaded at startup, and $CFG is global, then some separation of the various modules configurations parameters needs to exist, even if it's only relevant at initialization...
Am I making sense, or should I have gone to bed?? <G>
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ