views:

159

answers:

1

I'm building a Zend-based Web app that will permit third-party extensions.

Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.

Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.

Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.

I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."

Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.

From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).

So two questions:

  • What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).

  • What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.

+2  A: 

I'd implement the Visitor Pattern for this.

Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.

Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).

As for how to register it, check out the Zend_Application framework for defining resource plugins.

Bill Karwin