Garden

Views are used to define the main content of a page (ie. a list of discussions, a user profile, etc), but what about all of the other supplementary elements on a page? How does Garden handle adding buttons, menus, and all of the sundry elements that make any page complete? Modules.

Modules are extremely simple classes that have one purpose: return a string. That string can really be anything you want, but typically it will be a string of xhtml that is to be added to any of the asset containers defined in the master view.

Garden comes with a number of predefined modules, such as:

HeadModule: Allows the addition of tags to the head of the document, like link (css) tags, script tags, meta tags, etc.
MenuModule: Used to build a hierarchical menu that can then be manipulated to do a number of different tasks. For example, it is used for the main menu of Garden that includes hover-driven dropdown items, and it also is used for the main settings page as a sidebar menu.
EditInPlaceModule: Can be added to any page in the sidebars, header, or footer and allows administrators to put anything they want into that page by editing the content block in-place.

Before best open source forum began development on Garden, we spent a lot of time thinking about how to improve upon the plugin architecture adopted for Vanilla 1, and then I spent even more time doing test after test after test to see what really worked. In the end I realized that there can easily be more than one way to accomplish the task, so I’ve adopted a few standards, and I’ve left the code open to new methods of plugging in that some of you may decide to pursue. For now, I’ll talk about four different ways of plugging in.

1. Custom Events

Events are essentially what I mis-named as “delegation” in Vanilla 1. Any class that extends the class “Pluggable” has the ability to call $this->FireEvent('EventName'), and then plugins can attach to that event to perform some kind of operation. There should be no surprises here. There is a PluginManager class that picks up any defined plugins in the bootstrapper file (the file that includes core classes, defines constants, defines configuration settings, etc), and when the FireEvent method is called, it references the PluginManager class to see if there are any plugins that want to attach to the event name being fired.