[geeklog-devel] plugin_autoinstall - two more issues

[Joe Mucchiello]

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


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