On 7/1/05, David Zülke <[EMAIL PROTECTED]> wrote: > > About the changeset.. http://trac.agavi.org/trac.cgi/changeset/157 > > You should be able to instantiate the ExecutionFilter and initialize > > it, the same as is done with the security filter and it wouldnt be > > misleading as I would expect $this->executionFilter to be the actual > > object. > > I can rename the variable if you like. However, I don't want to use one > instance for all filters. It used to be > > $execFilter = new ExecutionFilter(); > And would now be > $execFilter = new $this->executionFilterClass(); > > I think this might have a reason. And I can imagine situations where people > with CustomExecutionFilters would need separate instances for every call. > I'm sure there is a reason why Sean back then decided to use a new instance > each time, so why should we change that?
I think the reasoning was that it wasnt configurable and there were many conditions that would have prevented reaching the execution filter so it was held off until it was actually required, no reason carrying around baggage you may not need. I'm ok with it working either way though, as long as the variables are more descriptive of their contents. I was thinking maybe it'd be better to not -require- the specification of the execution filter and fall back on the old std, but that's not consistent with everything else and if we do things like that here we should do it everywhere and I'm not so sure I like the sound of that. So if you wanna rename the variables to something else like you suggested I'm ok with that. Also, as I mentioned before, agavi.org runs a cron that keeps itself in sync with trunk. :) I've already added the execution_filter to the factories.ini, in preparation with a potential merge this weekend, though. -Mike _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
