Rewrite Plan

Lately, time has been spent refactoring sections of the TigerEvents code due to initial poor design choices, or unforseen requirements/needs. While refactoring the database is not much of a problem, due to the fancy Migrations, making corresponding changes to the controllers (and views) is proving to be problematic, especially due to the fact that we have no unit tests.

As a result, we are planning to rewrite most of the code from scratch. Some of the current code can still be used as is, but we feel it will be preferable to redo several sections from scratch, learn some new things, rewrite with flexibility in mind, and have cleaner code.

Current Deficiencies

• Events format can be unwieldy at times. For example, refer to ticket #385.
• Lack of syndication for those who know what it is/want it. Refer to tickets #386, #234, #235, #388, #370, #167.
• i18n (see #165)
• Certain functions are not generic enough for proper reuse. For example, the auditing code for objects, which currently only does events. Refer to ticket #344.
• The above also probably applies to tagging. Refer to ticket #380
• Certain functions are fairly ugly complicated and no one likes modifying them if at all possible. ie/ Selectors
• Several views actually use repeated information, which can be better abstracted into partials.
• Many of the view can be further abstracted into general content generation views (as partials) and layouting views (assemblies of partials).
• Several views have actually logic defined in them. Most of this properly belongs in helpers, which also allows for better code reuse.
• Better integration with Javascript driven interaction (RJS/script.aculo.us/Behaviour).
• Fine-grained RBAC to controllers, actions and models.

Potential Plugins For Usage

• acts_as_authenticated
• acts_as_taggable
• acts_as_paranoid
• validates_date_time

New Things To Play With

• PostgreSQL
• Capistrano (For Deployment)