Grid startup is always called at creation

[GoogleCodeExporter]

Grid.startup() is called at creation, this is fine in many cases. However
if you have a tab setup and the grid is not displayed in the visible tab at
startup you will not see the grid unless you call _refresh() or delay
startup() until that pane is selected.

This patch allows pane_id and parent_id to be passed to the grid and every
time that the parent_id changes tabs it will check if the pane the grid is
in is selected and call startup() if it is.

Further you can pass root_id for a higher row of tabs or some other
condition along with pane_id and parent_id. Either way as the startup
method is called the event will be unsubscribed.

Default behavior is the same as before, calling startup() during addOnLoad.

Original issue reported on code.google.com by mtthw.me...@gmail.com on 5 Aug 2009 at 3:15

Attachments:

• datagrid_disp.html

[GoogleCodeExporter]

Patch file attached.

Original comment by mtthw.me...@gmail.com on 5 Aug 2009 at 3:16

Attachments:

• datagrid_disp.html

[GoogleCodeExporter]

Minor change, added code to run startup if the window the grid is begins 
selected.

Original comment by mtthw.me...@gmail.com on 5 Aug 2009 at 4:39

Attachments:

• datagrid_disp.html

[GoogleCodeExporter]

Added the following two lines:
//This is a hack to work around the columns being resized wrong when data is 
loaded
dojo.connect(dojango._datagrid.{{id}}, "_onFetchBegin", 
dojango._datagrid.{{id}},
"prerender");

Original comment by mtthw.me...@gmail.com on 7 Aug 2009 at 1:35

Attachments:

• datagrid_disp.html

[GoogleCodeExporter]

Added a rendering fix for grids not in the first tab.
"//Without this is the grid will give a "this.headerContentNode.firstChild is 
null"
error if it is not in the first tab in a set.
dojango._datagrid.{{id}}.prerender();"

Original comment by mtthw.me...@gmail.com on 11 Aug 2009 at 6:18

Attachments:

• datagrid_disp.html

[GoogleCodeExporter]

Thanks for the patched datagrid. Will look at your changes and soon will commit 
it to
Dojango. At the moment i don't know, if that hack (about connecting to 
_onFetchBegin)
needs to be done within Dojango. Could be that this needs to be fixed within 
Dojo. Do
you have a hint, why you solved your problem like that, because i would like to
implement it without that hack.

Original comment by tobias.k...@googlemail.com on 18 Aug 2009 at 10:21

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

It is a problem that ultimately needs to be fixed in dojo, but until then I 
found a
way to work around the problem and included it so others would not have to 
track down
a workaround.  If I get the time I will check if it is fixed in the current 
nightly
build. http://bugs.dojotoolkit.org/changeset/19101 may fix it.

Original comment by mtthw.me...@gmail.com on 19 Aug 2009 at 12:33

[GoogleCodeExporter]

It appears to be fixed in the current nightly build from my initial testing.

Original comment by mtthw.me...@gmail.com on 19 Aug 2009 at 1:55

[GoogleCodeExporter]

Thanks for checking that. Then i would recommend that this hack isn't included 
within
dojango and users of the current Dojo version 1.3.2 should better add the patch 
from
revision 19101 or attach your hack externally somehow. Otherwise this would 
blow the
code and Dojango would have to handle different Dojo versions and different ways
handling problems. And this is what I would like to avoid.

Another thing I would like to do is to refactor your code, that not so much 
inline
javascript is created. A lot of that functionality could be wrapped into an 
extra
dojango js module. Something like:

dojango.grid.render(params);

This would make the code more maintainable. What do you about that?

Original comment by tobias.k...@googlemail.com on 19 Aug 2009 at 9:54

[GoogleCodeExporter]

Seeing as the bug is fixed in trunk I see on reason to include it in the code.  
If
you think there is a better way to wrap some of the functionality into another 
js
module feel free.

The only other thing to look into is the prerender() call.  You can just call
startup() and then refresh when the tab is selected, but there is a performance 
hit
as it will have to load the ajax data when the page loads and then again when 
you
select the tab. From what I saw the problem is that until prerender() or some
function it calls is done the nodes are not created and this causes problems. 
If you
can think of a more elegant way of doing it go ahead.

Original comment by mtthw.me...@gmail.com on 19 Aug 2009 at 10:20

[GoogleCodeExporter]

Is that already fixed in the current dojo code?

Original comment by tobias.k...@googlemail.com on 9 Apr 2010 at 10:58