On Mon, 2007-10-29 at 15:52 -0500, [EMAIL PROTECTED] wrote: > Why not just store promos in the database and have a static controller > that > acts on active promos? No changing application code for the promo. > easy > to do future promos too as you can have an epoch start and end time > for the > promo in the db tables that the controller takes into account.
This is actually how it works - I have a generic Promotions controller that looks them up from the db and applies date filtering, but it "proxies" action calls to a first-class controller for a given promotion if a corresponding controller exists. So, if I have a promotion with a defined moniker of 'MidnightMadness' and a Controller::Promotions::MidnightMadness exists, then action calls get proxied to this controller. Because of this particular client's needs there is no way to pigeon hole promotions into a standard set of code. Sometimes they want "this", sometimes they want "that". So, I still need to have a first-class controller for a given promotion. This is why I did the hooks - I can have a generic interface where any promotion can manipulate the stash. The big caveat is that I have to define the places where I want hooks and over time they could get messy. Thanks for the input. -- Matthew W. Pitts Software Engineer [EMAIL PROTECTED] 336.202.3913 (mobile) A3 IT Solutions, LLC www.a3its.com _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
