Re: Future url tag behaves unexpectedly

[Klaas van Schelven]

No one ready to weigh in on this?
:-(

On Thu, Aug 23, 2012 at 4:17 PM, Klaas van Schelven <
klaasvanschel...@gmail.com> wrote:

> Hi all,
>
> I'm not really ready to post this as a bug, please help me correct any
> possible misunderstandings before I do so.
>
> I was gently pushed towards the future url template tag due to my
> screen filling up with DeprecationWarnings
>
> There isn't a whole lot of documentation about the new url tag. This
> is what I could find:
>
> https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi
> and the "Forwards compatability" box on
>
> https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#std:templatetag-url
>
> Now, given the fact that the url tag is described as able to take a
> variable, I assumed it would be possible to pass callables to it. (In
> fact, I already had manually created such functionality myself for our
> app, and was happy to notice that Django now appears to support it out
> of the box). I.e.
>
> # views.py
> def myview(request, obj_pk=None):
> pass
>
> def other_view(request):
> return render('template.html', {'link': myview})
>
> # template.html
> {% load url from future %}
> {% url link obj_pk=1%}
>
> However, this fails, since the regular template variable resolution
> process is reused to resolve 'link'. Since link is a callable Django
> will attempt to call it. However, 'other_view' shouldn't really be
> called (rather, it should be used as the input of a call to reverse).
> In this case specifically it will fail since the parameters 'request'
> and 'obj_pk' aren't provided. The url templatetag will then try to
> reverse the empty string or any value given in TEMPLATE_DEBUG.
>
> I see the following 2 logical courses of action and a possible extra:
> 1] the status quo is the desired behavior: improve the documentation
> 2] allow for passing callables. However, this also makes certain use
> cases impossible. I.e.
>
> def other_view(request):
> return render('template.html', {'link': lambda: 'myapp.myview'})
>
> will become impossible, including more meaningful equivalents.
>
> extra] don't silently continue when the url's first param fails to
> evaluate properly only to fail 3 lines later with an incomprehensible
> error message.
>
> Hope this prompts some discussion / resolution. I'm willing to copy
> paste the above to track if necessary.
>
> ciao,
> Klaas
>



-- 
Klaas van Schelven
+31 6 811 599 10

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Future url tag behaves unexpectedly

[Klaas van Schelven]

Hi all,

I'm not really ready to post this as a bug, please help me correct any
possible misunderstandings before I do so.

I was gently pushed towards the future url template tag due to my
screen filling up with DeprecationWarnings

There isn't a whole lot of documentation about the new url tag. This
is what I could find:

https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi
and the "Forwards compatability" box on
https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#std:templatetag-url

Now, given the fact that the url tag is described as able to take a
variable, I assumed it would be possible to pass callables to it. (In
fact, I already had manually created such functionality myself for our
app, and was happy to notice that Django now appears to support it out
of the box). I.e.

# views.py
def myview(request, obj_pk=None):
pass

def other_view(request):
return render('template.html', {'link': myview})

# template.html
{% load url from future %}
{% url link obj_pk=1%}

However, this fails, since the regular template variable resolution
process is reused to resolve 'link'. Since link is a callable Django
will attempt to call it. However, 'other_view' shouldn't really be
called (rather, it should be used as the input of a call to reverse).
In this case specifically it will fail since the parameters 'request'
and 'obj_pk' aren't provided. The url templatetag will then try to
reverse the empty string or any value given in TEMPLATE_DEBUG.

I see the following 2 logical courses of action and a possible extra:
1] the status quo is the desired behavior: improve the documentation
2] allow for passing callables. However, this also makes certain use
cases impossible. I.e.

def other_view(request):
return render('template.html', {'link': lambda: 'myapp.myview'})

will become impossible, including more meaningful equivalents.

extra] don't silently continue when the url's first param fails to
evaluate properly only to fail 3 lines later with an incomprehensible
error message.

Hope this prompts some discussion / resolution. I'm willing to copy
paste the above to track if necessary.

ciao,
Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Moving my issue forward

[Klaas van Schelven]

Hi all,

I've reopened an old issue that I keep running into:

https://code.djangoproject.com/ticket/15084#comment:20
The comment indicates quite clearly what the problem is, how it can be
reproduced and has a patch included. Can we move this forward? Would
be much appreciated.

regards,
Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: (Model)Forms localize=True violates DRY

[Klaas van Schelven]

I'll just add my 2 cents as partial copy/paste from the (now closed)
ticket page:

I agree w/ Serge that USE_L10N should be the default value for
localize.

* I think the case Russel mentions is the exception, not the rule.
"Usually" a number is just a number, not a year. Postal codes and
phone numbers are often not numbers at all but a string.
* We (Django) have made the opposite decision for template rendering:
Indicating USE_L10N in settings makes localized rendering the default
throughout the application, and the developer is left to find the
exceptions and note them whenever they occur. This is inconsistent
with the way we deal with forms.


* If blank/help_text/verbose_name are considered undesirable elements
of Model Fields I'd love to know what the new canonical pattern for
DRY between models and corresponding forms is. I _do_ think there is
value in not repeating yourself between forms & models.


On Jun 23, 2:22 am, "Serge G. Spaolonzi" <se...@cobalys.com> wrote:
> I have opened a ticked for this same issue, it was rejected because the
> core team didn't liked the idea of including FormField options in
> ModelField. Decision i think was correct, I wasnt aware the other
> FormFields options in ModelFields like help_text were there for historical
> reasons.https://github.com/cobalys/django/blob/ticket_18471/django/db/models/...
>
> If this is not the correct way to do it, we need to find another way to do
> it respecting the DRY principle.
> imao the ModelFields must localize according to settings.USE_L10N, then if
> it is specified in the option localize as false that field must not
> localize.
>
> From the official Django Documentation:
>
> USE_L10N
> Default: False
> A boolean that specifies if localized formatting of data will be enabled by
> default or not. If this is set to True, e.g. Django will display numbers
> and dates using the format of the current locale.
>
> As I understand USE_L10N sets the default behavior application wise for the
> localization.
>
> Regards
> Serge G. Spaolonzi
>
>
>
>
>
>
>
> On Fri, Jun 22, 2012 at 9:16 AM, Karen Tracey <kmtra...@gmail.com> wrote:
> > On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven <
> > klaasvanschel...@gmail.com> wrote:
>
> >> I've created a ticket, but have always understood that calling
> >> attention to tickets should be done separately on the Django-
> >> developers mailinglist
>
> > It's not necessary nor encouraged to call attention to newly-opened
> > tickets on the -developers list. People are asked to post to the list in
> > preference to "contesting" a resolution the don't agree with (e.g.
> > wontfix). Newly-opened tickets on the other hand don't need to be announced
> > on the list, plenty of people monitor the flow of incoming tickets.
>
> > Karen
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Plans for "forms"

