Previous Lesson: List
Next Lesson: What's Next?
The selection mode
| So now we think we understand how the list part of an MVCList
works - how about the selections? Well, the first thing to understand is
that the way we express the selection or selections depends upon the "mode"
of the widget: whether it's single select or multi-select. The SelectionInList
model can handle both of these modes, but you have to know what you're doing
and only ask the appropriate questions. For instance, it's up to you to
ask either ||In Smalltalk, you have to choose either a SelectionInList model or a MultiSelectionInList model for the life of the component.|
Single selection lists
If the list component is single-select then the selectionIndexHolder will contain either an Integer (which corresponds to the 0-based index of the selection) or null (if there is no selection). SelectionInList implements a number of methods that makes dealing with single-select easy:||The method names are identical in Smalltalk, with the main difference being that the selection index is 1-based, so a selection index of 0 corresponds to no selection.|
Multiple selection lists
If the list component is multi-select then the selectionIndexHolder will contain a Vector of Integers. SelectionInList implements a number of methods that makes dealing with multi-select easy:||The method names are identical in Smalltalk, with the main differences being that the selection index is 1-based and the collection class used is a Set.|
The SelectionHolder object
|One method you can send to a SelectionInList object, selectionHolder(), will create a very useful object: a SelectionHolder object. This is a ValueModel that appears to hold onto the selection(s) of the list. As you'll see in the examples, this is really handy when you start "wiring" your ValueModels together.||
In Smalltalk you can send the method |
| We're getting near the end with these examples, so I expect
you'll be able to follow the source code without too much additional information.
In these next couple of examples, you should start to pick up on a different
mindset of application building. Traditionally, your application class is
responsible for building the window and properly responding to all the events
through the life-time of the application. MVC programming is quite different.
The main purpose of the application class is to "wire" the model to the
view using ValueModel
classes, and then to sit back and watch things work. Notice how little the
applications have been doing after the |
|Anyway, let's extend Example 7 to show detailed information about a selected player. In this example (look at the source code), we'll have the list of players in the left side and a "detail view" on the right side. The detail view will consist of two pieces of information: a read-only field with the selected player's name and an editable field with the player's shooting percentage. As we switch selections in the list, we should see the details on the right also change. The layouts are getting a little more complex, so I've switched to using the FractionalLayout layout manager for laying out the components.||The Smalltalk version of this example can be found in Example8.st and can be started by evaluating "Example8 open".|
|This example is very similar to the last one, but we will tie everything together. In addition to having a list for the players, we'll add another list for the teams. When you select a team, the list of players will update. When a player is selected, the detail view on the right is updated. You may want to check out a diagram of this example, which may help you understand the source code.||The Smalltalk version of this example can be found in Example9.st and can be started by evaluating "Example9 open".|
|There - we've taken care of a widget that can be a real pain to work with: the list. If you understand what's going on, the rest of the MVC widgets are kid's stuff. We'll wrap up in the next lesson.|