A few updates/bugfixes and suggestion of a new field_type

[alTus]

Hello.
I've tried your app (we are developing something like yandex.market)
and it's cool :)
Thanks for sharing it.

--------------------------------------------------------------------------------------------------------------------------------------------

I've noticed a few little things that look like bugs.

1) admin.py

- context.update(adminform=adminform, media=media)
+ context.update(adminform=adminform)

In django 1.2 dynamic inlines are not initiated, if you are using
original code.

2) admin.py

- __all__ = ['BaseEntityAdmin', 'BaseSchemaAdmin',
'BaseEntityStackedInline']
+ __all__ = ['BaseEntityAdmin', 'BaseSchemaAdmin', 'BaseEntityInline']

code like "from eav.admin import *" leads to import error, coz
BaseEntityStackedInline is undefined.
i suppose it's left from previous versions.

--------------------------------------------------------------------------------------------------------------------------------------------

In our project, we needed a choice field, but with a single value.
That is, widget: select of radio buttons set.
Of course it's possible just to use multiple_choices and select only
one choice for such fields...
But there can be some functionality that depends on multiple or single
choice type etc.
It slightly differs from multiple_choices and we've made a few
"commits" to get new TYPE_ONE field work.
If you are interested, I can share it.

Thanks.

PS. Sorry for my English )

[Andy Mikhaylenko]

Hello,
thanks for your interest! I'm glad that you find the application
useful.

1. The app was initially written for Django trunk between 1.1 and 1.2.
The original project is running Django 1.2. I don't think I've seen
the problem you are describing. Could you add more details?

2. Whoops, that certainly is a valid bug!

Thanks for the patches, I can commit them myself or you can fork the
project at bitbucket so I'll just pull the changes into the main
repository. Feel free to update the list of authors.

Concerning the TYPE_ONE, it doesn't sound like a good idea for me but
you may be right. I guess it would be easier to decide looking at the
actual code. It is also important to prevent feature creep because by
adding fields for every possible use case we'll end up with a huge and
slow table of attributes. So we should try our best to reuse the
existing set of fields. OTOH, the BaseAttribute model is abstract, so
we can provide extra datatypes (with facets and stuff) as extensions
(like eav.ext.radiofield.models.Attribute) and mix them in given
project's Attribute model. I think the existing TYPE_RANGE is already
a candidate for such approach because it covers an edge use case
(IMHO).

By the way, if you wish, we can discuss the stuff in Russian and then
add a brief summary in English if considered helpful to other
potential readers.

Cheers,
Andy

P.S.: after writing eav-django I decided to put more effort in Docu
(http://pypi.python.org/pypi/docu). Currently there is a beta-quality
but complete stack (ETL, storage, modeling, querying, web admin,
analysis/reporting). Some components are not public yet but will be
GPL. The major part of the code is a glue between various existing
packages, well-tested and polished. I think it has more potential
because both Django and RDBMS are too rigid for use case classes like
webshops (especially Yandex.Market-like). Docu supports anything from
in-memory store and DBM to Tokyo Cabinet and MongoDB. It offers a
uniform schema/query API so your application will basically work with
any such backend without changing a single line. Thanks for reading
the advertisement. :)) I just think it's really a next step after eav-
django. Maybe a bit "too next" :-)

[Илья ММ]

Да, можно было бы и по-русски, так хоть не надо думать, что пишешь)
Может, лучше как-нибудь на досуге через icq или даже skype?