[Klaas van Schelven]

Thanks for the info

On Jun 21, 2:04 pm, Andrew Godwin <and...@aeracode.org> wrote:
> On 21/06/12 11:58, Klaas van Schelven wrote:
>
> > Hi all,
>
> > I'm not entirely sure about the forum to ask this question: the
> > motivation is "django-users" like; but since it's about a roadmap /
> > the future I suppose only developers will know the answer.
>
> > I vaguely remember there being mention of big plans to do a big
> > refactoring of Django's forms/modelforms/formsets functionalities at
> > DjangoCon EU 2011. I'm not entirely sure what these plans entailed, if
> > there were ever such plans or if they've already been implemented. If
> > anything is surely to come up for Django 1.5 we'll postpone some
> > refactorings in our own code untill we know what the new canonical way
> > of doing this is.
>
> Hi Klaas,
>
> I suspect you're thinking of the form templating refactor (making all
> the form widgets use templates that can be overridden etc.) - this was
> done for GSOC last year but unfortunately it's blocked on us improving
> the template engine - it's too slow in the current one to be workable.
>
> There was also a GSOC project that same year to make the templating
> faster, but that unfortunately didn't result in something we could use.
>
> Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

(Model)Forms localize=True violates DRY

[Klaas van Schelven]

Hi all,

I've created a ticket, but have always understood that calling
attention to tickets should be done separately on the Django-
developers mailinglist, so allow me to copy/paste a bit:

As it is now one cannot make localized ModelForms without violating
DRY. Developers w/o the desire for localized data in their application
can simply take a model and then create a modelform in three lines and
an admin interface in even less. However, a developer that wants
localization to work in the admin/their modelforms needs to set the
attribute localize=True for each single field that they want
localized. This breaks DRY as there is both repetition of the
"localize=True" and it also introduces new repetition between models &
their forms.

I understand that the decision to make localize=False the default was
both deliberate and probably the correct one, as Russel explains
here:  
http://groups.google.com/group/django-developers/browse_thread/thread/01096cd968bf276a/9ad982e939f1284f

However, a couple of notes:
* I think the case Russel mentions is the exception, not the rule.
"Usually" a number is just a number, not a year. Postal codes and
phone numbers are often not numbers at all.
* We (Django) have made the opposite decision for template rendering:
Indicating USE_L10N in settings makes localized rendering the default
throughout the application, and the developer is left to find the
exceptions and note them whenever they occur. This is inconsistent
with the way we deal with forms (and has the usual drawbacks of
inconsistency, such as the confusion of the OP in the email above).

My suggested solution would be to add an attribute to ModelFields.

We already have a number of cases in which attributes of models'
fields are propagated to your modelforms. blank => not required,
verbose_name => label and help_text => help_text spring to mind.

I'd say name this attribute "localize" and default it to True (since
that's the most common case). But this will introduce backwards
breakage, so I can also imagine simply keeping it False as a default.
That would at least get rid of the violation of DRY mentioned above.
Alternatively the default value of this attribute could be
settings.USE_L10N.

Once we have localize=True/False on modelfields, we could even
envision using that value in template output as well, i.e. years will
automatically be recognized as such and we no longer need to
explicitly mark them as non-localized each time they're used in a
template. But maybe that's ground for another ticket.


regards,
Klaas van Schelven

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Plans for "forms"

[Klaas van Schelven]

Hi all,

I'm not entirely sure about the forum to ask this question: the
motivation is "django-users" like; but since it's about a roadmap /
the future I suppose only developers will know the answer.

I vaguely remember there being mention of big plans to do a big
refactoring of Django's forms/modelforms/formsets functionalities at
DjangoCon EU 2011. I'm not entirely sure what these plans entailed, if
there were ever such plans or if they've already been implemented. If
anything is surely to come up for Django 1.5 we'll postpone some
refactorings in our own code untill we know what the new canonical way
of doing this is.


Klaas van Schelven

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Sprints DjangoCon Europe

[Klaas van Schelven]

Hi all,

I'm sure you've all heard of the upcoming DjangoCon Europe. Of special
interest to Django Developers will be the sprints, on the 9th & 10th
of June. We've got a very special location: 
http://djangocon.eu/venues/#sprint_venue
Of further interest: the sprints will run for 48 hours straight. We
even have field beds...

I think it would be great if we can have some (or a couple) of themes
to work on / towards. Can we have the sprints coincide with "a bigger
picture" in Django?

If this is too soon, I'd be glad to re-ask the same question a month
in advance...

regards,
Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Various small issues

[Klaas van Schelven]

Hi all,

Maybe I wasn't clear enough last time... I've provided patches for
both these old problems and would appreciate either a brutal Linus
style rant for being such an idiot or would like to see the patches
applied. Silence... not so much.

ciao,
Klaas

On Jan 14, 6:28 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> Hi all,
>
> I've been looking into a few old unresolved issues.
>
> http://code.djangoproject.com/ticket/11667
> "Full traceback if import error before model validation" is a simple
> annoyance. On the issue page (one year old) various solutions are
> suggested, each with a patch. Can someone take a decision on the best
> patch and move this forward?
>
> http://code.djangoproject.com/ticket/10967
> save(force_update=True) crashes with model inheritance
> Turned out to be quite simple. I've provided tests & a patch. If
> someone who knows about the ORM is willing to take a look I guess we
> could move to a check in quickly.
>
> If anyone would care to take a look, that would be much appreciated,
>
> Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature suggestion: auto translate verbose names

[Klaas van Schelven]

Hi,

Thanks for the tip... that obviously makes it better since
"verbose_name" is no longer there. Obviously still not perfect, since
every line still repeats itself, but thanks anyway.

Klaas

