I'm developing an application in JSF and I need to show a graph, I'm using cytoscape.js and i embed script in my xhtml page.
I don't know how to avoid overlapping edges, when an entity A has a relationship with another entity B, and entity B has a relationship with entity A the lines overlap. Or when entity A has several lines to the target entity (B).
They seem to be a single line but they should be several towards the same target. Can anybody helpme?
Is there some method or property that can solve the problem?
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.
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.
The core data model of my app features about 50 entities with a lot of relationships between them. All of the relationships are uni-directional only (and are only required in one direction).
However Apple discourages you from leaving relationships without inverse (for model consistency reasons) and I believe that the missing inverses are responsible for a number of errors I am currently facing.
Since I don't really need the inverse relationships functionality-wise, I wonder if it would be possible to have them created automatically by XCode. Going through 50 entities with about 3 relationships each and creating inverses manually seems like a tedious task...
Any help much appreciated!
There's no way to have the inverse relationship automatically created in for you in Xcode4. Please file a feature request bug report for it. I could see this being a really useful feature in Xcode.
It may be impossible to automatically generate inverse relationship without generating proxy class. For example how to generate inverse relationship for a collection that occurs more than one time in a class (e.g. phones, mails, urls in business card)
New to XSD here.
Has anyone found or written a framework for validating XML with an XML schema in Cocoa/Obj-C?
What I really need is the ability to define permitted types of modifications to an NSXMLDocument, as described in an XSD file. This includes defining sequences of child elements, list of attributes and their permitted values, etc etc. I need to expose these modification rules in my UI. For example:
I want to constrain the names of the new child elements added to an existing NSXMLElement node in my NSOutlineView
If the XSD says that Node A has required child elements (Nodes Aa and Ab) then when the user adds Node A to the XML tree, I want to automatically create Nodes Aa & Ab and add them to the just-created Node A.
etc etc
It seems to me that a good solution would be a Cocoa counterpart of JAXB. XSOM (which doesn't create schema-derived classes, but rather gives an query-able object model of the XSD) would work too.
My question is similar to this one, but I don't want to limit myself to JAXB-like solution. I'm interested in finding out other solutions that people have come up to this problem.
Cheers!!
You can create a DTD and validate against it, or create a recursive parser based on your XSD, such as existing ones for RSS or Atom based on the spec.