I am writing a simple configuration helper program to hold variables-value combinations and have the ability to save and load to XML files.
The basic structure is built around the DefaultMutableTreeNode that I extended with a few methods. For example the 'get(String variable)' method recursively searches the children of the node to find the value of the specified variable.
String user = conf.get("Username");
After investigating saving to XML using the DOM I realized it uses a similar hierarchical node structure, rather than double handling I considered using the 'org.w3c.dom.Node' for everything.
As I can't extend the Node interface in the same way (only implement it), what class actually implements Node? I can see here that IOMetadataNode, SOAPPart implement the Node interface and there are a heap of subinterfaces.
Is a certain amount of double handling fine?
I have been able to do away with the double handling using MOXy
Following the example about JAXBCustomizations I used the below syntax to match the XML elements with the variables in my class. So long as there are setter/getter methods with matching names (For example var needs getVar and setVar methods) it's trivial to save to and load from XML.
#XmlRootElement
#XmlType(propOrder={"var", "value", "childNodes"})
The children nodes are instances of the same class as the parent and they are correctly nested underneath the parent.
Related
I am trying to implement a package-system which is commonly present in object-oriented programming language:
But I am not really sure which datastructure I am supposed to use, I thought about a directed graph at first. Nethertheless I think that some kind of LinkedList, which allows the addition of multiple childnodes would be a better and easier solution.
At least I guess so....
Can someone please tell me which datastructure may be the best solution for my problem?
I would just use a nonbinary tree like this:
public class Pck{
private List<Pck> children;
private Pck parent;//optional
private String name;//optional
//Also include a variable for your data
}
Each package has a reference to each subpackage.
If you want to get the name of a specific package, you would also need to maintain references to the parent package (and the name of each package within its layer). You could iterate over the parent to the next parent etc. and build the name.
Similarily, you could get the concrete package by splitting the name and recursively finding the next child.
I have source node and destination node I want to put restriction on nodes and relation types in the path. I am using Neo4j Java API.
Consider following toy example,
We have three person nodes A, B & C.
Source Node: A & Destination Node: B. There are many other kind of paths may exists between them. I want to restrict paths to specific format like-
(person) -[worksAt]-> (company) -[CompetitorOf]-> (company) <-[worksAt]- (person)
This can be very easily achieved from cypher query, but I want to know is there any way we can do it using Java API.
NOTE:
Kindly do not suggest putting restriction on path length, that
doesn't solve the problem. I want to restrict the node and relation
types in path.
Example mentioned above is toy example. Graph I am trying to work is more complex and there are many possible paths not feasible to traverse and validate individual paths.
It's not really clear from your question what you're actually trying to compute. Do you have A and B and want to find if their companies are competitors? Do you have C and want to find who among their friends work at competing companies?
Anyway, if you're using the traversal API (you're talking about paths), you can write a custom PathExpander which will use the last relationship in the Path to determine the next type of relationship to traverse.
If you're just traversing the relationships manually, I don't really see the problem: just call Node.getRelationships(RelationshipType, Direction) with the proper parameters at each step.
Contrary to what you do in Cypher, you don't declare the pattern you're looking for in the path, you just compute the path to follow the wanted pattern.
After reading the Neo4j java documentation carefully and experimenting with the code I got following solution working-
To filter path explored by PathFinder create a custom PathExpander using PathExpanderBuilder.
PathExpanderBuilder pathExpanderBuilder = PathExpanderBuilder.empty();
pathExpanderBuilder.add(RelationshipType.withName("worksat"), Direction.OUTGOING);
pathExpanderBuilder.add(RelationshipType.withName("competitorof"), Direction.BOTH);
pathExpanderBuilder.add(RelationshipType.withName("worksat"), Direction.INCOMING);
PathExpander<Object> pathExpander pathExpander = pathExpanderBuilder.build();
Once you create a custom PathExpander you can use it to create appropriate PathFinder which will filter traversal by the PathFinder.
PathFinder<Path> allPathFinder = GraphAlgoFactory.allSimplePaths(this.pathExpander, 4);
Iterable<Path> allPaths = allPathFinder.findAllPaths(sourceNode, targetNode);
In our example sourceNode would be Node 'A' and targetNode would be Node 'B'.
I have an implementation of a queue (Queue class, which is basically a linked list) - it consists of linked list of objects of Element class (with Previous/Next references) and a header for first and last element, which is also an object of Element class. I would like to serialize the Queue. The question is - how to serialize a bidirectional linked list?
There is a lot of ways to do that. You can implement Serializable and take care about persisting all the objects. You can save all the data and relations in some structured XML. You can go with JSON.
The only problem can be if your Queue is generic (like the one in the standard library), you are going to have hard time saving an object of unknown type.
I have an application that saves its context to XML. In this application, there is a hierarchy of classes, that all implement a common interface, and that represent different settings. For instance, a first setting class may be made of 4 public float fields, another one can be made of a sole HashMap.
I am trying to determine what is the best way to handle writing and reading to XML in a generic way. I read on this site a lot about JAXB and XStream for instance, which are able to make a specific class instance from XML.
However my question is related to the fact that the actual class can be anything that implement a given interface. When you read the XML file, how would you guess the actual class to instantiate from the XML data? How do you do that in your applications?
I thought that I could write the .class name in a XML attribute, read it and compare it to all possible class .class names, until I find a match. Is there a more sensible way?
Thanks
xstream should already take care of this and create the object of correct type.
The tutorial seems to confirm that:
To reconstruct an object, purely from the XML:
Person newJoe = (Person)xstream.fromXML(xml);
If you don't know the type, you will have to first assign it to the common interface type:
CommonInterface newObject = (CommonInterface)xstream.fromXML(xml);
// now you can either check its type or call virtual methods
In my case I just have a kind of header that stores the class name that is serialized and when de-serializing it I just use the header value to figure out to which class shall I de-serialize the values.
A best practice would to use an established, well documented XML parser/mapper. All of the serialization/deserialization work has been done, so you can worry about your business logic instead. Castor and Apache Axiom are two APIs that I have used to marshal/unmarshall(serialize/deserialize) Java Classes and XML.
http://www.castor.org
Apache Axiom
From the Java API, it seems that nodes of a JTree are instances of TreeNode. In addition, all TreePaths returned seems to be instances of TreeNode. So, why are TreePaths represented by Object[] instead of TreeNode[]? This give raise to inconvenience when using these classes.
Thanks.
See this explanation from the Java tutorial:
Interestingly, the TreeModel interface accepts any kind of object as a tree node. It does not require that nodes be represented by DefaultMutableTreeNode objects, or even that nodes implement the TreeNode interface. Thus, if the TreeNode interface is not suitable for your tree model, feel free to devise your own representation for tree nodes. For example, if you have a pre-existing hierarchical data structure, you do not need to duplicate it or force it into the TreeNode mold. You just need to implement your tree model so that it uses the information in the existing data structure.