continuing work on port of cakephp 1.3 app 3.0, , have run issue. have number of areas functionality varies based on settings, , have used modular component approach. example, leagues can have round-robin, ladder or tournament scheduling. impacts on scheduling algorithm itself, such there different settings required configure each type, dictates way standings rendered, ties broken, etc. (this 1 of 10 areas have similar, though not of these suffer problem below.)
my solution in past create leaguecomponent base implementation, , extend class leagueroundrobincomponent, leagueladdercomponent , leaguetournamentcomponent. when controllers need algorithm-specific, check schedule_type field in leagues table, create appropriate component, , call functions in it. still works fine.
i mentioned affects views. old solution pass league component object controller view via $this->set. view can query various functionality. admittedly bit kludgy, obvious alternative seems extracting info view might require , setting individually, doesn't seem me lot better. if there's better option, i'm open it, i'm not overly concerned @ moment.
the problem i've encountered when tables need of component info. issue @ hand when saving add/edit form , need deal custom settings. in order flexible possible future, don't have of these possible setting fields represented in database, rather serialize them single "custom" column. (reading works quite nicely custom constructor , getters.) had done loading component beforesave function in league model, calling function returns list of schedule-specific settings, extracting values , serializing them. changes component access in 3.0, seems can no longer create component in new beforemarshal function.
i suppose controller "pass" component table setting property, feels major kludge, , there must better way. doesn't seem extending table class solution, because horribly complicate associations. don't think custom types solution, don't see how they'd access component either. i'm leaning towards passing list of fields controller model, that's more of "configuration" method. speaking of configuration, suppose go central configure data store, that's felt me somewhere put "small" data. i'm wondering if there's better design pattern follow let table continue take care of these implementation details on own without controller needing involved; if @ point decide change serialized method adding of possible columns, nice have changes restricted table class.
oh, , keep in mind list of custom settings needed in both view , table, whatever solution proposed ideally provide way both of them access it, rather requiring duplication of code.
Comments
Post a Comment