Page 2 of 2
Posted: Wed Feb 07, 2007 3:06 pm
by feyd
What about the filter knowing which modules it overrides? While that does add work for you if you want more overrides, it is in a centralized location that is fairly simple to find.
Posted: Wed Feb 07, 2007 3:13 pm
by Ambush Commander
You mean instead of disableFilter($filtername) you say disableFiltersOfModule($modulename)?
Posted: Wed Feb 07, 2007 3:20 pm
by feyd
Potentially. There are many ways one could go. It could be a query point for the manager to interrogate the filter for example.
Posted: Wed Feb 07, 2007 4:04 pm
by Ambush Commander
Not sure what you mean. What would one example be, showing a use-case with the least overhead for a simple "add filter, don't care about overriding others"?
Posted: Wed Feb 07, 2007 4:59 pm
by wei
May be an observer on the add/remove method of the manager can be used to disable/enable particular filters, this leaves the Filter itself simple, and delegate the task of complex filter list manager to another class thus providing reuse as well.
Posted: Wed Feb 07, 2007 8:08 pm
by Ambush Commander
I've rethought my situation and I've decided that a filter manager, for now, is complete and utter overkill but can be added in later with very little pain (the old "API" would still be available, just without any cool features). I don't plan on fostering a bustling "mod community", so any conflicts from user-space extensions will have to be dealt with by those individuals.
I'll keep in mind these ideas for other situations, though.