On Jan 15, 4:16 am, Sergiy Kuzmenko  wrote:
> It sounds like the concern here are repetitive and untidy lines with
> lots of "verbose_name" so use of positional arguments may prettify a
> bit field definitions. It is not obvious from documentation (all
> fields are listed alphabetically) but for all except relationship
> fields verbose_name is the first positional argument. So field
> definition from your example may be shortened to this:
>
> class MyModel(models.Model):
>    some_field = models.IntegerField(_("Some field"))
>    some_other_field = models.IntegerField(_("Some other field"))
>
> Of course, you'd still need to use _ or one its verbose equivalents to
> indicate the field is translatable.
>
> Does this make it a bit better?
>
> Cheers
> SK

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Various small issues

[Klaas van Schelven]

Hi all,

I've been looking into a few old unresolved issues.

http://code.djangoproject.com/ticket/11667
"Full traceback if import error before model validation" is a simple
annoyance. On the issue page (one year old) various solutions are
suggested, each with a patch. Can someone take a decision on the best
patch and move this forward?

http://code.djangoproject.com/ticket/10967
save(force_update=True) crashes with model inheritance
Turned out to be quite simple. I've provided tests & a patch. If
someone who knows about the ORM is willing to take a look I guess we
could move to a check in quickly.

If anyone would care to take a look, that would be much appreciated,

Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Feature suggestion: auto translate verbose names

[Klaas van Schelven]

Hi,

A lot of my models look like this

class MyModel(models.Model):
some_field = models.IntegerField(verbose_name=_("Some field"))
some_other_field = models.IntegerField(verbose_name=_("Some other
field"))

class Meta:
verbose_name = _("My model")
verbose_name_plural = _("My models")

Note the clear violation of DRY. In the above example for all uses of
verbose_name, in practice for 98% of verbose_name's uses. In other
words, I mainly use verbose_name to repeatedly tell Django that my app
is indeed internationalized.

Is there any particular reason this is the case?

Has this been discussed before? I can't find any such discussion, but
that might just be my lack of google skills.

If there are no fundamental objections against fixing this I'd gladly
dive in an provide a patch.

regards,
Klaas van Schelven

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

n project and apps).


>
> d) I think the documentation text can be changed to make it clear that
>    no translation searching with short circuit is done but rather a
>    build of a unique translation by merging in/overriding the different
>    parts in the order documented. Also, the note about the
>    LocaleMiddleware can be dropped. Will take care of this soon.
>

Thanks!

Klaas van Schelven

> Regards,
>
> --
> Ramiro Morales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Hi all,

I'll just keep patiently bumping my own bugreport, i.e.
http://code.djangoproject.com/ticket/14924

I also do have something new to add & request since last time on this
list. I'd like to have some discussion on my own comment below: I'd
like to have some input on the most desirable order of looking for
localization sources.

Having looked at the original tests the most desirable order appeared
to be: 1. Project path locale 2. Apps (in correct order) 3. Locale-
path 4. Django's own translations

I made a patch (submitted in the bugreport) which I have running in
some production code now, and I'm feeling this is not the most logical
order. (The order was originally established by looking at the
existing tests and code, and matching that order as closely as
possible while making sure the apps are evaluated in the correct, not
reverse, order).

However, in my mind, locale path should be the first to be evaluated.
The reason someone would put up a specific path for locales pretty
much has to be to override the existing behavior (which would be found
in project and apps). At least, that is how I use and want to use the
explicit locale path.

Input (discussion) on this is much appreciated. I'll gladly put in a
new patch once a decision is reached. If this is a separate issue, I'm
also fine on opening a separate ticket. (it could be argued that we
can move forward on the original bug report as a separate issue more
easily, since it's "obviously broken")

ciao,
Klaas

On Dec 23 2010, 5:00 pm, Klaas van Schelven
<klaasvanschel...@gmail.com> wrote:
> Thanks for the notification!
>
> On Dec 23, 2:24 pm, Ramiro Morales <cra...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Klaas,
>
> > On Thu, Dec 23, 2010 at 7:43 AM, KlaasvanSchelven
>
> > <klaasvanschel...@gmail.com> wrote:
> > > Hi all,
>
> > > Thanks for checking in 14910!
>
> > > Could anyone take a serious look at
> > >http://code.djangoproject.com/ticket/14924
>
> > > It has a test that proves the problem and a relatively simple patch.
>
> > > I'm doing a lot of "app overriding" and this bug is extremely annoying
> > > in that case. It would be great if the fix could still make it to 1.3
>
> > I'm pretty sure a design decision will be made about it before 1.3 gets
> > released. It is in the list of tickets I want to look at, and I know it is 
> > in
> > the radar of at least one core developer.
>
> > Just bear with us, we have a lot of tickets (some of them older
> > and/or uglier) to review and fix and one almost seven weeks to work on
> > bug killing before 1.3 goes gold.
>
> > Thanks for reporting, following and contributing to the solution of
> > this old issue, and for your patience.
>
> > --
> > Ramiro Morales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Thanks for the notification!

On Dec 23, 2:24 pm, Ramiro Morales <cra...@gmail.com> wrote:
> Klaas,
>
> On Thu, Dec 23, 2010 at 7:43 AM, Klaas van Schelven
>
> <klaasvanschel...@gmail.com> wrote:
> > Hi all,
>
> > Thanks for checking in 14910!
>
> > Could anyone take a serious look at
> >http://code.djangoproject.com/ticket/14924
>
> > It has a test that proves the problem and a relatively simple patch.
>
> > I'm doing a lot of "app overriding" and this bug is extremely annoying
> > in that case. It would be great if the fix could still make it to 1.3
>
> I'm pretty sure a design decision will be made about it before 1.3 gets
> released. It is in the list of tickets I want to look at, and I know it is in
> the radar of at least one core developer.
>
> Just bear with us, we have a lot of tickets (some of them older
> and/or uglier) to review and fix and one almost seven weeks to work on
> bug killing before 1.3 goes gold.
>
> Thanks for reporting, following and contributing to the solution of
> this old issue, and for your patience.
>
> --
> Ramiro Morales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Hi all,

Thanks for checking in 14910!

Could anyone take a serious look at
http://code.djangoproject.com/ticket/14924

It has a test that proves the problem and a relatively simple patch.

I'm doing a lot of "app overriding" and this bug is extremely annoying
in that case. It would be great if the fix could still make it to 1.3

thanks,
Klaas

On Dec 20, 2:22 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> Ok, I split it out:
>
> Documentation incorrect: (incl. 
> patch)http://code.djangoproject.com/ticket/14910
>
> Code incorrect: (patch w/ test) http://code.djangoproject.com/ticket/14924
>
> Please review,
> Klaas
>
> On Dec 19, 1:13 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > To be a bit more specific:
>
> > I've filedhttp://code.djangoproject.com/ticket/14910
>
> > Added a test that proves the bug. Provided code that makes that test
> > green. Fixed the documentation. All including patches.
>
> > Could someone with sufficient authority move this forward?  > trolling remark about the state of the community here to draw
> > attention to this ticket>
>
> > Much obliged,
> > Klaas
>
> > On Dec 16, 3:25 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
> > wrote:
>
> > > ♫ Tom ♩ tie ♭♬ tom ♪
>
> > >http://code.djangoproject.com/ticket/14910
>
> > > On Dec 5, 11:37 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> > > wrote:
>
> > > > Replying to myself here.
>
> > > > I'm quite sure the docs are wrong by now.
>
> > > > Also: I think the documented behavior is not desirable. Changing
> > > > translations per-view makes for hard to debug once-in-a-while bugs.
>
> > > > This means the bug '2' is still a problem. I suggest either reversing
> > > > the loop
>
> > > > 158         for appname in settings.INSTALLED_APPS:
>
> > > > or making the update of a 'merge' non-destructive.
>
> > > > Agreed? Should I move forward w/ tests, documentation update etc. in a
> > > > bug report?
>
> > > > On Dec 5, 11:21 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> > > > wrote:
>
> > > > > Hi,
>
> > > > > According 
> > > > > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> > > > > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> > > > > At runtime, Django looks for translations by following this algorithm:
>
> > > > > * First, it looks for a locale directory in the application directory
> > > > > of the view that’s being called. If it finds a translation for the
> > > > > selected language, the translation will be installed.
> > > > > * Next, it looks for a locale directory in the project directory. If
> > > > > it finds a translation, the translation will be installed.
> > > > > * Finally, it checks the Django-provided base translation in django/
> > > > > conf/locale.
>
> > > > > However, this has not been my experience. I also do not see anything
> > > > > in the django source code or tests that responds to the above.
>
> > > > > In django/utils/translation/trans_real.py I see the following:
>
> > > > > def translation(language):
> > > > >      [..]
>
> > > > >         for appname in settings.INSTALLED_APPS:
> > > > >             apppath = os.path.join(get_apppath(appname), 'locale')
>
> > > > >             if os.path.isdir(apppath):
> > > > >                 res = _merge(apppath)
>
> > > > > _merge (and deeper down "merge") is defined as a dictionary update in
> > > > > the same file.
>
> > > > > I see two problems here:
> > > > > 1] the documented behavior is not implemented
> > > > > 2] the implemented behavior has the opposite order-of-preference for
> > > > > apps as the rest of Django. (Normally, the higher up in your
> > > > > INSTALLED_APPS you put an app, the more likely it's templates, etc.
> > > > > will be called. Here we're using a dict update, so the lowest app has
> > > > > preference)
>
> > > > > Am I missing something? I've done some grepping but couldn't find any
> > > > > point where the "currently called view's app" is somehow related to
> > > > > the used translation.
> > > > > Should I file a bug? And if so: should we fix the documentation or the
> > > > > code?
>
> > > > >Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Ok, I split it out:

