On Thu, 2014-08-21 at 11:07 +0800, Russell Keith-Magee wrote:
> The point is that I am convinced we will need to provide field
> flags to complement the get_fields() API no matter what API we
> choose for get_fields(). In fact, if we define and document a
> sane set of field flags, then the get_fields() API isn't that
> important, it just needs to be useful for the most common use
> cases.
>
> Well, no - it needs to be useful for *all* the use cases *in Django's
> codebase*. The end goal here is to provide a formal API definition so
> that someone else can take the specification, make a duck that quacks
> exactly like it, and use it because it is compatible with Django's
> internals.
>
>
> As an indicative goal - I'm thinking a good GSoC project for next year
> would be to implement a Django-compatible model layer for SQLAlchemy.
> That means the student will need to implement get_fields() (or
> whatever API we end up with) to sufficient depth that they can expose
> a SQLAlchemy model in Django's Admin, using Django's forms. Daniel's
> proof-of-concept project wrapping an email API demonstrates that this
> isn't a theoretical goal - it's has the potential of being real.
Unfortunately I don't see SQLAlchemy models in Admin as realistic at all
by just providing correct _meta API. Of course, the fields returned by
get_fields() calls will also need to quack the right way. Case in point,
Daniel's Gmail PoC uses Django fields internally.
Maybe there is some miscommunication here - what I meant by saying that
In fact, if we define and document a sane set of field flags,
then the get_fields() API isn't that important, it just needs to
be useful for the most common use cases.
meant that if we have sane field flags, then one can always use
get_fields(**return_all_possible_fields), and then use flags on fields
to get a set of fields one is interested in.
It is trivially true that get_fields() isn't sufficient for all use
cases in Django without relying on field flags. One can't even get the
fields for a form without relying on field flags filtering.
So, get_fields() doesn't need to return correct list of fields for all
use cases in Django, it is sufficient that one can get the correct list
of fields with further filtering.
I am not sure if you were objecting to anything else than "it
[get_fields()] just needs to be useful for the most common use cases". I
hope I cleared up what I meant by that.
I remain convinced we should document field flags in addition to the
get_fields() API.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1408602872.11410.300.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.
