[wp-hackers] Plugin dependency checking

[scribu]

About validating interfaces, it dawned on me that the simples way
would be to simply act like a consumer of that interface. For example:

define_interface('My Interface', '1.0', array(
  'constants' => array('FOO_CONST'),
  'classes' => array('foo_class', 'bar_class')
);

----------
// validating interface 'My Interface':

foreach ( $interface('classes') as $class )



On 6/18/09, scribu <scribu at gmail.com> wrote:
>> Development mode would be disabled by default but enabled in a new admin
>> menu in the Settings area called (something like) "Developer Options" or
>> "Deployment Options" or maybe just "Development" or "Deployment."  (This
>> menu could also enable a move to support something I'd love to see:
>> optionally different databases for development/test/staging/deployment ala
>> Rails.)
>
> I think this would be more readily transformed into a new constant in
> wp-config, like PLUGIN_DEBUG.
>
> On 6/18/09, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>> On Jun 17, 2009, at 3:49 PM, scribu wrote:
>>> On 6/17/09, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>>>> -- Ability to validate during development that a plugin that
>>>> implements an interface has done so correctly
>>>> -- Ability to extract documentation for a plugin author
>>>
>>> How do you propose we achieve these two points? You said yourself that
>>> lines like do_action("foo_$bar") would cause problems.
>>
>>
>> Great questions!
>>
>> To answer let me overview the process I'm envisioning using details
>> that are fully open for collaborative improvement.
>>
>> When a plugin is *activated* WP core would inspect its header to
>> determine its interfaces and then retrieve its interfaces either via
>> web service or as defined locally if the web service is unavailable
>> and it would add the interfaces to a new global $wp_interfaces.  WP
>> core would then crawl the interfaces and would order the plugins in
>> dependency order for the 'active_plugins' option in the wp_options
>> table. WP core would also serialize $wp_interfaces to the wp_options
>> table.
>>
>> When a URL is requested in "normal mode" the code at line 538 of wp-
>> settings.php in v2.8 would use the 'active_plugins' option to load
>> plugins as it currently does, but now in dependency order.
>>
>> However, when a URL is requested in "development mode" the same code
>> at line 538 of wp-settings.php in v2.8 would use the unserialized
>> $wp_interfaces to validate the 'active_plugins' against their
>> interfaces. I'm thinking this should only require one test of a global
>> variable, maybe $wp_development_mode==true
>>
>> In addition apply_filters() and do_action() would validate the
>> dynamically defined hooks, but only when in development mode.
>> Validation could also be cached so that the core wouldn't repeatedly
>> validate the same thing to speed page load during development mode.
>> apply_filters() and do_action() could even be made to be pluggable so
>> that the test for development mode could be made only once, not each
>> time thru the loops.
>>
>> Development mode would be disabled by default but enabled in a new
>> admin menu in the Settings area called (something like) "Developer
>> Options" or "Deployment Options" or maybe just "Development" or
>> "Deployment."  (This menu could also enable a move to support
>> something I'd love to see: optionally different databases for
>> development/test/staging/deployment ala Rails.)
>>
>> For normal page loads this new system of interfaces would have also
>> practically zero footprint and no unmeasurable performance impact.  It
>> would only affect performance during plugin activation and when in
>> "development mode."
>>
>> As for documentation, that would be easy.  There could be a text link
>> to a plugin/interfaces documentation page on the Developer Options
>> menu page. That documentation page would simply format the information
>> in $wp_interfaces for visual display to the end user.
>>
>> Once again let me stress everything proposed is *optional*, and would
>> only need be used by those who want add the additional support to
>> their plugins. What's more it could also be architected in such a way
>> that someone could add interface definitions for plugins that have not
>> opted to include interface information in their theme allowing the
>> WordPress developer full control over his site implementation.
>>
>> Does this answer your concerns?
>>
>> -Mike Schinkel
>> WordPress Custom Plugins
>> http://mikeschinkel.com/custom-wordpress-plugins/
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
>
> --
> http://scribu.net
>


-- 
http://scribu.net