[geeklog-devel] plugin_autoinstall - two more issues

[Joe Mucchiello]

At 10:53 AM 10/7/2009, Randy Kolenko wrote:


> > Instead have a PLG_LoadFeature($feature,
> > $plugin = '') function that calls the plugin before attempting to
> > access that feature. If the plugin supports the feature (and dynamic
> > loading of the feature) it would load the functions needed at that
> > time. I admit I don't know if this really would improve anything. I
> > plan to test it out when I get the chance. It sounds good on
> > paper though.
>
>That is a good idea -- which is all predecated on refactoring the way
>plugins are written.
>Separation of logical functional units of code into their own
>dynamically linkable libraries would cut the parsed codebase down
>considerably.

The original idea was to do it at the load level. If you were on 
search.php it would define something to signal that search was 
needed. That idea is over a year old. But the PLG_loadFeature idea 
came out of this discussion and is more elegant I think. I figure you 
could remove just about everything from the functions.inc. Even 
"typically used" stuff like the usermenu block would be unneeded 
cruft in webservice call. Similarly, plugin authors would be 
encouraged to add features to their own plugins. The forums, for 
example, don't need to load the topic specific code (badges, smileys, 
the display code for a specific forum post, etc) unless those 
features are needed by the forums themselves. When viewing the 
calendar, those functions aren't needed.

So you end up with a bunch of subsections if you want to do it fully:

plugin: PLG_install, PLG_uninstall, PLG_upgrade, PLG_migrate, 
PLG_pluginStateChange
moderate: PLG_isModerator, PLG_getSubmissionCount, 
PLG_approveSubmissions, PLG_deleteSubmissions, etc.
submit: PLG_showSubmitForm
admin: PLG_getCCOptions, PLG_getAdminOptions, PLG_getIcon
comment: PLG_getCommentUrlId, PLG_commentDeleted, PLG_commentSave, etc.
stats: PLG_getPluginStats
search: PLG_getSearchTypes, PLG_supportsExtendedSearch, PLG_doSearch
user: PLG_createUser, PLG_deleteUser, PLG_loginUser, PLG_logoutUser
profile: PLG_userInfoChanged, PLG_profileVariableEdit, 
PLG_profileBlocksEdit, (and display) etc
content_filters: PLG_templateSetVars, PLG_collectTags, PLG_replaceTags
spam: PLG_checkForSpam, PLG_spamAction
item_filters: PLG_groupChanged, PLG_userInfoChanged, PLG_itemPreSave, 
PLG_itemSaved, PLG_itemDeleted, PLG_afterSaveSwitch
feeds: PLG_supportingFeeds, etc
blocks: PLG_getHeaderCode, PLG_getMenuItems, PLG_getWhatsNew, 
PLG_showCenterblock, PLG_getBlocks, PLG_getUserOptions
webservices: PLG_invokeServices, PLG_wsEnabled
config: PLG_configChange, PLG_getDocumentationUrl
tasks: PLG_runScheduledTasks
ping: PLG_handlePingComment

About the only thing I would leave in the functions.inc is 
plugin_checkversion_$plugin and plugin_loadfeature_$plugin. Now, I 
realize that is a lot of "features" but I think it is better to err 
on the side of too many features than too few. Yes, moderate and 
admin could easily be combined. But leave that for the plugin author 
to do if he wants. If the plugin author doesn't want create a whole 
file just for PLG_isModerator, that's his business. This is the kind 
of thing that should be profiled but will be hard to profile. If you 
can determine PLG_getHeaderCode is invoked on 99% of all page hits, 
then perhaps it should be left in functions.inc. I'm just laying out 
the idea. The devil is always in the details.

In general the features with just one or two functions should be the 
ones that only get called from one place: submit, search, stats. 
Putting them all into a single file won't be too detrimental but 
getting them out of functions.inc should be most beneficial.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com