818: Name conflict in djblets.datagrid.grids.DataGrid

iamzh*****@gmai***** (Google Code) (Is this you? Claim this profile.)
March 24, 2009 
If there is a column in the subclass of DataGrid, e.g.:

from djblets.datagrid.grids import Column, DataGrid

class TicketDataGrid(DataGrid):
    id = Column(_("id"), sortable=True)

The datagrid will raise a exception like this:

Traceback:
File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in
get_response
  86.                 response = callback(request, *callback_args,
**callback_kwargs)
File "C:\Python25\Lib\site-packages\django\contrib\auth\decorators.py" in
__call__
  67.             return self.view_func(request, *args, **kwargs)
File "D:\myproject\myprj\..\myprj\views.py" in index
  44.         'title': _('myprj'),
File
"C:\Python25\lib\site-packages\djblets-0.4.dev_20090116-py2.5.egg\djblets\datagrid\grids.py"
in render_to_response
  564.         self.load_state()
File
"C:\Python25\lib\site-packages\djblets-0.4.dev_20090116-py2.5.egg\djblets\datagrid\grids.py"
in load_state
  379.             column.active = True

Exception Type: AttributeError at /
Exception Value: 'str' object has no attribute 'active'

I found this is due to DataGrid already has a member named id. After I
change it to id_, it works well.

As we know, many data tables have the field named id, so it's better to
rename the DataGrid member "id" to a unique name (or a weired one ;) ). And
I guess the other DataGrid members (page, page_num ,...) are in the same
situation.
#1 timw.a******@gmai***** (Google Code) (Is this you? Claim this profile.) 
Consider an alternative (to the original poster): namespace your fields. Since Django
doesn't do so already, consider providing your own helper,
def _colname(unqualifiedName):
    return "my_namespace_" + unqualifiedName

Then use _colname() everywhere you name a column. The rb authors could do this to,
but they are the purveyor of the base model, so that doesn't seem like it warrants
namespacing.

If you're referring to the 'id' python class member, then you might be SOL (I have
next to no python experience). If that's the case, then it probably makes sense for
there to be a 'best practice' for explicitly namespacing your fields when you extend
classes you didn't write and/or don't control (in some languages, you can be warned
when you are accidentally overriding/shadowing a method/field, but I am not sure that
would be possible in python).
#2 iamzh*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Adding a prefix/suffix to the column should work. But it will effect many of my
exsited codes. So I prefer to address this issue in djblets. I guess most guys using
djblets as a kind of add-on.
david
#3 david 
Yeah, I don't think this is really worth changing. Use a different name in your
extended class.
  • +WontFix
#4 bur****@gmai***** (Google Code) (Is this you? Claim this profile.) 
Please reconsider this issue solution.
Ideal solution is moving all internal data to some self._meta class, like in django models.
Changes are quite simple.
If you can't, then please raise properly named exception when user tries to add a column with name that's used 
within DataGrid class.
Current exception just doesn't explain anything, and that's awful.
Should I contribute a patch?
#5 iamzh*****@gmai***** (Google Code) (Is this you? Claim this profile.) 
It's a good idea. Wrap the internal fields to a named subclass can mitigate the name
pollution.