Opened 13 years ago

Last modified 13 years ago

#6183 closed defect

a Tree nodes' contentNode inadequate when multi-referenced by a single dataStore item — at Initial Version

Reported by: guest Owned by:
Priority: high Milestone: 1.2
Component: Dijit Version: 1.0
Keywords: Tree Data item node onclick issue problem reference referenced Cc:
Blocked By: Blocking:

Description

a Tree nodes' contentNode inadequate when multi-referenced by a single dataStore item.

(Tested as functional against the following browsers:

IE version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Safari Version 3.0 (522.11.3)

)

(NOTE: selections in a tree will be referred to as NODES, while there corresponding counterparts in the dataStore will be referred to as an ITEM)

consider the following example: http://public.dev.whmi.biz/rheaghen/places3.html

notice, when a node gets clicked, it's iconClass switches to visually display an icon with or without a checkmark.

At this point, please make sure to expand to view both Kansas City Nodes. Click a single Kansas City Node a few times, the do the same to the Opposite Kansas City Node. You should notice that only one of these nodes, not the other, will receive this white checkmark.

The _onSetItem(/*dataStore item*/ item) dijit/Tree.js(890) method is going about this the wrong way. since there are 2 Kansas City's, it is impossible to ask for the correct node given a shared item. The Tree widget is thus unable to return the appropriate node for this scenario because there was never a unique correlation between the 2 Kansas City nodes to there shared item in the DataStore?.

Because this is an onclick method, I can simply add the node parameter to my onclick definition, store the last clicked node as a global variable, and simply implement my own onset for the hitched apply. However if there were an event that were to fire that required souly on the infrastructure of this system, I'm not sure how this should be properly resolved, so for now I leave it to you. but I suggest that the identity of a node to become context driven; so that the path from the top down be the link to the actual node (exp: foo-->bar-->yak ~ yak's identity would be foo.bar.yak)

My Work Around Solution: http://public.dev.whmi.biz/rheaghen/places4.html

Change History (0)

Note: See TracTickets for help on using tickets.