Documentation incorrect: (incl. patch)
http://code.djangoproject.com/ticket/14910

Code incorrect: (patch w/ test)
http://code.djangoproject.com/ticket/14924

Please review,
Klaas

On Dec 19, 1:13 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> Hi all,
>
> To be a bit more specific:
>
> I've filedhttp://code.djangoproject.com/ticket/14910
>
> Added a test that proves the bug. Provided code that makes that test
> green. Fixed the documentation. All including patches.
>
> Could someone with sufficient authority move this forward?  trolling remark about the state of the community here to draw
> attention to this ticket>
>
> Much obliged,
> Klaas
>
> On Dec 16, 3:25 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > ♫ Tom ♩ tie ♭♬ tom ♪
>
> >http://code.djangoproject.com/ticket/14910
>
> > On Dec 5, 11:37 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> > wrote:
>
> > > Replying to myself here.
>
> > > I'm quite sure the docs are wrong by now.
>
> > > Also: I think the documented behavior is not desirable. Changing
> > > translations per-view makes for hard to debug once-in-a-while bugs.
>
> > > This means the bug '2' is still a problem. I suggest either reversing
> > > the loop
>
> > > 158         for appname in settings.INSTALLED_APPS:
>
> > > or making the update of a 'merge' non-destructive.
>
> > > Agreed? Should I move forward w/ tests, documentation update etc. in a
> > > bug report?
>
> > > On Dec 5, 11:21 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> > > wrote:
>
> > > > Hi,
>
> > > > According 
> > > > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> > > > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> > > > At runtime, Django looks for translations by following this algorithm:
>
> > > > * First, it looks for a locale directory in the application directory
> > > > of the view that’s being called. If it finds a translation for the
> > > > selected language, the translation will be installed.
> > > > * Next, it looks for a locale directory in the project directory. If
> > > > it finds a translation, the translation will be installed.
> > > > * Finally, it checks the Django-provided base translation in django/
> > > > conf/locale.
>
> > > > However, this has not been my experience. I also do not see anything
> > > > in the django source code or tests that responds to the above.
>
> > > > In django/utils/translation/trans_real.py I see the following:
>
> > > > def translation(language):
> > > >      [..]
>
> > > >         for appname in settings.INSTALLED_APPS:
> > > >             apppath = os.path.join(get_apppath(appname), 'locale')
>
> > > >             if os.path.isdir(apppath):
> > > >                 res = _merge(apppath)
>
> > > > _merge (and deeper down "merge") is defined as a dictionary update in
> > > > the same file.
>
> > > > I see two problems here:
> > > > 1] the documented behavior is not implemented
> > > > 2] the implemented behavior has the opposite order-of-preference for
> > > > apps as the rest of Django. (Normally, the higher up in your
> > > > INSTALLED_APPS you put an app, the more likely it's templates, etc.
> > > > will be called. Here we're using a dict update, so the lowest app has
> > > > preference)
>
> > > > Am I missing something? I've done some grepping but couldn't find any
> > > > point where the "currently called view's app" is somehow related to
> > > > the used translation.
> > > > Should I file a bug? And if so: should we fix the documentation or the
> > > > code?
>
> > > >Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Hi all,

To be a bit more specific:

I've filed
http://code.djangoproject.com/ticket/14910

