On Wed, Nov 18, 2009 at 9:17 AM, Evan Prodromou <[email protected]> wrote:
> jim sloan wrote: > > that functionality does not require the complexity of the nested if > statements. > > Are we looking at the same V-shaped 15-line block of code, Jim? :-) > > I'm just making a case that it could be more linear. > > 1. get the user if nickname exists > 2. if plugin finds user via an alias or email then it will return the user > object > > The whole point of this kind of structure is that plugins can augment > *or*replace the default processing. The more of the "default processing" we > get > between Event::handle() calls, the more that plugins can do. > If you wait until after the Event to load the user object then the plugins will not have an opportunity to use any of the profile data. also; why wait until after the Event fires to check for empty passwords? > If it's really sticking in your craw I'll make those three internal if's > into one if. > I thought that the original flow was clean and very flexible. All you need to do is to add the Events to the flow. see my post from last June http://lists.status.net/pipermail/statusnet-dev/2009-June/001499.html ~jim > > -Evan > > -- > Evan Prodromou > CEO, StatusNet, [email protected] - http://identi.ca/evan - +1-514-554-3826 > >
_______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
