How selection models work
Java has three components (with SwingX one more) which uses a selection model. There is the JList, JTable, JTree and J(X)TreeTable. The selection model maintains the set of selected elements and the anchor and lead selection. The anchor and lead do not need to be part of the set of selected elements. Changing the selection requires the invocation of either the setSelectionXXX, addSelectionXXX or removeSelectionXXX methods.
The user changes the selection either through the keyboard or the mouse. Based on what modifier keys he presses the selection change behaves different. If he doesn’t use any modifier or the shift key the setSelectionXXX method will be invoked for all cases. If he uses the ctrl key either add- or removeSelectionXXX will be invoked based on whether the elements where part of the selection or not.
If he doesn’t use any modifier there will only be one element which should be selected. The selection model should clear the set of selected elements and add this element. It should also set the anchor and lead selection to this element.
If he presses the shift key then the first element will be the element of the anchor selection. The selection model should clear the set of selected elements and add the elements between the given index0 and index1. The anchor selection is the element at index0 (first element in path array) and the lead selection is the one at index1 (last element in path array).
If he presses the ctrl key and the selection should be removed (invocation of removeSelectionXXX) the elements between index0 and index1 should be removed from the set of selected elements. The anchor selection is the element at index0 and the lead selection is the one at index1. In this case the elements of the anchor and lead selection are not part of the set of selected elements. If the user presses the ctrl key and the selection should be added (invocation of addSelectionXXX) the elements between index0 and index1 should be added to the set of selected elements. The anchor selection is the element at index0 and the lead selection the one at index1. The element of the anchor and lead selection are part of the set of selected elements.
What if some elements shouldn’t be part of the set of selected elements? The solution depends on how a selection change should behave. If the selection should follow the common scheme, then the anchor should be the beginning of the last contiguous interval which is part of the selection and the lead is the end of the last contiguous interval. The next selection would then start from the anchor. This also works with adding or removing elements from the selection. Removing elements is quite easy because there doesn’t need to be a verification. When setting or adding elements the set of selected/added elements has to be computed based on the anchor and lead selection. When adding elements the anchor and lead of the current selection need to be used, in the other case it is the first and last element of the selection. Caution must be used because the order is important, it defines whether the user selected up or down and also is input to the computation of the new anchor and lead selection! The anchor and lead is then the beginning and end of the last contiguous interval in the set of selected elements.
Based on this explanation I think it is really hard to understand how a selection works (should behave), especially when elements should be left out in between. Should the next selection start at the last interval or somewhere else?
Interesting post about DI, Spring and JEE
Java and the need for Dependency Injection
Somehow, I agree with the writer that Spring can be very intrusive and is much too big. As soon as you start using it, you are bound to it and with all components its already about 20MB. The positive argument is that it helps a lot in writing clean separated, testable code. For me the main reason to use Spring is to have an IoC container that manages bigger components. But often people go too far in using Spring by putting everything into the container either through configuration or annotation. This as I can see leads again to unmanageable code which is the opposite of the intention of DI.
With JEE 5 Sun has made a great step in simplifying the technology stack. Using annotations to declare specific cross-cutting concerns (transactions) and resource injections helps a lot. Still developer should know at least for resouce injection how it is mapped to the JNDI tree. So they understand how this can also be solved by other solutions (ServiceLocator).
I would like to see the Spring container moving towards the JEE specification by supporting all JEE annotations as well as their own especially with respect to transactions. So people can write code once and run it in different containers (JEE, Spring, etc.).
Las Vegas und Grand Canyon
Nach längerer Abwesenheit mal wieder etwas von meinen Ausflügen. Letzte Woche haben ich und einige Kollegen Las Vegas und den Grand Canyon besucht.
Las Vegas ist einfach ein riesiges Vergnügungsgebiet. Übernachtet haben wir alle in der schwarzen Pyramide des Luxors. Während der paar Tage habe ich den Strip mehr als 2mal abgelaufen und mir dabei die Hotels und Sehenswürdigkeiten angesehen. Man muss auf jedenfall einmal am Tag und einmal in der Nacht langlaufen, um die Unterschiede zu erkennen.
 |
| Las Vegas |
An einem Tag haben wir auch einen Ausflug (im wahrsten Sinne des Wortes turbulenten Flug) zum Grand Canyon gemacht.
 |
| Grand Canyon |
