A couple of months ago I asked pretty much the same question on this
list because I was doing the same thing. This is how we implemented
our system.
For starters, we rolled our own MVC framework. It's pretty much a
standard MVC framework, very rails inspired but much more lightweight
than Cake and with very strong support for ajax because we do a lot of
it.
We also decided to develop a large part of our functionality as
plugins. For example pagination is a plugin. You can just develop your
page and then paginate it pretty much as an afterthought by simply
including a plugin to which you pass your array of objects (we have an
ORM layer so we always deal with objects, not SQL) and the total
number.
Plugins are simply a folder in the plugins directory. This way the
framework can autoload them easily. If you have a Poll plugin you need
a PollPlugin class in the plugin/poll/classes directory. We also use
the savant3 template engine so from here you probably also want a few
templates to render your poll according to certain details. To display
a poll on a page all I have to do in the controller is this:
$poll = PollMapper::get()->findRandomBySite($ma->site());
$member = AFramework::framework()->user();
$poll_plugin = Plugin::load("poll",$poll, $member);
$ma->view()->assignRef("poll_plugin",$poll_plugin);
and in the view I simply class $this->poll_plugin->display(); and it
displays correctly at that location.
The interesting part there is the Plugin loader. Basically it's a
pseudo constructor. You give it a plugin name that you want to load
and any extra parameters (as many as you want) will be passed along to
the class' load method which serves as the pseudo constructor.
Since a poll object and a member object were passed to the poll
plugin, I can check whether this member has voted before of not. If
not, display() is going to return the p_poll_options template,
otherwise it will return the p_poll_results template. That's really
just some barebones html (a couple of divs with widths) that have a
default styling you can include (in the plugin's css folder) or that
you can override in the template that you're including's css.
I just mentioned that each plugin can have its own css but it can also
have its own images and javascript.
Anyway, this method has been working out extremely well for us. It
gives a lot of flexibility when you can just develop a self contained
piece of functionality and then just include it anywhere on any page.
If you make your plugins generic enough to handle anything (like
update lists that can take arrays of arbitrary object and just display
them correctly as a paginated list) you'll find this method works very
well.
On 8/7/07, Hamza Saglam <hamzasaglam@xxxxxxxxxxxxxx> wrote:
> ""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message
> news:7dd2dc0b0708061904i5578f8ewbe7ca511669f1dd5@xxxxxxxxxxxxxxxxx
> > On 8/6/07, Stut <stuttle@xxxxxxxxx> wrote:
> >>
> >> Hamza Saglam wrote:
> >> > Thanks for your response. However I am looking for something a bit more
> >> > comprehensive :)
> >> >
> >> > I could do it as you suggested if I had only a few plugins. As I am
> >> going to
> >> > add loads of plugins over the time, rather than adding all the plugins
> >> one
> >> > by one, could something like a 'loader' class be implemented? What I
> >> mean by
> >> > that is, it will take the requested plugin names (with their own
> >> parameters
> >> > necessary) and load/initialise them.
> >> >
> >> > In semi-psuedo-code, it would be something like:
> >> >
> >> > foreach plugin suplied as the argument
> >> > include the plugin
> >> > initialise it
> >> > end
> >> >
> >> > Perhaps I should change the question to: "Do you think something like
> >> this
> >> > would be efficient and useable? If not what sort of pattern would you
> >> > follow?"
> >>
> >> What you're describing is the Factory pattern, and yes that's the most
> >> efficient way to implement plugins. You should never load classes unless
> >> you need them - it's a complete waste of time, and definitely not
> >> recommended if you're going to have a lot of plugins.
> >>
> >> I would suggest you name your plugins X_plugin, Y_plugin and Z_plugin
> >> (where plugin could be anything) because that adds a level of security.
> >> Otherwise you could open yourself up to security issues because the user
> >> could instantiate any class in your system.
> >>
> >> -Stut
> >>
> >> --
> >> http://stut.net/
> >>
> >> > "Borokov Smith" <borokov@xxxxxxxxx> wrote in message
> >> > news:46B77B4B.9020600@xxxxxxxxxxxx
> >> >> Hey Hamza,
> >> >>
> >> >> require_once($chosenPlugin . '.class.php');
> >> >>
> >> >> $obj = new $chosenPlugin();
> >> >> return $obj;
> >> >>
> >> >> And you can start from there.
> >> >>
> >> >> hth,
> >> >>
> >> >> boro
> >> >>
> >> >>
> >> >>
> >> >> Hamza Saglam schreef:
> >> >>> Hello all,
> >> >>>
> >> >>> I am working on a project which needs to have some sort of plugins
> >> >>> architecture and I am kinda stuck. Basically I want to give a list of
> >> >>> items to the user, and according to his/her selection, I want to load
> >> >>> relevant functionality into my application.
> >> >>>
> >> >>>
> >> >>> I was thinking of having an abstract plugin class, and have the
> >> >>> plugins implement that but then how would I actually load the
> >> >>> plugins?
> >> >>> Say for instance I want to load plugins X,Y,Z (and lets say i
> >> >>> implemented them as [X|Y|Z].class.php) , should I just 'include' (or
> >> >>> require) them? Or should I initialize all possible plugins and just
> >> >>> pick the ones user has chosen (which sounds a bit pointless as it
> >> >>> would load unnecessary stuff)?
> >> >>>
> >> >>>
> >> >>> How would you go about doing something like this?
> >> >>>
> >> >>>
> >> >>> Thanks.
> >> >>>
> >> >>>
> >> >
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> > allow me to elaborate. you want to aim for composition as a flexible
> > alternative to sub-classing to extend behavior.
> > Namely what you want is the Strategy pattern. Strategy allows you to
> > compose objects at run time dynamically, thereby changing
> > behavior in your system on-the-fly. The components are made similar by a
> > common interface, which can be either the PHP
> > *interface* or the PHP *abstract class*.
> >
> > these components each encapsulate a different algorithm or module as you
> > would call it. and the interface makes the system simple
> > to extend. to create a new module you simply implement the interface and
> > it
> > is interchangeable with the other modules in the system.
> > the factory method pattern is sort of complex. it is used to encapsulate
> > object creation. it is typically used to instantiate objects in a
> > *family*
> > *of products* which is defined by a common interface, ie the strategy
> > pattern. the factory method is used to create products in a standard way.
> > factory method pattern goes further, in typical implementations, by using
> > template method in a parent class. this controls the boundaries
> > of the modules in the system.
> >
> > the template method invokes the a factory method on a subclass to get a
> > concrete object. it then operates on the the concrete object in a
> > predefined sequence. the abstract base class can define different types
> > of
> > methods. the base class may specify methods that must be
> > implemented by concrete subclasses. it can also expose hook methods, with
> > a
> > default implementation. these methods can be optionally
> > implemented in the subclasses.
> > after invoking the factory method to get a concrete object the factorys
> > template method will invoke the remaining methods, mandatory, hook
> > or otherwise on the newly created concrete object in a predefined sequence
> > before handing the new object to the client code that called it.
> >
> > http://www.phppatterns.com/docs/design/strategy_pattern
> > http://www.phppatterns.com/docs/design/the_factory_method
> >
> > -nathan
> >
>
> Hi Nathan,
>
> That all sounds quite interesting. I'll try to apply it when I'm coding my
> prototype :)
>
>
> Thanks a lot,
> Hamza.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