Added a test that proves the bug. Provided code that makes that test
green. Fixed the documentation. All including patches.

Could someone with sufficient authority move this forward? 

Much obliged,
Klaas


On Dec 16, 3:25 pm, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> ♫ Tom ♩ tie ♭♬ tom ♪
>
> http://code.djangoproject.com/ticket/14910
>
> On Dec 5, 11:37 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > Replying to myself here.
>
> > I'm quite sure the docs are wrong by now.
>
> > Also: I think the documented behavior is not desirable. Changing
> > translations per-view makes for hard to debug once-in-a-while bugs.
>
> > This means the bug '2' is still a problem. I suggest either reversing
> > the loop
>
> > 158         for appname in settings.INSTALLED_APPS:
>
> > or making the update of a 'merge' non-destructive.
>
> > Agreed? Should I move forward w/ tests, documentation update etc. in a
> > bug report?
>
> > On Dec 5, 11:21 am,Klaasvan Schelven <klaasvanschel...@gmail.com>
> > wrote:
>
> > > Hi,
>
> > > According 
> > > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> > > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> > > At runtime, Django looks for translations by following this algorithm:
>
> > > * First, it looks for a locale directory in the application directory
> > > of the view that’s being called. If it finds a translation for the
> > > selected language, the translation will be installed.
> > > * Next, it looks for a locale directory in the project directory. If
> > > it finds a translation, the translation will be installed.
> > > * Finally, it checks the Django-provided base translation in django/
> > > conf/locale.
>
> > > However, this has not been my experience. I also do not see anything
> > > in the django source code or tests that responds to the above.
>
> > > In django/utils/translation/trans_real.py I see the following:
>
> > > def translation(language):
> > >      [..]
>
> > >         for appname in settings.INSTALLED_APPS:
> > >             apppath = os.path.join(get_apppath(appname), 'locale')
>
> > >             if os.path.isdir(apppath):
> > >                 res = _merge(apppath)
>
> > > _merge (and deeper down "merge") is defined as a dictionary update in
> > > the same file.
>
> > > I see two problems here:
> > > 1] the documented behavior is not implemented
> > > 2] the implemented behavior has the opposite order-of-preference for
> > > apps as the rest of Django. (Normally, the higher up in your
> > > INSTALLED_APPS you put an app, the more likely it's templates, etc.
> > > will be called. Here we're using a dict update, so the lowest app has
> > > preference)
>
> > > Am I missing something? I've done some grepping but couldn't find any
> > > point where the "currently called view's app" is somehow related to
> > > the used translation.
> > > Should I file a bug? And if so: should we fix the documentation or the
> > > code?
>
> > >Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

♫ Tom ♩ tie ♭♬ tom ♪

http://code.djangoproject.com/ticket/14910

On Dec 5, 11:37 am, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> Replying to myself here.
>
> I'm quite sure the docs are wrong by now.
>
> Also: I think the documented behavior is not desirable. Changing
> translations per-view makes for hard to debug once-in-a-while bugs.
>
> This means the bug '2' is still a problem. I suggest either reversing
> the loop
>
> 158         for appname in settings.INSTALLED_APPS:
>
> or making the update of a 'merge' non-destructive.
>
> Agreed? Should I move forward w/ tests, documentation update etc. in a
> bug report?
>
> On Dec 5, 11:21 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > According 
> > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> > At runtime, Django looks for translations by following this algorithm:
>
> > * First, it looks for a locale directory in the application directory
> > of the view that’s being called. If it finds a translation for the
> > selected language, the translation will be installed.
> > * Next, it looks for a locale directory in the project directory. If
> > it finds a translation, the translation will be installed.
> > * Finally, it checks the Django-provided base translation in django/
> > conf/locale.
>
> > However, this has not been my experience. I also do not see anything
> > in the django source code or tests that responds to the above.
>
> > In django/utils/translation/trans_real.py I see the following:
>
> > def translation(language):
> >      [..]
>
> >         for appname in settings.INSTALLED_APPS:
> >             apppath = os.path.join(get_apppath(appname), 'locale')
>
> >             if os.path.isdir(apppath):
> >                 res = _merge(apppath)
>
> > _merge (and deeper down "merge") is defined as a dictionary update in
> > the same file.
>
> > I see two problems here:
> > 1] the documented behavior is not implemented
> > 2] the implemented behavior has the opposite order-of-preference for
> > apps as the rest of Django. (Normally, the higher up in your
> > INSTALLED_APPS you put an app, the more likely it's templates, etc.
> > will be called. Here we're using a dict update, so the lowest app has
> > preference)
>
> > Am I missing something? I've done some grepping but couldn't find any
> > point where the "currently called view's app" is somehow related to
> > the used translation.
> > Should I file a bug? And if so: should we fix the documentation or the
> > code?
>
> > Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Replying to myself here.

I'm quite sure the docs are wrong by now.

Also: I think the documented behavior is not desirable. Changing
translations per-view makes for hard to debug once-in-a-while bugs.

This means the bug '2' is still a problem. I suggest either reversing
the loop

158 for appname in settings.INSTALLED_APPS:

or making the update of a 'merge' non-destructive.

Agreed? Should I move forward w/ tests, documentation update etc. in a
bug report?

On Dec 5, 11:21 am, Klaas van Schelven <klaasvanschel...@gmail.com>
wrote:
> Hi,
>
> According 
> tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> At runtime, Django looks for translations by following this algorithm:
>
> * First, it looks for a locale directory in the application directory
> of the view that’s being called. If it finds a translation for the
> selected language, the translation will be installed.
> * Next, it looks for a locale directory in the project directory. If
> it finds a translation, the translation will be installed.
> * Finally, it checks the Django-provided base translation in django/
> conf/locale.
>
> However, this has not been my experience. I also do not see anything
> in the django source code or tests that responds to the above.
>
> In django/utils/translation/trans_real.py I see the following:
>
> def translation(language):
>      [..]
>
>         for appname in settings.INSTALLED_APPS:
>             apppath = os.path.join(get_apppath(appname), 'locale')
>
>             if os.path.isdir(apppath):
>                 res = _merge(apppath)
>
> _merge (and deeper down "merge") is defined as a dictionary update in
> the same file.
>
> I see two problems here:
> 1] the documented behavior is not implemented
> 2] the implemented behavior has the opposite order-of-preference for
> apps as the rest of Django. (Normally, the higher up in your
> INSTALLED_APPS you put an app, the more likely it's templates, etc.
> will be called. Here we're using a dict update, so the lowest app has
> preference)
>
> Am I missing something? I've done some grepping but couldn't find any
> point where the "currently called view's app" is somehow related to
> the used translation.
> Should I file a bug? And if so: should we fix the documentation or the
> code?
>
> Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Hi,

