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 <[email protected] > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
