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.
Related
Update: Added a collage of the images I was going to add to get around reputation block
I've been working on a cytoscape implementation that will dynamically display information I'm pulling from my database onto a webpage. The goal is to be an organization chart, displaying nodes in groups, in a directed tree structure. I've been doing a lot of research, and trying out several different layouts and api options to try and meet the use case, but I'm having issues getting it to work the way I'm intending.
Specifically I want to use compound nodes - the parents being the people's ranks. I've learned that a lot of layouts simply haven't been designed with compound nodes in mind, and I've been trying different implementations, including ones that create an initial layout, and then try to run a secondary layout specifically on the descendants of the parents.
Following are the closest of what I've tried and their issues:
Images of graphs: https://i.stack.imgur.com/6hzVS.png
cose-bilkent:
The main issue with this is that it doesn't seem to be meant for directed trees, but rather decides placement on its own. The bigger issue I've had is that I couldn't find a way to spread the nodes out better within their groups. I've tried to use the node padding options included, but they haven't had an affect, which I'm assuming is due to the compound nature.
grid:
Graph is in a perfectly grid like layout of all the nodes, but ignores parent nodes.
This layout was working for me initially, and would have the benefit of being able to easily change the amount of people per column. As I changed the elements though I realized it was a coincidence that it worked initially - it seems like it's totally ignoring the parent nodes, which is understandable if it wasn't designed with them in mind.
grid - descendants:
Graph is of the two sets of descendants layered on top of each other.
What I tried next was using a different layout to determine the initial placing of the parents, and then performing a grid layout on the descendants to make them organized in their groups. I realized then that parents are simply reacting to their child's placement. Also, it appears that calling layouts on sets of nodes separately for grid was completely ignoring anything else that exists on the graph, causing the groups to be put on top of each other.
cola:
It's close, but the way it puts them on the graph is not well structured, causing the placement in the groups to be jumbled up, though they are spaced out enough.
This appears it would work great if I could figure out how to run a proper layout on the parent nodes, forcing the tree structure that works without compound nodes.
Here is more or less what I'd like to see, though the logic for # of nodes per column isn't that important. As long as they're organized neatly:
https://i.stack.imgur.com/irVaK.png
Is there any advice someone could give on how I could go about making this work? I haven't been able to find any layout setups that work quite right, and I don't really know what to do from here. I would also prefer to avoid creating an entirely new layout from scratch. Any help is greatly appreciated.
If you have a proper tree data structure, you shouldn't be using compound nodes for layout. It's not generally possible to satisfy compound parent position restrictions when there are additional constraints on the children. This is because a parent is naturally constrained by its children -- a parent doesn't have its own position or size, it's children define it implicitly.
The best layouts for compound graphs are force-directed (physics simulation) ones like CoSE or Cola.
In your case, you just have a tree. I would use the breadthfirst or Dagre layouts without any compounds. Each level will naturally indicate rank.
For anyone interested, what I've done to solve this is create my own preset layout function that dictates where (children) nodes go on the graph, using their properties to dictate where they go.
It's designed to only display linear compound graphs, in order based on "level" in the hierarchy. It's capable of displaying the children nodes in grid-like sets within their parent nodes (visually - remember parents simply adjust according to their children), in the order of the mentioned linear levels.
You can also specify the values for how many columns in a set, space between nodes, and space between levels. There's obviously lots of room to make the variables more verbose if you'd like to specify "x-space" and "y-space" between nodes, and things like that.
It assumes the following:
-You know ahead of time what level corresponds to each compound group
-You know ahead of time how many nodes are in each compound group
-If you're making this dynamically, that you have a way to dynamically produce the javascript variables necessary for the dictionary, which tracks the total size of each group and how many nodes of each group have been accounted for.
Here's the code. I know it's a niche case, but if you do have a reason to use it, just keep in mind that it's sure to be bug prone, and is definitely inefficient (Javascript isn't my forte...). I've tested certain edge cases that I feel are common in my project, but there could be others that aren't accounted for.
http://jsbin.com/quyipo/edit
(Also upvotes/comments don't hurt either. I'm curious if this could actually help someone...)
I'm kind of a newbie in AngularJs and I have a complex JSON that i need to get data from to a auto complete.
I need to create an auto complete for ONLY the child elements in the the stucture without showing the parent categories.
Getting to the parents is easy, data[2].JobCategories and binding that to the ng-repeat and binding "jobParentCategoryModel.JobCategoryName" to the model does the trick.
But drilling to get only the children confuses me in the angular way. The way i see it, what I need to so is to to get only the children from the factory in new array of categories children and work with that. But for some reason in my mind it seem wrong to drill in the factory... Don't know why, just doesn't seem the angular way to do things.
PS. When looking at examples i saw lots of nested ng-repeat examples but i don't want to create the extra parent DOM elements for each child, so using nested repeats seams over head. But again I don't want to destroy the data structure (It is not two way binding so I don't know if it matter if i change the model at all).
What is the best practice to do this kind of deep drill down in angular?
I assume that you want to use only the child elements for instance in an ng-repeat but you do not want to create a separate data structure, that holds only these elements, in your scope. In this case I would write a function that extracts the elements and refer to this function in the ng-repeat:
<li ng-repeat="eachElement in getChildElements()">...</li>
This way you avoid redundancy and inconsistencies since your list automatically adapts to changes in the data structure.
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
I'd like to find a way to tell the distance between two DOM elements. Not in pixels, but as in traversal steps.
The practical use of this would be the following: There is one core element, that needs to find other similar elements in the site, and mimic the behavior of the closest related.
E.g. a gallery without a set width, in tabs. The invisible tabs could have no width, thus the gallery in the tab will not be visible unless it's reinitialized when the tab is shown. The hidden gallery would be the core element and it will to look for another possible instances of the gallery which is working properly and copy its width in order to work. The working gallery could be in the first tab, or in the content, or a small gallery in the sidebar or footer. What I'd like is for it to 'know' that the closest related other instance is the one on the other tab, not the one in the footer. Since this is a WP plugin I can't hardcode anything, and the scenario is not just limited to tabs.
.closest() doesn't work for this purpose.
I found out that for this pupose the most efficient solution is this:
var commonParentsDepth = a.parents().has(b).first().parents().length;
You'll get a number that tells you how deep the two elements' common ancestor is. You do this test in a loop for multiple elements, comparing two at a time, one of which does not change. You'll be able to tell by the result if two elements are closer related than others. The larger the number, the deeper down the tree your two elements are, which means the closer they are.
Note: This is not for comparing two elements against another two.
I've combined these two, somewhat related questions:
How to find the nearest common ancestors of two or more nodes?
JS/jQuery: Get depth of element?
I've looked around but have yet to find a great solution the the following problem:
I have a Backbone View tied to an el on the page that is a container element for what I'll call a "sidebar" in the traditional sense (for explanation's sake). This sidebar element's inner-html needs to change completely depending on the route. However, the position on the page never changes, and will always fill this container.
Now, for an initial prototype, I had a 1:1 relationship between this container and the view placed in it (I only coded up one route). Now however, said view needs to change based on the route as I've mentioned.
Being that these different views have entirely different html markup, response to events, etc... I had thought that I'd make sense to have a higher level view that'd swap in sub-views. Of course, one solution that would work would be to handle everything in the same view, but the necessary logic would be cumbersome (and pretty damn unwieldy).
Currently, here's what I'm thinking (and have partially implemented):
Have a top-level view for this page element.
Depending on the route, swap in the necessary sub-view.
These subviews are rendered with dust.js, where the .html template for just this component on the page is lazy-loaded via AJAX, compiled, and cached. Subsequent renders just consist of calling the cached "compiled" function with a new context.
Additionally, I was going to initialize and cache each of the subview Views within the top-level View, such that I'm only instantiating, setting up event handlers, etc.. once.
Then, depending on the route, look up the associated subview View (cached), and swap it in in-place of the current view.
Now, as I've mentioned, I have this mostly coded up and... semi-working. However, what I'm struggling with is how to have each of these subviews exist independently and handle the swapping, but keep all of the event handlers and current state to continuing to live whether the component is currently displayed or not.
Basically:
How to avoid completely destroying / re-instantiating subviews each time they're required. Maybe this operation isn't as expensive as I'm thinking it is and I should simply do the latter.
Being that the top-level View (the "manager", if you will) is tied to the container $el, how to swap in the subviews.
I'm sure there's a simple, elegant solution. I just haven't found it yet, unfortunately.
As far as point 1 is concerned I don't think it is too expensive to let the view be created each time.
For point 2 - I would recommend using Backbone.Marionette https://github.com/derickbailey/backbone.marionette. It has the concept of a Layout which lets you define different regions of your app and render/manage them individually.
I would recommend Backbone.Marionette not just for point 2 but for the way in which it allows you to manage interaction is in my opinion much better than standard Backbone.