Hi folks I'm using dojo tree with ForestStoreModel and ItemFileWriteStore. I'm seeking some out of the box way of adding tree items to the top of the Tree root. The default behaviour is to add items to the bottom of the tree. This is how I add stuffs on to the tree. (Dojo V 1.8)
this.model.newItem({ name:''+item.name+'', type: ''+item.type+''},parent);
answering this for future searchers. I'm quite new for js stuffs so I was mainly relying on DOJO API and documentations attached with them. I've tried to newItem insertion to a specific index using additional parameters as per the API. ie. (args,parent Item, insertIndex, before Item). I've also tried pasteitem method with these parameters (childItem , old parent Item,new parent Item,bcopy, insertIndex, before Item). Neither of them were successful. On the debugger, I tried to step in to these methods and found dojo treat bit differently when you pass root object as your parent object. So i've created a default root level element used that as the root element for my tree. Problem solved. All these functions started working. Unfortunately I couldn't find any documentation that specifies these functions doesn't support Root as the parent parameter. At least for these indexed based insertion purpose. I find it really strange though. I could be still wrong so may be some reader can elaborate on this later. Just putting this forward
Related
I've made a component that visualizes an object where array's and nested objects are collapsible.
It works by looping through all the keys/indexes and using the appropriate render function. Right now the collapse and extend actions are purely CSS class-based.
The issue I have right now is that I need to make it so the collapsed/extended state persists. So basically I need a way to store the collapsed state info. and read it later on. I'm not really sure how to even start.
The state should persist even when the object is modified. So when an new item gets pushed in the middle of the array it should still open the same thing. What data structure should I use for this and how would I read it?
The reason I'm not posting any code is that I don't think it's necessary, I'm purely interested in how the data should be structured for the collapsed/extended state of an array/object so it persists when updates are made to the object/array.
I've tried making some type of "breadcrumbs" that follow the structure of the object but then I realized that it won't persist when changes are made.
Any ideas? Is this even possible without some hardcoded unique ids?
Edit 1: point 4 it's not optimal and can be done better - after you finish rendering the main object to the DOM, loop through the state object and for each path, find the DOM node and expand it.
Edit 2: instead of 'index1.nestedIndex2[1].nestedIndex3' you can do 'index1.nestedIndex2.1.nestedIndex3', makes your code simpler
Edit 3: no need to use lodash (edited point 1)
I hope I understood your scenario correctly.
In order to persist the expanded (or collapsed) state, you have to:
create an object that stores the paths to the indexs that you want expanded, like this {'index1.nestedIndex2[1].nestedIndex3': true}. You can do this when clicking to expand. Of course, this means you should know the current index and it's parents when you click - one way to do this is by having a DOM attribute holding the index, on each element. So when you click a node to go up recursively until you reach the top element, and build that string path
Convert the state object to a string using JSON.stringify and store it in localStorage (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). localStorage.set('expandedState', JSON.stringify(stateObject)). If you need to store the state for multiple data objects, you have to use some specific key instead of 'expandedState'
In the code, before rendering the main object, convert the string state from localStorage back to an object using JSON.parse
While rendering your main object, you have to build the path for the currently rendered node and check if it can be found in the state object. If yes, expand it by adding your css class on it. To build back the path, it's more optimal to build it as you render each node rather than using the same method used in point 1, but that would also work (but slower, so for really big objects will be a problem, I think)
I am using a JavaScript library called PIXI and am looking for a way to "zoom" in my game. A search on the internet suggested that I put everything inside a DisplayObjectContainerand then resize it to simulate a zoom-effect.
The thing is that I already have Container (aka stage), and I think that is resizable too. So I don't understand the reason behind using a DisplayObjectContainerwhen you have a Containeralready. And frankly, I don't even see the difference between them.
This page says the following about DisplayObjectContainer:
A DisplayObjectContainer represents a collection of display objects. It is the base class of all display objects that act as a container for other objects.
This other page says the following about Container:
A Container represents a collection of display objects. It is the base class of all display objects that act as a container for other objects.
The only possible scenario I can imagine is that one of these container-objects is outdated and belongs to an older version of PIXI, which isn't too unrealistic since PIXI is rather new and could change a lot. But this is just a guess.
The guess is correct. DisplayObjectContainer is outdated and replaced with Container.
I have two trees on the same page. The first is http://bl.ocks.org/1249394, and the other is http://bl.ocks.org/2503502. I followed the examples on these 2 links for my trees, with some alterations of course. I have included both on the same page. However the click functions seem to be conflicting. The tree at http://bl.ocks.org/1249394 works great, but the tree at http://bl.ocks.org/2503502 generates the tree with the correct data, but then when I click the root node to collapse, the child nodes data changes to that of the child nodes data for the first tree at http://bl.ocks.org/1249394. How do I fix this conflict?
Have you tried just naming the click handlers differently? This looks like you've got identically-named functions that might be in the same scope, so you should either
make sure each graph is in a different scope (e.g. enclose all the code for each in different functions), or
make sure all the functions on the page have unique names, or
both.
I'm trying to figure out how layers in Ext work. The documentation is very concise and I can't find a lot about them anywhere else, other than a forum thread where Jack Slocum says they're very simple.
I have a working tree panel, and what I'm now trying to do is put that in a layer so it floats over the page (it's meant as a helper dialog that pops up next to a form element). I've only gotten as far as creating a simple layer with a <div> element in it, but can't get it to contain more advanced stuff. Looking at the Combo source, which uses a Layer for the option list, also didn't make me much wiser.
So, can someone with a little more experience on this subject please tell me: how are you really supposed to use Ext.Layer? Or am I "doing it wrong"? :)
An Ext.Layer is an extension of Ext.element, rather than being an extension of Ext.Component.
Ext.Element doesn't benefit from all the component config options and methods that say an Ext.Panel does, and so you're going to have a much harder time adding a tree panel to an Ext.Layer than if you added the tree panel to an Ext.Window which already benefits from shim and shadow (the two main reasons you would want to use an Ext.Layer).
But before I would resort to using Ext.Window to wrap the tree panel, I would take a look at the shadow config option in tree panel which should provide the 'floating' effect you want...
true (or a valid Ext.Shadow Ext.Shadow.mode value) to display a shadow behind the panel, false to display no shadow (defaults to 'sides'). Note that this option only applies when floating = true.
I have a YUI Treeview that allows selection with checkboxes. After some operations, I destroy the tree (with tree.destroy()), and then create a new tree using the same containerID. This new tree should allow selection using checkboxes, but does not. What could be causing this?
If you've got some code, that'd be helpful, but in general the destroy method cleans up the JavaScript side of things (listeners, etc.), but doesn't necessarily clean up all of the markup. If you want to use the same ID, it'd consider removing that ID from the DOM to clean out all of it's children and then recreating it and then building the tree. I'm guessing that's not super helpful, but maybe if you can explain your use case a little more, I can offer some better suggestions.