Upgrading and extending VuFind should be easier – especially when it comes time to upgrade to a new version. If we are going to significantly overhaul the VuFind code for a 2.0 release, building a new architecture that makes extensibility cleaner and easier should be a high priority.

VuFind currently has several different types of plug-ins (authentication mechanisms, record drivers, ILS drivers, etc., etc.). The concept of theme inheritance is also somewhat related. Where they exist, these mechanisms are useful and powerful, but different mechanisms do not always work in totally consistent ways, and there is not a strong separation between local custom content/configuration and the distributed VuFind core.

Feel free to add to this section – the idea is currently to list possible solutions and evaluate advantages and disadvantages.

Since VuFind's initial release, many frameworks have appeared which simplify the construction of a web application. We should look at these and see if any would be suitable for VuFind. This feature comparison chart in Wikipedia may be helpful.

This one is relatively lightweight and seems like a good candidate if we are also interested in making use of Maven.

Another popular lightweight framework, available here.

This project advertises itself as both a CMS and an application framework. The CMS element might be a nice bonus feature, but at the same time, tying VuFind to a particular CMS might become an obstacle to adoption (the same argument goes for Drupal).

Kohana is a PHP framework similar in many ways to Ruby on Rails.

Obviously, VuFind is going to remain a PHP-based project; if you want discovery on Rails, Blacklight has that territory well covered, and Rails' very heavy dependence on naming conventions would make migration from existing legacy VuFind code unnecessarily complicated. However, it's not a bad idea to borrow some design principles from Rails. Here are a couple of ideas that might be helpful to VuFind:

• Render shared page layouts AFTER action-specific page contents – this way you can pass page-specific details (like title tag contents) from template to template rather than having to embed it in the controller.
• Share the URL routing logic with the templates so that the same logic which resolves incoming requests can also be used to build outgoing links.

(feel free to expand this list if you have strong feelings about any other Rails conventions)

Smarty templates are not as popular as they once were, though they may still serve some useful functions within the library environment. We should consider alternatives, especially if it helps make VuFind development less complex and more consistent.

PHP 6 is going to introduce namespace support – might this be helpful for differentiating between VuFind core and local modifications in a straightforward, unambiguous way?

As of 4/8/11, these are Demian's thoughts on reasonable goals for the redesign. These presume certain answers to some of the questions above. It's all still negotiable, so feel free to add comments.

• Maintain existing URL routes for compatibility, while potentially offering improved alternative routes
• Maintain compatibility with existing configuration files (either directly or via an upgrade script)
• Replace existing controller model with something more flexible (for example, well-designed context switching would be helpful for providing alternate API-style views)
• Replace Smarty views with something PHP-based
• Reduce external dependencies on obsolete code (i.e. deprecated PEAR libraries)
• Make file organization and class naming more consistent (i.e. sort out the current web/sys quagmire)
• Ensure that everything (models, views, controllers, routes, configurations) can be extended/overridden outside of the core for easy upgrading