Is there a layout or an option to avoid grouping nodes to overlap eachother?
I'm getting a graph with standalone and grouped nodes, but the combinations are dependent on dynamic data. So i can not place them on my one, or would like to avoid it.
All layouts i have tried do not take care of the grouping nodes and place their sub nodes together.
For example 'circle' creates one circle of all nodes, not a circle per group.
The goal would be to create something like "http://js.cytoscape.org/demos/5b192c88616af2f75344/", but there the nodes are placed manualy..
I have seen the example "http://js.cytoscape.org/demos/59e38e9f20e25a293e44/" which seems to work as required but it is using an extension. First of all i would like to find a built in solution.
Your requirement for a non-extension solution is erroneous.
Only basic, small KB layouts are included in Cytoscape.js itself, and it makes no functional difference whether a layout is included by default or not: They are both extensions -- some are included by default, some are not.
CoSE Bilkent is the best compound node layout algorithm for graphs/networks -- bar none. You can alternatively use CoSE, which is included by default. CoSE is a more basic version of the algorithm, optimised for speed at the expense of visual results in some cases.
Related
I am currently working with GraphDB to visualize some data that has a graph nature. I have imported the RDF data into graphDB and actually the graph is pretty nice. The only downside is that every single node is orange.
I was wondering then, if graphDB has some mechanism whereby the color of some nodes could be changed based upon a semantic relationship between them. For example:
<Berners_Lee> <created> <web> .
<Berners_Lee> <works_as_a> <teacher>
If I were to load this onto graphDB all nodes would appear by default in orange. Is there any way I can specify that nodes that are pointed by relationship created appear in blue?
I hope everything is clear. Any help would be much appreciated.
The colors are generated automatically and differentiate the types in one graph, which is their main purpose. Also we do not handle properly the case with multiple types for a node, but we have it in mind. The problem with your data is that all of the subject predicates and objects have no type (which makes them the same type). Here is a small example, based on your data which will produce the desired effect.
<Berners_Lee><created><www>;
<works_as_a><teacher>;
a <Person>.
<teacher> a <Occupation>.
I am writing 3D geometry visualization software for schools. I am designing my engine as an Entity-Component system, because it has served me well in games. In this case I have some specific requirements:
There is a limited amount of different geometries I need to render. I would like to render these in batches. So I render all lines as one batch, all triangles as one batch, all planes as one batch, ... It works well even with transparent objects, since I am using depth peeling and don't need to sort them by distance.
One logical object will typically have more than one mesh associated: e.g. a plane entity has a border "child"-entity that has four lines as its body, these lines all share the same material.
I would like to have a clean design, so I am trying to stay true to the no-code-in-components principle and same-structure for one type of components.
What I have now is: A different component type for each type of geometry (point, line, plane, ...). The corresponding system stores a batch with a mesh + instance data and renders it in one draw call. The instance data for different types of geometry is different, hence I decided to go with one component type per geometry type. (A bad design?)
Question:
Now I'm wondering how to handle entities that seem to need multiple components of the same type, like the plane border, that has a body consisting of four lines.
I could think of several solutions, which all have draw-backs:
1. Make each line of the border entity an entity itself. Each would have a "line" component and a "child" component. That would model the border and the lines as five entities, with the four lines attached to the border entity via "child" component. This seems like quite a waste of entities. Some special entities would have several dozens of children then.
2. Allow the border entity to have multiple components of the "line" type. This seems like a hack, since all ECS article I've seen discourage using multiple components of the same type on one entity.
3. Make a unified "geometry" component that may contain an arbitrary number of elementary geometries. That would introduce quite some indirections, but seems like the best solution to me, at the moment.
Could someone help me to sort this chaotic thoughts into a good solution? I'm sure I'm missing a straight-forward approach, but I just couldn't find one yet.
I have a lot of experience in programming (10+ years), but unfortunately, just recently started with Entity-Component systems. So I'm still struggling with the concept, it seems.
Thank you very much.
I have a bunch of nodes on each side of a central node. I am trying to find a way to position the node lines so that they go to the right or left side of the nodes.
So for this:
http://jsbin.com/ipuxub/4/edit?js,output
I want the lines for the Jerry node to go to right side of Elaine, George, Kramer, etc.
While I don't think this is possible now:
Is there a way to force it, trick it or make it look better?
If it is changing the Cytoscape JS code, any suggestions to where I begin or look at or what would need to be changed?
Controlling edge control points more manually or adding support for node bend points are things we have planned to add in future, and I think either case would satisfy your use case.
However, we do not have the resources to do this in the short term: Both cases require our side to plan how those features would fit in with the model and visual style system (cy.js css).
In the short term, if you want to control where edges are drawn, you have to adjust the positions of the connected nodes -- because the edge positions are inferred between them. The first edge is straight between them, and for 2 or more beziers are used.
If moving node positions does not suffice for your usecase, the first steps would be for us to discuss and plan how this feature would work and how it would fit into the system: https://github.com/cytoscape/cytoscape.js/issues/359
Then if you're interested in implementing it, it would be a straightforward process. We could direct you to the relevant parts of the code that would need to be changed etc over a Google+ call.
Thanks -M
How to traverse a tree of MP_Node (django-treebeard) categories and display effectively with lease amount of queries? I tried looking the docs but I see the queries number increasing with more categories.
Is there a method to limit the number of queries to display a menu like amazon.com and get all the categories in an optimized manner?
I see that dump_bulk() api in treebeard gets all the categories in a single query. Is it advisable to use it? If not why? Where is its practical usage?
A sample code using twitter-bootstrap nav menu would be appreciated.
I'm looking to reduce the number of queries. Answer with explanation with least number of queries will be accepted.
I chose django-mptt in lieu of Treebeard. It's much more simple, and uses only one tree management methodology (MPTT, hence the name). See this function (disclaimer, I submitted a patch which rewrote this function to be more optimized) - it caches an entire tree below a given node, allowing you to go up and down the tree as much as you want (e.g., node.get_children(), node.parent, etc.), without running any more queries. In other words, it's ideal for doing exactly what you're wanting to do.
tiles:insertDefinition and tiles:insertTemplate both has putAttribute , i am not understanding the difference between the two.I am using tiles 2.x version.
thanks in advance
kranthi
A template is a view which expects to be supplied attributes while definitions are named instances of a template defined in tiles.xml (or pragmatically using the API).
tiles:insertDefinition requires the name attribue to be set, because you are inserting a defintion you have layed out in tiles.xml.
tiles:insertTemplate creates a new definition on the spot, from a view and expects you to insert values at that point. It requires the template parameter be set, there is no name attribute.
In general I don't think you should need to use either of these tags often (you can create tiles using applications without ever using either). Avoiding their use means having all definitions clearly laid out one place AND being able to see how all definitions fit together.
This central view is tiles greatest strength which these tags can undermine.
tiles:insertDefinition still means using named definitions, there is still one central location were all layout is controlled but because we are inserting the definition within a view we loose our overview of how everything fits together.
tiles:insertTemplate is akin to a JSP include, you are creating a new definition at that moment in the view and use it. This tile is not part of the overarching view.
In case the argument was not clear, JSP includes can achieve the same reduction in boiler plate code as Tiles can. It is the overarching view which tiles provides that allow you to easily change page structure across the whole application easily. Carefully consider that this is not being undermined.