According to
http://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-in-your-own-projects
and
http://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-django-discovers-translations

At runtime, Django looks for translations by following this algorithm:

* First, it looks for a locale directory in the application directory
of the view that’s being called. If it finds a translation for the
selected language, the translation will be installed.
* Next, it looks for a locale directory in the project directory. If
it finds a translation, the translation will be installed.
* Finally, it checks the Django-provided base translation in django/
conf/locale.

However, this has not been my experience. I also do not see anything
in the django source code or tests that responds to the above.

In django/utils/translation/trans_real.py I see the following:

def translation(language):
 [..]

for appname in settings.INSTALLED_APPS:
apppath = os.path.join(get_apppath(appname), 'locale')

if os.path.isdir(apppath):
res = _merge(apppath)

_merge (and deeper down "merge") is defined as a dictionary update in
the same file.

I see two problems here:
1] the documented behavior is not implemented
2] the implemented behavior has the opposite order-of-preference for
apps as the rest of Django. (Normally, the higher up in your
INSTALLED_APPS you put an app, the more likely it's templates, etc.
will be called. Here we're using a dict update, so the lowest app has
preference)

Am I missing something? I've done some grepping but couldn't find any
point where the "currently called view's app" is somehow related to
the used translation.
Should I file a bug? And if so: should we fix the documentation or the
code?

Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Localization fix

[Klaas van Schelven]

Hi all,

Subtly drawing attention to
http://code.djangoproject.com/ticket/14807

A minor fix including test.

Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Doc. patch

[Klaas van Schelven]

Hi,

I believe it is customary to politely ask for attention for bugs on
this list.

http://code.djangoproject.com/ticket/14704

Contains a minor patch to the documentation that would have saved me
some headaches this afternoon.


Klaas van Schelven

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ordering Check in django/core/management/validation.py

[Klaas van Schelven]

http://code.djangoproject.com/ticket/14513

Now give me my bonus points :-)

On Oct 20, 1:05 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Oct 20, 2010 at 6:43 PM, Klaas van Schelven
>
> <klaasvanschel...@gmail.com> wrote:
> > Hi,
>
> > I'm not sure I'm following protocol here, but here it goes...
>
> The best way to report this is to open a ticket [1] which describes
> the problem in detail (which is what you've done here). This ensure
> that we have a formal way of tracking that the issue exists, when it
> is resolved, etc.
>
> For bonus points, if you're able to generate a source code diff that
> contains the fix you propose, that will make it easier for us to make
> the change.
>
> For double bonus points, if your diff includes a test case that
> verifies the problem exists, and that your patch fixes it, you make it
> very easy for us to make the change.
>
> Tests for model validation usually live in
> tests/modeltests/invalid_models, which is a list of models known to
> have model problems, followed by a list of the problems that Django
> reports.
>
> [1]http://code.djangoproject.com/simpleticket
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ordering Check in django/core/management/validation.py

[Klaas van Schelven]

Hi,

I'm not sure I'm following protocol here, but here it goes...

django/core/management/validation.py, both in the current trunk and in
1.2.3

It says in the accompanying comment:
# Skip ordering in the format field1__field2 (FIXME:
checking
# this format would be nice, but it's a little
fiddly).

However, the actual check is for only one "_"
Which leads fieldnames which contain underscores to not be checked for
ordering;

The patch would be something like this:

260c260
< if '__' in field_name:
---
> if '_' in field_name:

Good luck,
Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based models

[Klaas van Schelven]

Sorry, missed your reply somehow,
>
> The line in question, however, should respect subclasses. So your
> example wouldn't fail in the case of a proper subclass.
>

I've heard this claim before,
But per my example above it doesn't. What am I doing wrong there?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based models

[Klaas van Schelven]

There's a quite a few things that I don't like about the get_model
approach. I'll focus on one though: contrib.comment's own models do
not respect it.

Consider a customized model for comments (the model MyComment in
my_comments)
so in settings.py we put:
COMMENTS_APP = 'my_comments'

then we do the following:
from django.contrib.comments.models import CommentFlag
flag = CommentFlag()
from django.contrib.comments import get_model
mycomment = get_model().objects.get()
flag.comment = mycomment

Traceback (most recent call last):
  File "", line 1, in 
  File "...django/db/models/fields/related.py", line 318, in __set__
self.field.name, self.field.rel.to._meta.object_name))
ValueError: Cannot assign "":
"CommentFlag.comment" must be a "Comment" instance.

You see the problem? Any help thinking about the solution is much
appreciated.

Klaas

On Sep 27, 7:57 pm, "subs...@gmail.com" <subs...@gmail.com> wrote:
> I thought that's what get_model did?
>
> You specify your own comments app and register your own (subclass or
> other) model within that function and its used throughout the original
> app.
>
> On Sep 27, 3:02 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
> > On Sep 27, 4:17 am, "subs...@gmail.com" <subs...@gmail.com> wrote:
>
> > > I may be dense but is this the functional equiv of cobtrib.comments
> > > get_model()?
>
> > Nope.
> > Rather, it's a way to subclass models that are provided by reusable
> > apps, and letting the reusable app use the subclassed instance
> > throughout.
>
> > > On Sep 26, 8:28 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> > > wrote:
>
> > > > Hi all,
>
> > > > I'm looking for a bit of input for making Django's apps a bit more
> > > > extendable, either by modifying Django or (preferably) by coming up
> > > > with a common language on top op Django. The main painpoint are
> > > > extendable models. The idea of 'extendable' is that models from
> > > > reusable apps can be extended in any concrete project. The reusable
> > > > apps should refer to their own models in such a way that they will get
> > > > the concrete implementation (extension).
> > > > Class based models if you will.
>
> > > > Context can be found 
> > > > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > > > Currently, apps usually refer to their own models by simply importing
> > > > them from models.py and referring to them. This obviously will not
> > > > work, so any solution will need some kind of registry, or instance of
> > > > "app". If "app" is an instance of a class referring to it can be done
> > > > in an extendible way (simply by using Python's inheritance mechanism).
>
> > > > I've put an example of this approach 
> > > > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > > > Which incorporates the above idea of an app class & instance in blog/
> > > > __init__.py.
>
> > > > abstract_blog/abstract_models.py and blog/models.py
>
> > > > The key sections are:
> > > > (in abstract_models)
>
> > > >     def get_AbstractPage(self):
> > > >         class AbstractPage(models.Model):
> > > >             body = models.TextField()
> > > >             category = models.ForeignKey(self.app.models.Category)
>
> > > >             class Meta:
> > > >                 abstract = True
> > > >                 #app_label = 'abstract_blog'
> > > >         return AbstractPage
> > > >     AbstractPage = property(get_AbstractPage)
>
> > > > (in models)
> > > >     def get_Category(self):
> > > >         class Category(self.AbstractCategory):
> > > >             some_added_field = models.IntegerField()
> > > >         return Category
> > > >     Category = property(get_Category)
>
> > > > As you can see, it is possible to refer to "the apps real
> > > > implementation of Category" (self.app.models.Category, or just
> > > > self.Category) from the abstract model. Less neat: the cruft that's
> > > > needed to pass self into AbstractPage for reference (3 lines per
> > > > class: def, return & property).
>
> > > > In a more recent version I've managed to factor those lines away at
> > > > the cost of a lot of 
> &

