Opened 12 years ago

Last modified 7 years ago

#10764 closed defect

Tree in an AccordionPane not yet focused will call fetch() from its store and render itself — at Version 1

Reported by: OakBehringer Owned by:
Priority: low Milestone: 1.13
Component: Dijit Version: 1.4.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Bill Keese asked me to log this here.

A tree in an AccordionPane? that is not yet focused will call fetch() from its store and render itself. I would like to defer this behavior until the pane is focused. It makes sense as the data is not yet used, it shouldn't be requested until needed.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ""><html xmlns="" xml:lang="en">
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<link rel="stylesheet" type="text/css" href="/js/src/dijit/themes/tundra/tundra.css" />
	<link rel="stylesheet" type="text/css" href="/js/src/dijit/themes/dijit.css" />
	<script type="text/javascript" src="/js/src/dojo/dojo.js" djConfig="parseOnLoad:true"></script>
	<script type="text/javascript">
			var store = new{ url: "/url/doesnt/matter/" });
			var treeModel = new dijit.tree.ForestStoreModel({
				store: store,
				query: { "type": "continent" },
				rootId: "root",
				rootLabel: "Continents",
				childrenAttrs: ["children"]
			new dijit.Tree({ model: treeModel }, "treeOne");
<body class="tundra">
	<div dojoType="dijit.layout.AccordionContainer" style="height: 400px;">
		<div dojoType="dijit.layout.AccordionPane" title="Pane1">
			The tree in Pane 2 attempts to render / call store.fetch() before scrolling into view.<br />
			(the url for the store will fail, but it still demonstrates that fetch has been called)
		<div dojoType="dijit.layout.AccordionPane" title="Pane2"><div id="treeOne"></div></div>

Our discussion can be read here:

I'm not sure if this is a bug or feature request, but Bill made it seem like a bug.

Change History (1)

comment:1 Changed 12 years ago by bill

Description: modified (diff)

It turns out that Tree.postCreate() calls this._load() and does other loading-related execution. I guess I should change Tree to defer that operation until the first resize() call, but only if there's a parent widget with isLayoutContainer defined.

Need to keep the old behavior otherwise; we can't move the loading code to startup() since existing apps may not even be calling Tree.startup().

I want to give this a little more thought, because I'm a little wary of deferring loading until a widget is made visible, because there are a lot of widgets where the equivalent change could be made (FilteringSelect, !Grid, etc.), so it seems like a big decision.

I assume that in your actual application you are using a client-server store rather than ItemFileReadStore?

Note: See TracTickets for help on using tickets.