[geeklog-devel] plugin_autoinstall - two more issues
joe at ThrowingDice.com
Wed Oct 7 10:42:22 EDT 2009
At 07:44 AM 10/7/2009, Randy Kolenko wrote:
> > Plugins should not modify tables they don't own. I don't know of any
> > plugins that do. You want to add info to a story or a forum post you
> > create a table with a sid or (whatever the forum primary key is) as a
> > foreign key and you maintain that table outside the main table.
>Really? How could the forum/stories/pluginx possibly use that data then
>if the newly insertted data is in a separate table? I'm not trying to
>sound snarky here -- just really trying to understand the approach.
I'm not getting this. If the data (from plugin X) was not put there
by the native plugin (forum, say) then how would the native plugin
know how to use that data.
Perhaps the disconnect is "modify". I mean adding fields to some
other plugin's tables. How would the plugin owning the modified table
be aware of how to use that data?
> > Now you want to add another file that is always included from the
> > functions.inc page rather than putting it in existing autoinstall
> > file. Does this scale?
>May not scale for Geeklog 1.6 -- but if its in its own file, 1.6.x could
>include the uninstall ONLY when on the plugins page when the uninstall
>is clicked. That scales.
If you really wanted scale, you'd do something about 3000 line
functions.inc files containing 70-80% unneeded code which take up
memory on every page load. Search functions would only be loaded when
search was active. Stats, profile editing, user create/destroy,
comment code, config change, etc. I wouldn't mandate file name
conventions for this. 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's great Joe. I looked at it and I simply asked a question as to if
>we used that approach, how can we manage external data. That is all.
>It was a valid question that I don't have an answer to yet. Perhaps its
>my lack of understanding on your approach so I asked for clarification.
You don't. The plugin author does by making another "type". When
autoinstall.php is loaded, it could contain a function such as
"INSTALLER_install_special_action". In the install array, the plugin
could have an entry of type "special_action". When the installer
reached that line of the array, it would look for a function called
INSTALLER_install_special_action and call it. The uninstaller (did I
mention that the library's uninstall uses the same array as the
install function uses to do the uninstall?) would attempt to call
INSTALLER_uninstall_special_action. Thus a plugin with special
requirements could supply the installer (and uninstaller) with
special functions to handle those requirements. The cool thing about
this setup is the INSTALLER function is passed the current array
being acted on as well as an array of "variables". These variables
are generated by the "group", "feature", etc
Throwing Dice Games
More information about the geeklog-devel