[Solar-talk] Model helpers

[Rodrigo Moraes]

On 9/6/07, Jeff Surgeson wrote:
> Sounds like a good idea to me, definitely something I would use!

That's cool. :) Several of us agreed already that plugins would be
worth in several places, and I think the base MVC classes in Solar
should support them. Meaning: we already have helpers in View; now we
need them in Controller and Model. :)

And, after some talks with Paul on IRC, some time ago I created a base
class for helpers (or you may call them "plugins" [1]), that can be
used:

1. as a base class (versus extending Solar_Base) for classes that need
some kind of shared helpers loaded according to the context. I
followed a suggestion by Paul; initially I only thought to use it as
an standalone plugin manager, as described in 2:

2. as a base class for standalone plugin managers. It can be set as a
property/dependency for classes that need to share a helper system,
rather than initialize their own on construction.

The base class is here:

    http://dev.tipos.org/browser/trunk/Tipos/Base/Plugin.php

And there are some points I would like to explain:

* instead of a single class stack, it has an array of keyed stacks,
and uses the 'main' key by default in case no one is specified. It is
very transparent and allows a class to have several stacks, for
several purposes. If just one stack is necessary, just ignore the
extra parameter that defines it, and it will use the 'main' stack.

The above idea means that this class can be used by
Solar_Controller_Page or Solar_View to manage several stacks, but also
allows that users set their own app-related stacks for different
purposes, with no additional methods or properties.

* newPlugin() is an abstract method which should be implemented by the
extended class.

As an example implementation of "multiple stacks", I extended the
Model helper idea to support plugins for models, collections or
records, using just one class that extends Tipos_Base_Plugin:

    http://dev.tipos.org/browser/trunk/Tipos/Sql/Model/Plugin.php

It creates a stack dynamically only if a plugin is requested, and uses
the proper stack for models, collections or records. And since with
different stacks you may need to use different strategies for
instantiate the plugin, you are free to do implement anything you need
in newPlugin(), switching according to the stack key that is
requested.

Note that the model class doesn't extend the base plugin class;
instead, it uses the "plugin manager" object (Tipos_Sql_Model_Plugin)
as a dependency, and calls it only if a plugin is requested
(implementation #2, as described in the beginning of this e-mail). See
how it is done in the plugin() method, in the end of this class:

    http://dev.tipos.org/browser/trunk/Tipos/Sql/Model.php

In short words, the base plugin class is useful to:

a. be used as a base class for plugable objects
b. be used as a standalone plugin manager
c. manage multiple stacks

I'm excited about this whole idea; I think its adds a lot of
flexibility and power to Solar, and honestly but humbly I think it
revolutionizes the base MVC a bit, allowing us to, more easily and in
a modular way, share pieces of code and functionality that were before
attached to our apps, models etc. Not only we can reuse pieces within
our code, but also we can borrow plugins from other Solar projects -
so it stimulates collaboration too. :D

let me now your thoughts! :)

cheers,
rodrigo

[1] http://martinfowler.com/eaaCatalog/plugin.html