In a browser if I'm using javascript it's fairly straight forward to traverse the DOM. Unpacking it from the top down is just a series of calls, and finding individual elements is easy because of id# tags.
Swing components have a treelike structure similar to HTML. What's the best methodology for traversing that structure to find objects inside of it? Or should I simply stick to creating local field references to the objects that I care about?
Assuming you have a user interface that has data in it, and some code that's interested in querying those components to find out what their state is, how would you manage "finding" those components in the Swing DOM?
A HTML DOM is a tree data structure, which doesn't provide much behavior, and that uses node types that are not under your control.
A Swing tree of components is a tree of rich objects, containing objects of types that you create, and which should provide the behavior you need. You should apply the OO principles to the elements of this tree (panels, etc.): encapsulation, law of demeter, composition, etc.
You shouldn't have to traverse a tree of Swing components to find the one you want. This would be a sign of poor design and lack of encapsulation. The elements of the tree should collaborate, reference each other, call appropriate methods to do their job.
Related
I am working on Object Oriented Design Principles and Heuristics.
In the remarkable book named Object-Oriented Design Heuristics By Arthur J. Riel (1996) I see this heuristic:
Heuristic 4.13: A class must know what it contains, but it should never know who contains it.
Based on J.Reil, The main reason is reusability.
But in Swing Structure, we can access directly to the reference of Parent object.
for example: label.getParent()
So my question is:
Why swing components have .getParent() method?
Which Object Oriented Priciples or Heuristics are behid of existing this method?
Two things here: no rules are cast in stone in software engineering. It is always about balancing different aspects that are somehow competitive.
Then: the main purpose of UI components is (surprise) to be used in UIs. And typically any UI element belongs to exactly one parent. You can't have the same table showing up in two windows (maybe the same data, but not the UI table objects!). And from there: getting to the parent of a UI component is something that you need all the time. UI elements are always owned - and it is much more convenient when you can go up and down easily.
Long story short: I think you are looking at a very special case here - where it simply makes a lot of sense to deviate from a rule written in some book.
Disclaimer: I haven't read the book in question, so I can only speculate on what the author meant.
But my surmise would be that what is intended here is that the class should not change its behavior based on the type of the class that contains it. So, a Button must not behave differently when it's in a ScrollPane than it does if it is in a JPanel or a JFrame.
But the hierarchy of components in the UI is part of their responsibilities. They are in a tree structure, and so they not only maintain links to one another, but they have accessors to allow client code to navigate that structure. Now, you could have a structure where only the parents had links to the children, and not vice versa, just as you could have a singly-linked list. But to have a doubly-linked list, where each node has a pointer, not only the the node after it, but also a pointer back to the node before it, is not a violation of object-oriented principles, and neither is it a violation to have a doubly-linked tree structure where the child nodes also have pointers that allow navigating up the tree, from children to parents.
We must ask ourselves, how would knowing who contains it impair reusability? Why would knowing that make the class less reusable? Now, if it changed its behavior based on who contained it, that would do it. You could not just take the class and use it somewhere else, because it might not do what you expect it to do. But merely maintaining the links doesn't harm reusability.
(I would note that, if you're going to add and remove components from the hierarchy, there has to be some care taken in their API so that when you tell one of them you're severing the link, both of them can update their state. But that can be handled as part of the API design. As long as that was done up front in the first version so that it's part of the contract of all classes that are written to be part of that component hierarchy, it would not pose a problem.)
I'm new to graph databases (although I've extensive experience with Semantic Web technologies) and I'd like to understand if what I've in mind makes sense.
I've my own data model, made of Java's JavaBean objects, the model is rather similar to a graph, with a Node interface (and a few subclasses), an Edge interface (and a few subclasses), methods to query the model (get Node instances with attribute = 'x', get all edges for a node, etc).
I'd like to wrap this model with one of those query languages out there (let's say Cypher or Gremlin), so to have something more standardised and so that I can avoid implementing my own query language and, most importantly, my own query engine.
One obvious way would be to use Neo4j or some TinkerPop implementation as a backend for my object model (or similarly, to convert/synch my objects to a graph for one of those frameworks). However, because the model is already graph-like, has good search methods and efficient storage components (to/from simple XML files), I'm also thinking that maybe I could adapt a query language to my model. TinkerPop seems designed to support that.
Does this make sense? Is TinkerPop the best (or a good) way to go? Is/are there documentation/tutorials about that?
As a comitter of SimpleGraph I had similar needs that led me to starting the
SimpleGraph open source project in the first place.
For conversion of Pojos to and from Tinkerpop there is the ORM/OGM stack FERMA.
The idea of SimpleGraph is to "graphenize" other information sources e.g. the tabular structures of Excel Tabels or SQL databases.
Since your own data structures are already in graph form obviously the mapping to and from tinkerpop is much simpler. The SimpleGraph approach in this case would be a simple back and force (link) between the node and edge structures of so that each tinkerpop node corresponds to one of your nodes and tinkerpop each corresponds to one of your edges. I have succesfully used this approach e.g. for a graphical representation of UML models by mapping XML structural elements to tinkerpop elements and graphical representation elements in a graph editor at the same time. So my answers would be:
Does this make sense? Yes
Is TinkerPop the best (or a good) way to go? Yes
Is/are there documentation/tutorials about that? I'd neither say Yes and No this one
I have not seen a specific tutorial for your use case. If you experiment a bit e.g. with the SimpleGraph modules you might get a feeling how things work.
What is the best design pattern for a node - link diagram in Java?
The model should be seperable from the graphical representation.
There are several types of nodes.
There are rules as to which nodes can connect to other nodes and how many.
Java 1.7
You need to use literature of graph in data structures.
https://en.wikipedia.org/wiki/Graph_(abstract_data_type)
Then there are famous algorithms you can implement. Depends on what you want to do one of the depth first and breadth first algorithms are more appropriate for you
https://en.wikipedia.org/wiki/Depth-first_search
https://en.wikipedia.org/wiki/Breadth-first_search
If you want to separate your model from the view, you can use the MVC pattern. For the problem of the nodes, you need to study about graph data structures.
To have multiple types of nodes you can take a look at the composite pattern, which work like the DOM in HTML (you have parents and childrens). You can adapt it to have a graph but take car if you want to explore it, you can have some cyclic way (you have to look at the graph exploration algorithms).
I would like to have a composite structure which is build from JSON. Each element can has only one type of children - so a group can contain only groups or only leaves. Then based on this tree I want to draw graphic user interface component, which will render diferrently and run different actions due to the type of itself (group or leaf).
The question is how to determine what to render and which listeners to attach on drawing. The tree is only a model, so it should not contain methods to do the graph or controlling.
Is it a good or bad pratice to check if it is instance of something and cast component to to right type and then do the right set up?
What about having a enum and getter to determine it?
I know answers that will work but I want to hear about good pratices.
Is it a good or bad pratice to check if it is instance of something
and cast component to to right type and then do the right set up?
Personally I think this will break the pattern.
Accordingly to wikipedia:
When dealing with tree-structured data, programmers often have to
discriminate between a leaf-node and a branch. This makes code more
complex, and therefore, error prone. The solution is an interface that
allows treating complex and primitive objects uniformly. In
object-oriented programming, a composite is an object designed as a
composition of one-or-more similar objects, all exhibiting similar
functionality.
Composite is a pattern that help you to use both container and leaf as the same type.
Look this diagram.
I suggest you to add and abstract draw method to the component class and let its subclasses implement it. Leaf will have a different implementation than Composite. This way a client class traversing your tree doesn't need to be aware if a node is a Leaf or not, but can simply call draw method on it.
Is anyone aware of a stateless tree component in Apache Wicket that works similarly to the JTree/TreeModel concept in Swing? I'm specifically looking for a static tree, i.e. no fancy AJAX or the like — just a plain and simple way of displaying a tree model.
You say you want a static, AJAX-less tree... does it even have to be a formal tree component? If not, you might be able to use recursive panels to mimic a tree, as illustrated here in the Wicket Examples (source code). It really depends on your use case, though.
I was also going to suggest going ahead and using one of the fancy trees, like this one, and overriding the behavior of clicking on the tree to "do nothing." Unfortunately, it looks like the expand/collapse methods are built in at such a deep level that that's not possible. There is no built-in class that does exactly what you want.