Re: Class based models

[Klaas van Schelven]

On Sep 27, 4:17 am, "subs...@gmail.com" <subs...@gmail.com> wrote:
> I may be dense but is this the functional equiv of cobtrib.comments
> get_model()?

Nope.
Rather, it's a way to subclass models that are provided by reusable
apps, and letting the reusable app use the subclassed instance
throughout.

>
> On Sep 26, 8:28 am, Klaas van Schelven <klaasvanschel...@gmail.com>
> wrote:
>
>
>
> > Hi all,
>
> > I'm looking for a bit of input for making Django's apps a bit more
> > extendable, either by modifying Django or (preferably) by coming up
> > with a common language on top op Django. The main painpoint are
> > extendable models. The idea of 'extendable' is that models from
> > reusable apps can be extended in any concrete project. The reusable
> > apps should refer to their own models in such a way that they will get
> > the concrete implementation (extension).
> > Class based models if you will.
>
> > Context can be found 
> > here:http://groups.google.com/group/django-users/browse_thread/thread/2287...
>
> > Currently, apps usually refer to their own models by simply importing
> > them from models.py and referring to them. This obviously will not
> > work, so any solution will need some kind of registry, or instance of
> > "app". If "app" is an instance of a class referring to it can be done
> > in an extendible way (simply by using Python's inheritance mechanism).
>
> > I've put an example of this approach 
> > here:http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862ce...
>
> > Which incorporates the above idea of an app class & instance in blog/
> > __init__.py.
>
> > abstract_blog/abstract_models.py and blog/models.py
>
> > The key sections are:
> > (in abstract_models)
>
> >     def get_AbstractPage(self):
> >         class AbstractPage(models.Model):
> >             body = models.TextField()
> >             category = models.ForeignKey(self.app.models.Category)
>
> >             class Meta:
> >                 abstract = True
> >                 #app_label = 'abstract_blog'
> >         return AbstractPage
> >     AbstractPage = property(get_AbstractPage)
>
> > (in models)
> >     def get_Category(self):
> >         class Category(self.AbstractCategory):
> >             some_added_field = models.IntegerField()
> >         return Category
> >     Category = property(get_Category)
>
> > As you can see, it is possible to refer to "the apps real
> > implementation of Category" (self.app.models.Category, or just
> > self.Category) from the abstract model. Less neat: the cruft that's
> > needed to pass self into AbstractPage for reference (3 lines per
> > class: def, return & property).
>
> > In a more recent version I've managed to factor those lines away at
> > the cost of a lot of 
> > magic.http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb6...
>
> > class AbstractModels(object):
> >     #...
> >     class AbstractPage(shmodels.Model):
> >         body = shmodels.TextField()
> >         category =
> > shmodels.ForeignKey(Zelf("app.models.Category"))
>
> > Neet uh? Self referral without an actual introduction of "self".
>
> > I may look for the general case of Zelf & Zelf2 and shmodels and
> > whatever... but I'd like to know that this is a path worth following.
> > In other words: am I missing really obvious, more simple solutions
> > here?
>
> > ciao,
> > Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Class based models

[Klaas van Schelven]

Hi all,

I'm looking for a bit of input for making Django's apps a bit more
extendable, either by modifying Django or (preferably) by coming up
with a common language on top op Django. The main painpoint are
extendable models. The idea of 'extendable' is that models from
reusable apps can be extended in any concrete project. The reusable
apps should refer to their own models in such a way that they will get
the concrete implementation (extension).
Class based models if you will.

Context can be found here:
http://groups.google.com/group/django-users/browse_thread/thread/22875fd287d0aa81/313b7bb67f24ad2f

Currently, apps usually refer to their own models by simply importing
them from models.py and referring to them. This obviously will not
work, so any solution will need some kind of registry, or instance of
"app". If "app" is an instance of a class referring to it can be done
in an extendible way (simply by using Python's inheritance mechanism).

I've put an example of this approach here:
http://bitbucket.org/vanschelven/extendible_app_experiment/src/0862cecb358d

Which incorporates the above idea of an app class & instance in blog/
__init__.py.

abstract_blog/abstract_models.py and blog/models.py

The key sections are:
(in abstract_models)

def get_AbstractPage(self):
class AbstractPage(models.Model):
body = models.TextField()
category = models.ForeignKey(self.app.models.Category)

class Meta:
abstract = True
#app_label = 'abstract_blog'
return AbstractPage
AbstractPage = property(get_AbstractPage)

(in models)
def get_Category(self):
class Category(self.AbstractCategory):
some_added_field = models.IntegerField()
return Category
Category = property(get_Category)

As you can see, it is possible to refer to "the apps real
implementation of Category" (self.app.models.Category, or just
self.Category) from the abstract model. Less neat: the cruft that's
needed to pass self into AbstractPage for reference (3 lines per
class: def, return & property).

In a more recent version I've managed to factor those lines away at
the cost of a lot of magic.
http://bitbucket.org/vanschelven/extendible_app_experiment/src/2b8eb68e8ee5

class AbstractModels(object):
#...
class AbstractPage(shmodels.Model):
body = shmodels.TextField()
category =
shmodels.ForeignKey(Zelf("app.models.Category"))

