Alice,
I think our problems are the same, just that you are looking at it
from the left side and I'm looking from the right. ;) In fact, I was
so confused when you replied to the one-to-one post as I thought you
were replying to me!
"""
This relationship has been modelled as a one-to-one, but when listing
the detail of any given Item, I would dearly like to have the extended
data displayed too - whatever that may be. The problem is I can't
figure out how to detect that extra data without adding some
indication in the Items table as to what other table(s) to check in.
Or I could check all specialized tables, which is clunky.
"""
I think part of the solution would be adding a type column to the item
database. To follow your example, type's value for a book would be
"BookItem" (this would be better as a fully-qualified name
items.BookItem if your app was called items). At this point it would
be trivial for the admin to do a lookiup in the bookitems specialized
table. One limitation I can see is when adding a new item from the
item admin page. At that point the page doesn't know the type of item
you're trying to add.
The way I am looking at the problem is whenever I go to the Book
Item's admin page, I would see and be able to fill out the base item's
information as well in the same form, in one shot. This is very
similar to the concept in the Polls tutorial, where you can add many
choices from the Poll view by setting up the relation:
poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED, num_in_admin=3)
except that this doesn't work when you have many items being extended;
you would get the information for all items in the item view, which is
not the desired result.
Here's a possible solution I've been thinking about. Maybe adding a
keyword argument similar to edit_inline, "parent_edit_inline", which
would pull the parent table into the child form instead of the other
way around.
This relationship would not need the keyword "num_in_admin" because
there could only be one parent, and you would simply set the
parent_edit_inline to True, since TABULAR would make no sense.
Another field type, "ChildDescriptionField", could be added so that
adding a BookItem would fill in that column with the child's type
(BookItem).
The result would look something like:
class Item(meta.Model):
type = meta.ChildDescriptionField()
class BookItem(meta.Model):
item = meta.ForeignKey(Item, parent_edit_inline=True)
[...]
Does this ramble sound feasible/the right direction to go in?
-Roberto.
On 1/8/06, Alice <[EMAIL PROTECTED]> wrote:
>
> Your subclass problem sounds similar (though not exact) to this here:
> http://groups.google.com/group/django-users/browse_thread/thread/89123a476f7a26ac
>
> more information on the one-to-one relationship can be found here:
> http://groups.google.com/group/django-users/browse_thread/thread/cb3c96aaffc42597/e10e4aec10e81c96?q=subclass&rnum=1#e10e4aec10e81c96
>
> there is no answer for it yet (if there is, I'd love to hear it ...)
>
> for your permissions issue, you should look into Django's builtin
> support for Users, user authentication and permissions:
> http://www.djangoproject.com/documentation/authentication/#id5
>
> The documentation is still thin and patchy in a lot of places, but it
> should be treated as more of a reference to the code.
>
> Hope this helps some,
>
>
> Alice
>
>
