convore.json/groups/django-community/django-13s-get_context_data/messages.json

[{"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305298784.212188, "message": "if they just added their stuff to a .context_data attribute, we'd have shinier flowers.", "group_id": 81, "id": 1042504}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305298869.2942729, "message": "what's your opinion about this? I want to fill a feature request, but I want to be sure if my argument is solid enough.", "group_id": 81, "id": 1042525}, {"user_id": 960, "stars": [{"date_created": 1305303331.6206319, "user_id": 141}], "topic_id": 35138, "date_created": 1305299756.167094, "message": "Which one wins if they're both interacting with `.context_data` though?", "group_id": 81, "id": 1042797}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305298749.5095811, "message": "for example, if I want to include a form in a DetailView -- the form isn't related to the object --, I would compose my view with DetailView and FormView; but then the 'form' context variable wouldn't be exposed because both these classes have their .get_context_data.", "group_id": 81, "id": 1042495}, {"user_id": 21387, "stars": [{"date_created": 1305298233.9867311, "user_id": 960}], "topic_id": 35138, "date_created": 1305298055.914048, "message": "I've been playing a lot with new Django's class-based views and the only thing I can't agree is the way that the template context is extended. IMO, the context should be accessible by a .context_data attribute instead of a method call, because, due to the MRO sometimes, some stuff may just disappear.", "group_id": 81, "id": 1042295}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305303697.080132, "message": "namely shouldn't each class combine their context data with the result of a super() call? then the whole MRO is walked. it should be effectively the same as filling a property, but the dict is passed as a return value instead of sticking in the view's __dict__.", "group_id": 81, "id": 1043651}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305303754.7306881, "message": "if django's own views don't do that, it's a problem, of course (I haven't used/looked at them yet myself)", "group_id": 81, "id": 1043660}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305304061.673665, "message": "@tswicegood the '.context_data' would be simply a dictionary, there'd be no \"win\" in this case.", "group_id": 81, "id": 1043761}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305304011.756773, "message": "@markpasc then we have a problem, Houston.", "group_id": 81, "id": 1043754}, {"user_id": 2232, "stars": [], "topic_id": 35138, "date_created": 1305305943.513624, "message": "@eMyller What code will be populating the dictionary that avoids the MRO issues?", "group_id": 81, "id": 1044068}, {"user_id": 2232, "stars": [], "topic_id": 35138, "date_created": 1305304916.563026, "message": "@markpasc super() searches the whole MRO for a given attribute, but it can't result in the methods of sibling methods being called. Given class C that inherits from A and B, super(C, self).my_func() will call A.my_func() or B.my_func(), but not both. Only one path up the inheritance diagram will be followed in a chain of super() calls.", "group_id": 81, "id": 1043889}, {"user_id": 213, "stars": [], "topic_id": 35138, "date_created": 1305306099.0675709, "message": "@eMyller your FormView/DetailView hybrid sounds like something for the CreateView or is the form not related to the detailed object?", "group_id": 81, "id": 1044096}, {"user_id": 213, "stars": [], "topic_id": 35138, "date_created": 1305306148.749819, "message": "(or the UpdateView for that matter)", "group_id": 81, "id": 1044103}, {"user_id": 960, "stars": [], "topic_id": 35138, "date_created": 1305305161.8131111, "message": "@eMyller the issue is if they're both updating, which one wins.  It's the same issue as which one wins for `get_context_data` as far as I can see.", "group_id": 81, "id": 1043912}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305305490.103488, "message": "@tswicegood nope because they'd be inserting different keys into the context dictionary. Even if some of them insert the same, the last \"wins\". Bue the point here is just to enable two or more bases insert their stuff (generally not the same keys) into the context.", "group_id": 81, "id": 1043992}, {"user_id": 3978, "stars": [], "topic_id": 35138, "date_created": 1305306783.3670089, "message": "@jezdez On #django @eMyller mentioned that the form is not a related to the detail object", "group_id": 81, "id": 1044165}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305309413.8673761, "message": "yep, it's just an ordinary form.", "group_id": 81, "id": 1044718}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305309745.6801431, "message": "@niran the context could be fed by a 'set_context_data'-like method, that could update the instance '.context_data' or just return a dictionary (so it'd be collected into the final context dict somewhere else).", "group_id": 81, "id": 1044823}, {"user_id": 141, "stars": [{"date_created": 1305315768.0862629, "user_id": 13325}], "topic_id": 35138, "date_created": 1305315200.287199, "message": "@niran won't it call both? i thought that was the whole point of new style objects' linearized MRO (such as C.mro()). for example, this wfm: https://gist.github.com/971155", "group_id": 81, "id": 1046151}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305315309.942625, "message": "i expect they would have called it the Attribute Resolution Order otherwise.", "group_id": 81, "id": 1046164}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305315943.8937531, "message": "like i said, i hadn't looked at CBVs yet, so i agree it doesn't really matter in this case since FormMixin and SingleObjectMixin don't inherit from a common class that can get_context_data(). however you'd also want a common superclass in the dict case, since you want to know the context_data dict already exists before you try to stuff values in it.", "group_id": 81, "id": 1046277}, {"user_id": 13325, "stars": [{"date_created": 1305315752.3636789, "user_id": 141}], "topic_id": 35138, "date_created": 1305315737.381916, "message": "@markpasc Ha. I wrote something very similar to that but got distracted by work before I could post.", "group_id": 81, "id": 1046237}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305316437.432704, "message": "it probably makes as much sense as it is, where get_context_data() methods in different form hierarchies are otherwise-unrelated cognates. if you want to combine two views with different get_context_data() behavior, resolve the differences however you want since someone else might need it to work a different way.", "group_id": 81, "id": 1046368}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305316605.902647, "message": "(for that matter you might use composition instead of inheritance, or use the ModelFormView instead... like i said i'm not so familiar with the generic CBVs yet so i'm not sure what this use case requires)", "group_id": 81, "id": 1046413}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305319151.7782381, "message": "all this job could be done if we had a \"set_context_data\" method in the base 'View' class. this method could create the context_data attribute if it doesn't exist already and we wouldn't need to override the method. :)", "group_id": 81, "id": 1047014}, {"user_id": 960, "stars": [], "topic_id": 35138, "date_created": 1305323490.96277, "message": "That, or I may have just missed something with it", "group_id": 81, "id": 1047913}, {"user_id": 960, "stars": [{"date_created": 1305325271.741354, "user_id": 141}], "topic_id": 35138, "date_created": 1305323485.0811839, "message": "@markpasc So why doesn't this work as expected?  https://gist.github.com/971375  I agree that what your code demonstrates is the hoped for behavior, but it seems to have some edge cases around it.", "group_id": 81, "id": 1047911}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305324167.4796209, "message": "@tswicegood \"super\" really only means next-in-the-MRO, and in that case the MRO is (C, A, B, object). so A.say() needs to call super(A, self).say() in order for B.say() to execute.", "group_id": 81, "id": 1048014}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305324777.1376441, "message": "it does mean pain when you have to make your DetailPlusFormView.get_context_data() manually compose the FormView.get_context_data() and DetailView.get_context_data() into one context, but that's weighed against some other guy's incompatible cognates failing to interact in an unexpected way", "group_id": 81, "id": 1048099}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305324446.807018, "message": "they could have made super() \u201cjust work,\u201d but that means false cognates (per http://www.modernperlbooks.com/mt/2009/05/perl-roles-versus-duck-typing.html ) would be called automatically. in some cases you'd have to discover this problem in a complex hierarchy and work around it. in the end, the way it works now seems like a reasonable avoidance of magic.", "group_id": 81, "id": 1048050}, {"user_id": 960, "stars": [], "topic_id": 35138, "date_created": 1305324432.882549, "message": "Without that, you have to do your own Object object.", "group_id": 81, "id": 1048049}, {"user_id": 960, "stars": [{"date_created": 1305325290.988023, "user_id": 141}], "topic_id": 35138, "date_created": 1305324421.142967, "message": "@markpasc Now it makes sense why you have `Base` there.  That's still pretty odd.  If that's a requirement, shouldn't `object` automatically allow anything via `super`?", "group_id": 81, "id": 1048047}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305324590.078346, "message": "in my example, A.data() and B.data() are true cognates because they both \u201care\u201d Base.data() implementations, so it should be compatible for A.data() to super into B.data().", "group_id": 81, "id": 1048067}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305325100.254699, "message": "so a solution to fix it in Django would seem to be to have the mixins have a common superclass so you could super through the whole tree of get_context_data() calls... but given the generic CBVs are already a big bag of classes and mixins, i'd be leery of that too.", "group_id": 81, "id": 1048150}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305325227.473927, "message": "hierarchies are easy to shoot yourself in the foot with\u2014see also http://fuhm.net/super-harmful/ \u2014so in this case i would seriously consider using composition to make DetailPlusFormView have-a DetailView and FormView instead of be-a-ing them. then everything is cleanly composed (the same way you'd have to do for get_context_data() anyway), with clear points where you could e.g. move/namespace context data so their keys don't clash.", "group_id": 81, "id": 1048171}, {"user_id": 141, "stars": [], "topic_id": 35138, "date_created": 1305325326.341717, "message": "but as i said it's not me doing it so that could be totally inappropriate to this case :|", "group_id": 81, "id": 1048184}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305428102.054121, "message": "Any other votes?", "group_id": 81, "id": 1057386}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1305428095.9849191, "message": "@markpasc I agree that composition would be a very clever choice here, but anyway it's not a standard practice in the Django environment. So, for this case, I vote for an instance attribute, which is a way that doesn't tie us to the MRO.", "group_id": 81, "id": 1057385}, {"user_id": 2232, "stars": [{"date_created": 1306257645.8324211, "user_id": 141}], "topic_id": 35138, "date_created": 1305571454.521178, "message": "@markpasc You're right. That's what I expected as well, but then I read the super() docs and took them a bit too literally.", "group_id": 81, "id": 1073421}, {"user_id": 21387, "stars": [], "topic_id": 35138, "date_created": 1306135646.4008839, "message": "I have just filed a bug @ Django: http://code.djangoproject.com/ticket/16074 -- I'd appreciate any feedback.", "group_id": 81, "id": 1149676}]