Re: Django's CVB - Roadmap?
There is a plan to do some work on the docs at the djangocon sprints - in particular trying to get some examples of when you 'could' and when you 'should not' use the generic CBVs. With regards to Zach's point about TDD testing - some of that may simply be familiarity. I don't know about you but it would have been very difficult for me to get into successfully TDDing a functional view until I'd written several dozen views and knew what the pattern is. You can still test the CBV top to bottom, exactly as you would with a function based view. Yes there may be some shift to conventions, but that will come with familiarity. I think part of the important difference is that when you look at a CBV for the purposes of unit testing it, you feel very quickly that you should be testing the individual methods. This is actually really nice and gives a lot more branch-coverage without rerunning the same 4 database queries every time for variables which aren't used. Without CBVs a complex view can easily extend over 50 or so lines, whereas it's more natural to split this up and test the sections independently with a Class based system. I know in general we should be 'writing less view code' and pushing the logic elsewhere, but that depends on what that logic is - for example the view layer needs to decide whether to return JSON or HTML depending on certain headers in the request, and that is more easily testable as an overridden render to response method than as the last 4 lines of a 50 line view. Marc -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ. To post to this group, send email to django-developers@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.
Re: #18094: signals, model inheritance, and proxy models
On Jun 4, 5:58 pm, Jeremy Dunck wrote: > On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen > > Could we force the caller to define the wanted signal inheritance mode > > when .connect() is called? The inherit mode must be one of True,False > > or None. Default of None means no inheritance (as now) but it will be > > deprecated. > > I took a swing at a similar implementation > here:https://github.com/votizen/django/tree/fe0f92b0f50bcd47742638ff3b8ff9... > (Tracking branch:https://github.com/votizen/django/tree/virtual_signals) > > I haven't tried to address performance yet, but I've read all > ofhttps://code.djangoproject.com/ticket/16679and think it's possible to > keep sane overhead. There is one two really important signals for performance: pre_init and post_init. If these are fast (maybe by special casing), then the rest of the signals wont be that important. IIRC the caching approach will give you good performance assuming there aren't any signals for the model which is inited. This isn't true currently. Of course, all bets are off if there are pre/post init signals for the model. We need to either make the pre/post init signals fast enough, or make some special casing for them. > > Any opinions on the above transition phase idea? Other ideas? Is the > > "define signal inheritance on connect" the wanted behavior in 1.7 or > > should it be something else? > > I think this is the right approach - but I'm not sure why you said > "1.7" here. You mean 1.5 or done with the deprecation path by 1.7? I guess there isn't much point for the 1.7 in there. Maybe I was going to ask about the default behavior in 1.7 forward (inherit or no- inherit) but just wrote something different. Hard to know now... - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Customizable Serialization check-in
Hi, Sorry for being late with weekly update. Due to some issues with Meta and my wrong understanding of metaclasses that Russell pointed I spend time on enhance my knowledge about this. I rewrote also some part of code that I have written week before. This week I will do what I was suppose to do last week - initial tests, documentations. After this week serialization should work with simple objects. -- Piotr Grabowski -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Draft branch: Swappable User models in contrib.auth
On Jun 4, 6:12 pm, Russell Keith-Magee wrote: > * The swapping mechanic is set up using a new Meta option on models > called 'swappable' that defines the setting where an alternate model > can be defined. Technically, the swappable option *could* be used for > any model; however, I'm not proposing that we actually document this. > I've implemented it as a generic approach purely to make the internals > cleaner -- mostly to avoid needing to make references to auth.User in > the model syncdb code, and to make testing possible (i.e., we can do > validation tests on a dummy 'swappable' model, rather than trying to > munge a validation test for auth.User specifically). The "swappable" meta attribute part of the patch raises a question: would the following pattern work instead of the meta attribute: # in auth/models.py if settings.AUTH_USER_MODEL: User = get_model(AUTH_USER_MODEL) else: class User(models.Model): # the traditional auth-user model definition here If I understand the patch correctly the "swappable" Meta option basically just removes the model from the app-cache. This means the model will not be synced or validated. In addition you can't make foreign keys to the swapped out model due to other changes in the patch. Still, the auth.User model exists, and is importable. The idea above gets rid of the User model 100% if settings.AUTH_USER_MODEL is set. In runtime it never exists at any level. It is very simple in this regard, and of course the implementation is simple, too. Is there some design consideration which prevents the use of the above mentioned idea? - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Django's CVB - Roadmap?
On 01/06/12 15:54, Jacob Kaplan-Moss wrote: > On Fri, Jun 1, 2012 at 10:14 AM, Victor Hooi wrote: >> The reason for my post - is there anything from the Django core as a whole >> on this? What's the future roadmap like in terms of CBV's? Are there going >> to be any changes to it, or are we safe to assume things will be as they are >> now. > > I think as a whole we're divided. Luke's opinions differ from > mine, and it's entirely unclear to me who's "right" or even if there's > a "right" to be had. And that's just the two of us! I personally found all the responses and discussion really enlightening, and it moderated my opinions somewhat. Here are the things I'd like to actually see change: 1) An easy one: Some documentation to the effect of this: "The Django-supplied CBV base classes may not be the best fit for your project. Consider two alternatives - use a function, or write your own base classes." I'm happy to write that paragraph if others agree. 2) A harder one: nicer functional way of using CBVs in the simple case, so they can be used from traditional function view without subclassing. In theory, you can do this: def my_view(request): return ListView.as_view(template_name='foo.html') However, you've got a few problems: * you can't pass in the extra context you need, which is pretty much a crucial requirement * you have some gotchas with things like POST requests. I found I had to write something like this snippet: https://gist.github.com/2596285 But it's not ideal in a number of ways, like needing its own documentation, since it doesn't just set parameters on ListView. Luke -- O'REILLY'S LAW OF THE KITCHEN Cleanliness is next to impossible. Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
San Francisco sprint info
We (Votizen) hosted a 1-day sprint yesterday from 10a to 6p. I had capped attendance at 30 just for logistical reasons - there's room for more but I wanted to gauge interest. 24 people signed up, and I'd guess that about 20 people total were there for at least part of the day. I think we peaked at about 16 people at once. I think this is a really great turnout, but I look forward to building it up. Julien Phalip was available to take patches - thanks, Julien! I worked on making signals work with class inheritance (a handler connected to Some(Model) does not consistently receive calls for SubclassOf(Some)). This is an old problem made worse with the addition of abstract and proxy models. I've intended to work on it for over a year, so it's great to finally get some focus on it. The branch so far has a proof of concept with tests passing - now we need some discussion on backwards-compatibility issues and, if we can come to some conclusion, I'll work on improving performance of the updated implementation. https://github.com/votizen/django/tree/virtual_signals https://code.djangoproject.com/query?status=!closed&keywords=~signals The attendees collectively worked on admin, documentation, signals, mezzanine, and probably some other things I didn't see. :) As previously noted[1] we plan to host these sprints in San Francisco twice per month - 1st and 3rd weekends of the month (mostly Saturdays) - at the same location (Votizen, 292 Townsend) and time (10a - 6p). We put up a job whiteboard which listed Votizen (contact me), Burning Man (brianber...@burningman.com), and Priceonomics (o...@priceonomics.com). We covered drinks at a net cost of about $2 per attendee. If you or your organization would like to sponsor food or beverage, I'll make sure you're publicly noted and thanked. To all who came, thank you for contributing to the core and the community. To all who didn't, please consider joining us next time. I'll be putting up a signup form for the next one shortly. Cheers, Jeremy [1] https://www.djangoproject.com/weblog/2012/may/24/sf-sprints/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Improvements to contrib.sessions (Pull #78)
Hi all, Recently, I have been working on some patches for contrib.sessions. These include server side sessions expiry check (#18194) and some other trivial changes. These changes are in the pull request [#78][pull-78] The expiry checks is be done in the base backend, i.e. inherited by every backend, utilizing the timed signer from signing framework. This would mean that only session data which was signed within a duration of `settings.SESSION_COOKIE_AGE` will be valid. The format in which session data is stored is changed with this, so existing sessions are invalidated and reset. To prevent loss of existing sessions, I have provided a compatibility setting which when set to true, will run the legacy decoding mechanism on a failed session decode with new one. This does make the system susceptible to all attacks possible with the previous mechanism. I have moved the session cleanup command logic to individual backend. Cleanup for sessions data will be done on the basis of current backend setting, instead of just for the database backend. Also, the session key character set is now `a-z0-9`. -- Rohan [pull-78]: https://github.com/django/django/pull/78 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Draft branch: Swappable User models in contrib.auth
Hi all,
Following the BDFL pronouncement of a preferred option for
customisable User models in contrib.auth [1], I've just pushed a
branch to Github that contains a draft implementation [2].
It's not ready for trunk quite yet, but you can use this code to set
up a custom User model, and then log into admin with that User model,
and the effort required to do this is fairly minimal.
There isn't a whole lot by way of documentation -- all I've done is
add the documentation for the new AUTH_USER_MODEL setting, and a stub
for where the documentation about swappable User models will finally
go.
Testing is also an interesting area. I've got some tests in place for
the validation code, and for parts of the management. Widespread
testing that apps (e.g., admin) will work with a different User model
will be a bit difficult because the app cache is populated at the
start of the test run, which prohibits switching the User model later
in the suite. Any suggestions on areas where more testing is necessary
and possible are welcome.
So - how does it work? Here's a minimal example in which MyUser has a
unique, required EmailField acting as the identifier for users.
There's also a required "date_of_birth" field for every user. To
switch to using this User model:
* Define a new "myauth" app, and put the following into your models.py file
===
from django.db import models
from django.contrib.auth.models import BaseUserManager, AbstractBaseUser
class MyUserManager(BaseUserManager):
def create_user(self, email, date_of_birth, password=None):
if not email:
raise ValueError('Users must have an email address')
user = self.model(
email=MyUserManager.normalize_email(email),
date_of_birth=date_of_birth,
)
user.set_password(password)
user.save(using=self._db)
return user
def create_superuser(self, username, password, date_of_birth):
u = self.create_user(username, password=password,
date_of_birth=date_of_birth)
u.is_admin = True
u.save(using=self._db)
return u
class MyUser(AbstractBaseUser):
email = models.EmailField(verbose_name='email address',
max_length=255, unique=True)
date_of_birth = models.DateField()
is_admin = models.BooleanField(default=False)
objects = MyUserManager()
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = ['date_of_birth']
def get_full_name(self):
return self.email
def get_short_name(self):
return self.email
def __unicode__(self):
return self.email
# Admin required fields
def has_perm(self, perm, obj=None):
return True
def has_module_perms(self, app_label):
return True
@property
def is_staff(self):
return self.is_admin
@property
def is_active(self):
return True
===
* Set AUTH_USER_MODEL = 'myauth.MyUser'
* Run syncdb.
It's important that you do all this on a clean project; once you've
run syncdb, the foreign keys are already set up, and changing
AUTH_USER_MODEL will lead to hilarity.
Some implementation notes:
* As the branch currently stands, you can log into admin with a
custom User model by doing nothing more than defining an
'admin-compatible' User model and setting AUTH_USER_MODEL.
* The fields on MyUser are the minimum subset that I've been able to
establish in order to be "admin-compatible". The implementation of
MyUser is intentionally simple -- every user is effectively a
superuser. If you want fine-grained permissions, you'll need to
implement them.
* The createsuperuser and changepassword management commands both
work with the designated User model.
* The custom manager is required to make sure that the
createsuperuser management command works. Strictly, only
create_superuser is required, but create_user is an obvious utility to
have, so I've included it here.
* I've made get_full_name() and get_short_name() part of the required
API; this follows the most practical and applicable of the suggestions
from the W3C guidelines on personal names [3].
* USERNAME_FIELD and REQUIRED_FIELDS are constants used for
metaprogramming. For example, createsuperuser needs to ask for data
for all the required fields; these constants let you define what
createsuperuser should ask for. They're also used whenever the auth
backend needs to retrieve the User based on credentials (the backend
can't say User.objects.get(username=…), because the field may not be
called username). I'm not completely happy about the way these
constants are defined, but I also can't think of a better option,
other than top-level settings (e.g., AUTH_USER_USERNAME_FIELD).
Suggestions and opinions welcome.
* The swapping mechanic is set up using a new Meta option on models
called 'swappable' that defines the setting where an alternate model
can be defined. Technically, the swappable option *could* be used for
any model; however, I'm not proposing that we actually document th
Re: Django's CVB - Roadmap?
Glad to see this debate happening, because for a long time I felt like I was the only one who had issues with CBVs. I forced myself to use CBVs (custom and generics) on two major projects and I'm still struggling to see the real value in them. Luke's post did an excellent job of articulating the issues, so I won't bother repeating the same arguments. However, one of the things I find with CBVs is that it encourages a programming style that doesn't seem to go well with the TDD approach (at least in my opinion): With FBVs, I would start writing the code for my view, satisfying the test, then going back and refactoring the view code by looking for commonalities with other views (Write code > Pass Test > Refactor) With CBVs, I tend to start by searching for an appropriate parent/base class to subclass, then writing my custom view code and satisfying the test. I see this as forcing the refactoring first before writing custom code (Refactor > Write code > Pass Test) Not sure if anyone else feels the same way, but it's good to hear all the different perspectives on this. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/dMym_nPg2T0J. To post to this group, send email to django-developers@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.
Re: #18094: signals, model inheritance, and proxy models
On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen wrote: > On Apr 12, 10:27 pm, Anssi Kääriäinen wrote: >> > So perhaps we do need the signal inheritance behavior to be opt-in when >> > connecting the signal handler. I think I'd like to see a deprecation >> > path so that eventually the inheritance behavior is the default, and you >> > have to opt out of it, as I think in most cases it's the desired behavior. >> >> Unfortunately this seems to be the only backwards compatible way >> forward. I don't know how to do the technical details... from >> __future__ import pre_save? :) > > Could we force the caller to define the wanted signal inheritance mode > when .connect() is called? The inherit mode must be one of True,False > or None. Default of None means no inheritance (as now) but it will be > deprecated. I took a swing at a similar implementation here: https://github.com/votizen/django/tree/fe0f92b0f50bcd47742638ff3b8ff94af83ff9c5 (Tracking branch: https://github.com/votizen/django/tree/virtual_signals ) I haven't tried to address performance yet, but I've read all of https://code.djangoproject.com/ticket/16679 and think it's possible to keep sane overhead. > Another problem is that delete fires the same signal multiple times in > the inheritance chain. We can't remove the parent signal for backwards > compatibility reasons, nor can we fire them as then inheriting > listeners will see the delete signals multiple times. I think I solved this my the simple expedient of seen_receivers here: https://github.com/votizen/django/blob/270666cc701dff1eb1a8e5e649634aee5980b737/django/dispatch/dispatcher.py#L249 Basically we can group up the receivers so that they are fired at most once. ... > Another option is to continue as currently: model signals aren't > handled coherently, and there is no signal inheritance. Django users > have managed to survive thus far with the current signals > implementation, so maybe it doesn't need fixing? I'm less of a fan of signals than I used to be, but I think this line of reasoning is wrong - mostly people don't notice when their signal handlers are doing the wrong thing. The lack of visibility makes it difficult. I have definitely seen bugs caused by this misbehavior. (I'm not in favor of removing signals entirely, for what it's worth - I still don't see a better way in some cases - but I do think more visibility would be useful.) > Any opinions on the above transition phase idea? Other ideas? Is the > "define signal inheritance on connect" the wanted behavior in 1.7 or > should it be something else? I think this is the right approach - but I'm not sure why you said "1.7" here. You mean 1.5 or done with the deprecation path by 1.7? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Django's CVB - Roadmap?
Glad to see this debate happening, because for a long time I felt like I was the only one who had issues with CBVs. I forced myself to use CBVs (custom and generics) on two major projects and I'm still struggling to see the real value in them. Luke's post did an excellent job of articulating the issues, so I won't bother repeating the same arguments. However, one of the things I find with CBVs is that it encourages a programming style that doesn't seem to go well with the TDD approach (at least in my opinion): With FBVs, I would start writing the code for my view, satisfying the test, then going back and refactoring the view code by looking for commonalities with other views (Write code > Pass Test > Refactor) With CBVs, I tend to start by searching for an appropriate parent/base class to subclass, then writing my custom view code and satisfying the test. I see this as forcing the refactoring first before writing custom code (Refactor > Write code > Pass Test) Not sure if anyone else feels the same way, but it's good to hear all the different perspectives on this. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/jMkryR-q8YcJ. To post to this group, send email to django-developers@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.
Re: Django's CVB - Roadmap?
On 1 June 2012 16:54, Jacob Kaplan-Moss wrote: > I think this might be a situation where we need some more feedback > from the community and some more time to decide what the right move > here is. > > So... what do *you* think? I've used CBV's in one app so far, and have wound up only using View and TemplateView. For the rest it seems better to make my own methods to deal with forms etc. and not bother with any of the mixins. Even in that app, when I redirect I use a functional style generic view. I prefer my urlconfs to look like config, not code. I had planned on rewriting functional views, but... no. I think it is important to remember the difference between CBV and *generic* CBV. It's the latter that doesn't seem to be working very well. HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Django's CVB - Roadmap?
Still sounds like an issue with the docs to me, and while they do still have some issues, I'm a big supporter of the CBVs. I've posted this here before, but http://ccbv.co.uk/ really helps cut out most of the pain of the "looking through the source code" stage of understanding the CBVs because it squashes the class hierarchy and allows you to "see the wood for the trees" as it were. There are UX issues and even the odd bug, but it helps. In other words: it's a work in progress, but until the docs are fixed, I think it's a very useful resource. Disclaimer: I was involved in creating it, but it's not-for-profit, and there for everyone to use. I would really like to get involved in getting the docs to the stage where they display something more similar to this, so if you know how I could do that, I'd really like to know. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/I80VlL1c89UJ. To post to this group, send email to django-developers@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.
