On Sun, 2007-08-19 at 14:30 -0700, MikeHowarth wrote: > I'll take a look at that. > > Even commenting that line out and attempting to access self.title I'm > still getting an attribute error thrown: 'Register' object has no > attribute 'title'
Doug Ballanc has explained how you should be writing your save() method. I thought I might just add something about why what you're doing doesn't seem to work, despite looking like perfectly valid Python code. The newforms Form class has a specialised __new__ method, which is what is responsible for attaching attributes to the object you get back from calling Form(). In the default case (i.e. pretty much always), what this method does is *not* creating attributes for anything that is a newforms.fields.Field subclass. Rather, those fields are put into an attribute called "base_fields" (which is copied to an attribute called "fields" in __init__). All this metaclass stuff happens in DeclarativeFieldsMetaclass in newforms.forms. Replacing the metaclass with something elase to populate the base_fields leaves open some interesting possibilities about how to initialise form classes for those with imagination. This might look very strange and, in a way, it is unusual. When I was wondering, early on in newforms life, why this was done (I think my initial mental question was "what was he smoking?"), I realised there isn't a completely natural thing to store in those attributes. Do they hold the normalized, cleaned data? The original value? Both, depending upon whether clean has been called? If the attribute is None, does that mean we don't have that value? We haven't set it yet? Or that the form's normalized value is None (possible for some fields)? How would you know which fields had errors in them and what would prevent you accidentally accessing those attributes and treating the values as real values? To some extent, it reduces confusion by not having attributes at all for fields. Instead, you initialise a form with the raw, submitted data. Then you access "cleaned_data" or is_valid() or "errors" whenever you like and the raw data is cleaned and normalized (where possible) and sent to two dictionaries: Form.cleaned_data and Form.errors. So, whilst what you were attempting might seem logical on one level, hopefully I've explained why it could, in many cases, be more confusing and error-prone than convenient. So the design uses a slightly different approach from providing access to the form data and errors. Best wishes, Malcolm -- Borrow from a pessimist - they don't expect it back. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
