1. One of my questions left unanswered on the pull request [1] (I mean this one about documentation and `__str__` use.).
2. I've finished rewriting admin checks. I've renamed `admin_validation` to `admin_checks`. I would like you to have a deep look at `fk_name` and `exclude` checks [2] as well as `inline_formsets` tests [3] (especially error messages). 2a. "applabel.modellabel[.fieldname]" is the format of error messages for models and fields. How should the one for admin look like? I propose "applabel.ModelAdminClassName". 2b. BaseModelAdmin, ModelAdmin and InlineModelAdmin classes and their checks live in separated files. `options.py` defines these classes, but checks lives in `checks.py`. We want to have these two issues separated, otherwise class definitions would become too long. Python does not support open classes, so we cannot just add some `_check_*` methods in `checks.py` to existing classes defined in `options.py`. The current approach is that `check` method is defined in `options.py`, but it delegates to appropriate functions in `checks.py` [4]. Yes, I use functions -- there is no need to have validator class, because we don't need to store anything in its instances. However, the code is really ugly. I wonder if there is any better approach. 3. I've created a new ticket [#20974] about lack of mysql-specific checks. 4. I've rebased my branch against master. On Fri, Aug 16, 2013 at 7:45 AM, Russell Keith-Magee <rus...@keith-magee.com > > wrote: > >> 8. I've added a new check. If you're using a `GenericRelation` but there >>> is no >>> `GenericForeignKey` on the target model, an warning is raised. This >>> check was >>> implemented in this commit [9]. It uses `vars` builtin function to check >>> if the >>> target model has a `GenericForeignKey`. This is ugly, but I don't see a >>> better >>> approach. >> >> [9] >>> https://github.com/chrismedrela/django/commit/ab65ff2b6d6346407a11a72c072e358c7b518cf9#L1R397 >>> >> Hrm. I don't really like this, but I'm not sure I have a better option. A >> better approach would be to have GFKs turn up in get_fields, but it isn't >> your responsibility to fix the internal problems of Generic Foreign Keys. >> If we have to live with this, then we should at the very least document it >> as a FIXME, pointing at the underlying problem with _meta handling of GFKs. > > > > Michal Petruca just mailed the django-dev list with some discussion about > changes he wants to make in his own GSoC project, which drew my attention > to something I'd forgotten about. > Does _meta.virtual_fields -- contain the information you need? It looks > like it should. 5. Yes, you're right, `virtual_fields` is what I need. 6. Now I'm implementing filtering checks. [1] https://github.com/django/django/pull/1364 [2] https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/contrib/admin/checks.py#L673 [3] https://github.com/chrismedrela/django/blob/gsoc2013-checks/tests/inline_formsets/tests.py#L113 [4] https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/contrib/admin/checks.py [#20976] https://code.djangoproject.com/ticket/20976 -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
