Guys I spent quite a while yesterday reading through the newforms section of the docs, and thought I'd taken everything in.
As a python novice, I wrote a test script and couldn't replicate the error, so was beginning to wonder whether I was cracking up! After reading Malcolm's (comprehensive) response, it does make alot more sense and I feel to have a better understanding of how the newforms library hinges together. I've got to say as someone new to django I'm really impressed at the level of support you guys have got going on. On Aug 20, 6:54 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
