Yeah, I actually read your modification of the trac page after posting this :\
I guess what I'm getting at is the more general issue of maintaining the same interface... is it really that important? If people acknowledge that they are using a different system, then they can adjust their expectations accordingly. For example, this specific case of a decorator could be changed slightly so that the decorator is passed as a parameter to the url conf, or something like that. If the goal here is to be completely unsurprising and fit something into the existing system then I'll let the thread get back on topic :) I was just considering the possibility of actually providing another option which is a bit more of a radical change, but also doesn't involve some quicky ... tweaks.. On Sat, Oct 2, 2010 at 11:14 AM, Russell Keith-Magee <[email protected]> wrote: > On Saturday, October 2, 2010, David P. Novakovic > <[email protected]> wrote: >> My problem with all of this is that it feels like a hell of a lot of >> hoopjumping to deal with something that could be solved in the >> Resolver. >> >> I may be missing something obvious here, so please tell me if I am.. >> but couldn't the resolver just check that quacks like something >> OOViewish has been passed in and simply branch and init the class >> before calling the view in the same way it normally would? >> >> pseudo code follows: >> >> obj = None >> func = None >> if hasattr(view,something_an_ooview_has): #general ooview instance checking >> obj = view() >> func = view.dispatch >> else: >> func = view >> >> response = func(...) >> return response >> > > Sure. Now decorate the view. > > Decorating views in the urlconf is a very common and useful pattern, > but it's a pattern that is pretty much impossible using the approach > you describe. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
