satchmo_store.shop.context_processors.settings set too generic context names

Issue #1266 open
Bruno Clermont created an issue

satchmo_store.shop.context_processors.settings set context variable with very generic names such as "categories".

When using satchmo with an other application (in my case django-helpdesk) that internally use categories variable name (in this case for it's own knowledge base categories).

Satchmo overwrite categories.

here: http://docs.djangoproject.com/en/1.2/ref/templates/api/#subclassing-context-requestcontext

it says:

When context processors are applied

When you use RequestContext, the variables you supply directly are added first, followed any variables supplied by context processors. This means that a context processor may overwrite a variable you've supplied, so take care to avoid variable names which overlap with those supplied by your context processors.

Comments (4)

  1. Chris Moffitt repo owner

    Are there any other name clashes you've seen. I'd prefer to make all the changes at once so we can just bit the bullet and deal with it in one fell swoop.

  2. Bruno Clermont reporter

    I didn't found anything else in both context_processors.py.

    Personally, I simply put a prefix to all my variables I put in my context ($myapp_$varname) except obvious variable that are set by other context processor, like media_url.

  3. Hynek Cernoch
    • changed status to open

    This would break some user templates. Bruno, why to change it in Satchmo and not in django-helpdesk or in both?

    Hmm, You can create a new unique name as alias and hold them both for long time. A name takes only several bytes.

    This path is enough for Bruno to work with unmodified Satchmo.

    'categories': all_categories, # for backward compatibility garanteed to ver. 0.9.... + 'blabla_categories': all_categories, 'is_secure' : request_is_secure(request),

    If django-helpdesk is good coded, it overwrites only categories, not blabla_categories.

    The new name can became preferred in templates for new installations after major update (0.9.2?) Some note in documentation how long will be an old name backward compatible?

  4. Bruno Clermont reporter

    I understand it will break some user templates. I didn't expected to see a change that will brake comptability with any stable release.

    For django-helpdes, I already open a pull-request in django-helpdesk: https://github.com/rossp/django-helpdesk/issues/unreads#issue/35

    The pull request is unread, so I'm actually using only my own fork.

    The pluggable nature of django framework applications, using general name such as categories is risky on collisions.

    Thanks!

  5. Log in to comment