On Wed, 2007-03-28 at 07:10 -0700, Jiri Barton wrote:
> Is there a way of accessing fields of a model?
>
> I have
>
> class Position(models.Model):
> ....
>
> class Person(models.Model):
> position = models.ForeignKey(Position)
>
> Now, I'd like to get to this position member. Is there another way
> besides the following *oh my*:
>
> Person._meta.get_field('position')
You seem to being a bit judgemental here. What exactly is your problem
with a function call that takes the name of the field and returns the
field object? You just don't like the extra _meta access? That can't be
avoided, for reasons I describe below.
Given that, it can't actually get any simpler than this, can it? One
function call would seem to the minimum.
> I'm trying to create a form from part of the instance but it is so
> different from what form_from_instance can give me that I'd rather
> create a new form. So, then I'm having
>
> class ContractInformation(forms.Form):
> position =
> Person._meta.get_field('position').formfield(empty_label='(Unknown)')
>
> I would hope for something without magic, such as
Function calls have not been called magic for a long time. :-)
> class ContractInformation(forms.Form):
> position = Person.position.formfield(empty_label='(Unknown)')
This is because the attributes on your model are just normal Python
attributes: strings, integers, datetime instances, etc. All of the
machinery needed to store this in the database and relate it to other
objects is kept in the Options class (which is what _meta is). This is a
good design because it means that when you are dealing with a model in
Python, you just talk to it like you would any other Python object using
the same types. So your code doesn't have to understand that there is a
persistence mechanism in the background.
A consequence of this is that if you want to deal directly with the
persistence mechanisms and the model interior structure, you need to
interact with the _meta attribute, which is used to encapsulate the
meta-information. Not even a surprising name, given its behaviour.
So, whilst I don't see what you are unhappy about (if there's a
technical objection, please clarify -- I think I've missed it), I'm also
not sure what the alternatives could be if we want models to continue to
have normal Python types in their attributes.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
