I have a data set(excel spreadsheet) which needs to be migrated to CQ/AEM.
eg:
http://imgur.com/lbYIExf
Each entry in the excel cell should correspond to a node in CRX content repository. My initial thought is to use apache POI to parse the excel and construct a data structure containing the tree elements. Now, How do i construct this tree data structure before iterating persisting to CRX? Map containing map containing map(depth of 5) will be very complex to manage.
If there is any efficient design idea that you can share, please let me know.
To construct tree element you can create a class Node.
Class Node will have reference of its parent, reference of list of child nodes and actual Node data (corresponding to jcr node)
By using this class you can create a tree structure.
Use DFS/BFS to traverse the tree and then convert those node to jcr Nodes.
Related
I have often read/heard that the composite pattern is a good solution to represent hierarchical data structures like binary trees, which it is great to explain this pattern because internal nodes are composite objects and leaves are leaf objects. I can appreciate that using this pattern, it is easy to visit every element in an uniform way.
However, I am not so sure if it is the best example if you are considering that a tree is filling on demand (every time an insert method is executed) because we have to convert a leaf to composite object many times (e.g. when leaf has to add a child). To convert a leaf object, I imagine a tricky way like (inspired by become: from Smalltalk I guess):
aComposite = aLeaf.becomeComposite();
aComposite.addChild(newElement);
//destroy aLeaf (bad time performance)
To sum up, Is a good example the use of a tree-like structure to illustrate the composite pattern if this kind of structure is born commonly empty and then you have to add/insert elements?
GoF states the Intent of Composite as follows:
"Compose objects into tree structures to represent part-whole hierarchies. ..... treat individual object and compositions of objects uniformly"
So a tree is not so much a structure to illustrate Composite, rather a tree is the structure by which composite is defined and operates. Its also worth remembering that for the purposes of Composite, a tree can be a binary tree (2 children), a linked list (one child) or can be composed of nodes with a variable number of children .
Its quite normal to build a tree from nothing. Consider an arithmetic expression parser, building a composite "parse" tree. The parser will start from nothing and create leaf nodes for terminal symbols (like + - * / braces, numbers) and composite nodes to combine the terminals perform the calculations. The parser constructs the tree such that invoking evaluate() on the head node will cause a traversal to evaluate the expression.
I use this example to show that a tree can be built bottom up, never having to "convert a leaf to composite object".
If your application builds the tree top down, or progressively in stages, its hard to see that matters, because the build process will consist of creating appropriate nodes and inserting them in a way that makes sense for the application.
If converting leaf nodes to composite nodes is problematic in any specific application, then for sure you make to look at ways to minimise the overhead in that situation. but its only a valid Composite structure when the tree is built!
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.
I want to add a node in jackrabbit Repository which has a property holding a HashMap object. What property type should be used and how It should be done?
A JCR node is a hash map itself (with its properties as the keys). So, could you just add a child node?
I'm developing a new system that talks to a third party via JSON.
One of the calls returns a huge JSON structure to represent products and rules.
I've used Jackson to convert this JSON into a tree quite easily. Now the issue is I want to be able to find nodes by 'querying' without manually traversing the whole tree.
So somewhere deep in the tree is an object which has a field called business_id. I want to return all the nodes that have this field.
Is that possible?
You can use Jackson's JsonNode class documented here:
http://fasterxml.github.io/jackson-databind/javadoc/2.5/com/fasterxml/jackson/databind/JsonNode.html
Parse your data into a JsonNode (e.g. by ObjectMapper.readValue), then you can traverse programmatically that JSON structure as a tree.
Look at methods like: as{datatype}, find[Value|Values], is[Array|Object|{datatype}], path etc.
You could try Json Path, it lets you pick up a json node using it's xpath:
http://code.google.com/p/json-path/
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.