#11234: BlockNode unsafely manages context
---------------------------------------------+------------------------------
          Reporter:  brutimus                |         Owner:  brutimus
            Status:  assigned                |     Milestone:          
         Component:  Template system         |       Version:  SVN     
        Resolution:                          |      Keywords:          
             Stage:  Design decision needed  |     Has_patch:  1       
        Needs_docs:  0                       |   Needs_tests:  1       
Needs_better_patch:  0                       |  
---------------------------------------------+------------------------------
Comment (by brutimus):

 Ah I think I see where the disconnect is on this issue; my fault.  I
 understand how all the push/pop logic works, but our issue has always been
 we've used context.update({}) (useful when setting multiple items) instead
 of going through !__setitem!__.  You're right in that if you just use
 dictionary access, it will add the variable to the current context layer,
 then the block node will remove that entire layer at the conclusion of the
 block.

 However, should the block node further "scope" the context?  I mean, if
 you add several more context layers from within a block node, should the
 block node remove all layers that have been added since the start of the
 block ...

 {{{
 context.dicts = context.dicts[context.dicts.index(stored_reference):]
 }}}

 This would prevent the issue of the block assuming position it's 0 if the
 context is mismanaged by a user and in essence create a truer "scope".

 From here, I would agree that having the public method for adding to the
 base context layer might not be a bad idea.  It might also be convenient
 to note in documentation (docstring/sphynx docs) the difference between
 using !__setitem!__ and update and/or clarification on how block nodes
 manage context layers like a true scope.  I could see how this might bite
 a user wanting to treat the context object like a typical dictionary.

 I suppose this is back to: design decision needed.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/11234#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to