2010/10/15 Łukasz Rekucki <lreku...@gmail.com>: > On 14 October 2010 18:19, Russell Keith-Magee <russ...@keith-magee.com> wrote: >> >> The following things are still needed: >> >> * An audit of create/update views. >> * An audit of date views. > > I was planning on hacking onto this on today/tomorrow. Also see below. > >> * Documentation, including >> - changes to the tutorial >> - topic documentation >> - reference documentation >> - a migration guide for function generic views to class-based generic >> views > > That's probably not something I can help with much :( - no really, I'm > terrible at documenting things (and even worse in doing it in foreign > language).
Don't discount your skills here. Your english is at least as good as some native speakers I know (plus, your English is a lot better than my Polish :-) Plus -- the hardest bit of writing documentation is almost always the first draft. That bit requires you to work out a good organization of your ideas, get examples worked out, and so on. Once you've got a first draft, polishing the language is relatively easy. If members of the community can provide good first drafts, I'm happy to carry the text the rest of the way -- even if the draft has occasionally slightly stilted english because of a non-native speaker. Fixing quirks of grammar is easy. Coming up with good ideas isn't. >> * Feedback from the community on the API that has been exposed. > > This is a kind of "what came first" dilema. As you already mentioned, > most APIs don't get lots of testing and feedback until they are > released. For sure. At this point, I'm trying to just trying entice the adventurous souls out of hiding to take a look. I'm just looking for *some* feedback that indicates that what is on the table isn't completely off base. > There is this crazy idea im my mind to mark CBVs API as > "Beta" in 1.3 and put a big warning in the docs that it can change in > backwards-incompatible was in 1.4. A precedence to this would be > `databrowse`[1], but we could actually finish it this time ;). That thought has occurred to me in the past. My concern is how we manage such an idea as a project. Backwards compatibility is a big deal, and one of Django's big selling points IMHO. So - the question becomes how can we introduce a new feature, but give people fair warning that they're using a feature that is subject to change? Python's 'from __future__' is a really good approach to this, IMHO -- i.e., an explicit opt-in to new features. There might be some room to explore this sort of idea for Django. However, this isn't a decision we need to make right now. If we land what we have, we can fiddle with it until the RC comes out; if we are getting to that point and we're making API changes, we can look at our options for providing adequate warnings. > Anyway, here are my thoughts that troubled me this week[2]. Thanks for that feedback. Regarding mixins: I agree about the ProcessFormView and DisplayFormView differences; that's one of the issues I'm struggling with in the edit views. The issue of a JSON view overriding a TemplateMixin is a valid one; the easy solution here is to include a "BaseUpdateView", and then make "UpdateView" do nothing but include the TemplateMixin. My concern here is the proliferation of base classes that don't really contribute anything but make the class hierarchy that much harder to explain. I'm uncertain myself about the best way to handle error processing. As you noted, having methods that raise NotImplemented is problematic, because they then place constraints on MRO ordering. Using ABCs would be a nice touch, but it's not one available to us since we need support for Python 2.4. Given that we're shipping a bunch of known views that won't be subject to these problems, and any collection of mixins that is missing a required method will raise 'no such method' errors fairly early in the process, I'm inclined to say that we should just leave out this kind of error handling. The last option you mention -- empty methods -- mean the 'no such method' error is replaced by a range of errors depending on how the return value from the method is used. If a mixin can't provide a sensible default implementation, I'd rather see a consistent 'no such method' error. The issue of teaching MRO doesn't especially worry me, because we don't really have to teach the full MRO. Our inheritance hierarchies will be shallow and wide, not deep and convoluted; for almost all practical purposes, MRO is explained as "first implementation in the mixin list wins". Sure, there will be some exceptions, but most of the interesting edge cases of MRO (e.g., diamond inheritance patterns) aren't cases that most users will encounter. Regarding get_* methods: I share many of your concerns about the way we're using get methods. In the current implementation, there's a good reason for them to *not* be properties -- the need to take arguments. However, this could be a symptom of a larger problem. For example, the fact that get_object() changes signature depending on how and when it is called is somewhat concerning to me. It's harder to explain (since you need to be aware of when certain arguments are required) but it also makes things harder to use -- since you can't just generically call get_object(), you need to know what extra magic it expects. One possibility is to rely on view state a lot more -- make get_object() a property, and then make implementations check self for the extra values they need to work. However, I'm not sure how comfortable I am with making such strong use of globals like this. I'm certainly open to suggestions here. One of the reasons I haven't finished my audit of the edit and date views is that I'm not entirely happy with the answers I've arrived at with regards to questions like the one you raise about get_* methods. Lastly, regarding response classes: It sounds like the problem you're describing is that calls to "return HttpResponse()" need to be abstracted behind functions that allow you to return your own custom response types. I don't have any objection to this in principle. >> * Fixing Django's handling of PUT requests (this currently raises an >> expected failure in the test suite) > > Any hints on this, anyone ? Is this as trivial as putting the > `corce_post_put()` in the BaseHandler. This will work, but I'd like to put a little more thought into the "right" solution. Forcing PUT data into POST seems like something that could have unexpected consequences long term. There's also the related issue of handling non-form-encoded data properly; raw_post_data is also a bit of a hack at present. Again, suggestions (and volunteers) welcome. 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 django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