Neet uh? Self referral without an actual introduction of "self".

I may look for the general case of Zelf & Zelf2 and shmodels and
whatever... but I'd like to know that this is a path worth following.
In other words: am I missing really obvious, more simple solutions
here?

ciao,
Klaas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: proposal for lazy foreignkeys

[Klaas van Schelven]

Some more cases that would be important (not just ForeignKey):

inheriting from the VirtualModel
any kind of relationship to it (manytomany)
ModelForms

On Sep 25, 7:47 pm, Carl Meyer  wrote:
> Hi all,
>
> I've seen some level of interest in the idea of a lazy foreign key
> (one whose target table is determined by project configuration in some
> way, not hardcoded by the app/model in which it lives). The idea was
> most recently brought up again in Eric Florenzano's keynote at
> DjangoCon. I have some ideas regarding possible API for this, and
> would be glad for feedback.
>
> First, a couple motivating use cases:
>
> 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and
> smell bad. They're good to have around when you really need to link to
> any one of a possibly-growing set of models. But currently reusable
> apps often use them anytime they want to link to "some domain model
> but we don't know which one" - even if in practice in most cases it
> will be only one! A lazy foreign key would be a better solution.
>
> 2. Standardization with flexibility: i.e. possible-future replacement
> of contrib.auth.User. To be clear, I am not at this point proposing
> any changes at all to contrib.auth. But in some future possible
> contrib.auth refactoring, a lazy foreign key could provide a way for
> reusable apps to point to a common User model, without Django having
> to provide a concrete implementation of that model.
>
> The concept:
>
> We introduce the "virtual" model, which is an abstract model with the
> following additional characteristics:
>
> - It can be the target of a ForeignKey.
> - It may only have one direct concrete subclass, and if it is the
> target of any ForeignKey it must have exactly one.
>
> At runtime, any ForeignKeys pointing to a virtual model are resolved
> to actually point to the concrete subclass of that virtual model.
>
> Like an abstract model, a virtual model may include fields, methods,
> etc. These can be considered the specification of an interface: any
> model with a ForeignKey to this virtual model can expect the concrete
> model to satisfy that interface. This is particularly helpful for a
> contrib.auth-type use case: reusable apps don't only need a User model
> to point FKs at, they also often need at least some minimal set of
> fields/properties they can rely on being present.
>
> It's not required for the virtual model to have any fields, of course:
> in some use cases (voting, tagging) the reusable app doesn't need to
> know anything at all about its target model. A hypothetical voting app
> could simply provide an empty "VotableObject" virtual model, which
> would be inherited by the domain model which can receive votes. Since
> Django already supports multiple inheritance for abstract models, this
> is a minimal and non-restrictive requirement for the domain model
> author.
>
> Advantages of this proposal:
>
> 1. No new settings.
> 2. In terms of new code API, almost nothing: a new "virtual = True"
> Meta keyword.
> 3. Very little conceptual overhead; reuses existing constructs as much
> as possible.
>
> I plan to put together a patch to show working code for this, but I'd
> be glad for any feedback at this point, especially if there are
> obvious conceptual problems I'm overlooking. Thanks!
>
> Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: proposal for lazy foreignkeys

[Klaas van Schelven]

Hi all,

My 2 cents.

I think the fact that you cannot have Foreign Keys link to specific
models is a specific instance of a larger problem. It's currently not
possible to make an app which has models with any kind of extended
(subclassed) behavior. Say I create a tagging app. Now I might want
to:

* Create a foreign key to a specific taggable model (the problem at
hand)
* Add weights to tags
* Add owners to tags
* ...

I think having this ability to extend models and pass the extended
versions back into the reusable app is the key missing feature.

Klaas


On Sep 25, 7:47 pm, Carl Meyer  wrote:
> Hi all,
>
> I've seen some level of interest in the idea of a lazy foreign key
> (one whose target table is determined by project configuration in some
> way, not hardcoded by the app/model in which it lives). The idea was
> most recently brought up again in Eric Florenzano's keynote at
> DjangoCon. I have some ideas regarding possible API for this, and
> would be glad for feedback.
>
> First, a couple motivating use cases:
>
> 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and
> smell bad. They're good to have around when you really need to link to
> any one of a possibly-growing set of models. But currently reusable
> apps often use them anytime they want to link to "some domain model
> but we don't know which one" - even if in practice in most cases it
> will be only one! A lazy foreign key would be a better solution.
>
> 2. Standardization with flexibility: i.e. possible-future replacement
> of contrib.auth.User. To be clear, I am not at this point proposing
> any changes at all to contrib.auth. But in some future possible
> contrib.auth refactoring, a lazy foreign key could provide a way for
> reusable apps to point to a common User model, without Django having
> to provide a concrete implementation of that model.
>
> The concept:
>
> We introduce the "virtual" model, which is an abstract model with the
> following additional characteristics:
>
> - It can be the target of a ForeignKey.
> - It may only have one direct concrete subclass, and if it is the
> target of any ForeignKey it must have exactly one.
>
> At runtime, any ForeignKeys pointing to a virtual model are resolved
> to actually point to the concrete subclass of that virtual model.
>
> Like an abstract model, a virtual model may include fields, methods,
> etc. These can be considered the specification of an interface: any
> model with a ForeignKey to this virtual model can expect the concrete
> model to satisfy that interface. This is particularly helpful for a
> contrib.auth-type use case: reusable apps don't only need a User model
> to point FKs at, they also often need at least some minimal set of
> fields/properties they can rely on being present.
>
> It's not required for the virtual model to have any fields, of course:
> in some use cases (voting, tagging) the reusable app doesn't need to
> know anything at all about its target model. A hypothetical voting app
> could simply provide an empty "VotableObject" virtual model, which
> would be inherited by the domain model which can receive votes. Since
> Django already supports multiple inheritance for abstract models, this
> is a minimal and non-restrictive requirement for the domain model
> author.
>
> Advantages of this proposal:
>
> 1. No new settings.
> 2. In terms of new code API, almost nothing: a new "virtual = True"
> Meta keyword.
> 3. Very little conceptual overhead; reuses existing constructs as much
> as possible.
>
> I plan to put together a patch to show working code for this, but I'd
> be glad for any feedback at this point, especially if there are
> obvious conceptual problems I'm overlooking. Thanks!
>
> Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.