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.
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.)
Does anyone have an example of a custom made Renderer for xwiki rendering framework? I want to do a conversion from JSPWiki to XHTML but the default result xwiki generates is not sufficient. I need to apply some logic that inspects siblings/children in the intermediate tree.
Debugged the xwiki code what gave me the idea there is a strong seperation between parsing (generates a tree) and rendering. Think solution has to come in the rendering phase
Thx
Tom
If you want to modify the tree, what you want is probably more a custom translation than a renderer actually. Renderes receive events in a streemed way so it's not always easy to do somthing depending on following events even if doable.
For transformations you can look at http://rendering.xwiki.org/xwiki/bin/view/Main/Extending#HAddinganewTransformation. You can also simply use the parser modify the generated XDOM and then render it, creating a translation is generally needed when you don't write yourself the code that parser and renderer.
If you still want to do it as a custom renderer the simplest it probably to extend the XHTML renderer and add you stuff, you have an example of extended XHTML renderer in https://github.com/xwiki/xwiki-rendering/tree/master/xwiki-rendering-syntaxes/xwiki-rendering-syntax-annotatedxhtml (add annotation in the generated XHTML content using XML comments).
Java world has few dead wiki renderers high positioned in google. I use info.bliki.wiki many years, I'm fascinated with high quality of object design
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.
So I've been trying to see how I could best structure my code, because I have an intuitive feel that there must be a better way to achieve what I want without passing around a single object to nearly every UI class in the project.
The project I'm working on has a class RhythmWheel that extends JRootPane. The constructor then goes on to create all the components that form a RhythmWheel. For example it creates an instance of ControlPanel (which extends JPanel) and adds it to itself.
However ControlsPanel needs to have a lot of knowelgde of things that are defined in RhythmWheels like the number of wheels that are currently selected. Currently the constructor for ControlsPanel takes a RhythmWheel as an argument, and then keeps a reference to it. It uses this for things ranging for component a JFileChooser should be parented to to, and as an argument to a function that writes the revelant state of the application to an XML file.
It seems wrong to me that I'm passing around a main component across so many classes. I thought about design patterns, and figured that a singleton might be a solution to this. However I have read numerous times that singletons are evil and are an anti-pattern. I guess the MVC pattern might help, but I'm not sure how I'd implement that in Swing. And most recently I came across Dependency Injection as a possible solution.
I'm a little lost as to what I should be doing, or if I should be doing aything at all. If you'd like to glance at the code I'm working on, you can see it at https://github.com/vamega/RhythmWheels so any advice on how to proceed would be great.
if everything needs a reference to RhythmWheel then it sounds like RhythmWheel is awfully complex. maybe you can break RhythmWheel into a collection of components that (hopefully, and likely, since GUI should reflect logical structure) correspond to particular parts of the GUI?
also, why do all the GUI components keep references to the RhythmWheel (or the appropriate sub-component, if you refactor as described above)? i haven't done much spring programming, but i thought the idea was to structure things round an observer pattern. in that case, the gui components should be registering themselves as observers on the wheel components, so that they can update when the wheel changes.
and yes, this is mvc. the wheel components form your model; the gui is your view. what is less clear is what the controller is. i suspect that it is the high-level wheel.
so, in summary:
the wheel is composed of sub-components
the wheel has high-level methods that reflect what you can "do" to it
the wheel's high-level methods are what are called by actions in the view
the wheel's high-level methods make changes to the wheel's sub-components
the wheel's sub-components, when they change, inform the model, which updates
only the input parts of the view need references to the wheel; the display parts are triggered via callbacks registered with the wheel sub-components.
(to answer the original question directly, i don't see anything so bad in passing around a wheel instance, but as i suggest above, it might be better for it to "fragment" into different components as it gets "lower" into the GUI).
I don't see what's wrong with using singletons. A control panel sounds like a prime candidate for a singleton. Why would have you more than one? Same goes for the others. Anything your currently accessing in ControlPanel from RhythmWheel can be exposed through getters and setters.
Unless there's a model/view separation that you would like to decouple or a view that needs to observe model updates, I wouldn't use MVC.
For an audit log, i need to know the differences between 2 objects.
Those objets may contains others objets, list, set of objects and so the differences needed maybe recursive if desired.
Is there a api using reflection (or other) already for that ?
Thanks in advance.
Regards
It's a pretty daunting problem to try and solve generically. You might consider pairing a Visitor pattern, which allows you to add functionality to a graph of objects, with a Chain of Responsibility pattern, which allows you to break separate the responsibility for executing a task out into multiple objects and then dynamically route requests to the right handler.
If you did this, you would be able to generate simple, specific differentiation logic on a per-type basis without having a single, massive class that handles all of your differentiation tasks. It would also be easy to add handlers to the tree.
The best part is that you can still have a link in your Chain of Responsibility for "flat" objects (objects that are not collections and basically only have propeties), which is where reflection would help you the most anyway. If you "catch-all" case uses simple reflection-based comparison and your "special" cases handle things like lists, dictionaries, and sets, then you will have a flexible, maintainable, inexpensive solution.
For more info:
http://www.netobjectives.com/PatternRepository/index.php?title=TheChainOfResponsibilityPattern
http://www.netobjectives.com/PatternRepository/index.php?title=TheVisitorPattern
I have written a framework that does exactly what you were looking for. It generates a graph from any kind of object, no matter how deeply nested it is and allows you to traverse the changes with visitors. I have already done things like change logs generation, automatic merging and change visualization with it and so far it hasn't let me down.
I guess I'm a few years too late to help in your specific case, but for the sake of completion, here's the link to the project: https://github.com/SQiShER/java-object-diff