Overview
I was recently working on a daft tool for my Fantasy Baseball League. I found myself using a lot of lists to display the teams, free agents and selected players. The first list I was looking at was a list of team names I wanted to stretch from left to right at the top of the page. I wanted to use this list not just to display the teams in our league, but to also identify which team was currently selecting and what direction the draft was going. Most fantasy drafts “snake” meaning that the last team to pick in the first round picks first in the second round.
Now, being a newly equipped Silverlight programmer, I quickly wrote a control to display a team name and gave this control three states: ‘Drafting’, ‘Drafted’, ‘Normal’. ‘Drafting’ would be for the team currently picking, ‘Drafted’ would be for teams that have selected during the current round and ‘Normal’ would be for teams left to pick. I then added a ListBox, and created the appropriate DataTemplate. What I later found out, however, was that I couldn’t obtain a reference to my team control (The control with three visual states) from outside the ListBox. I needed this reference to pass into the VisualStateManager.GoToState function.
So at this point, I said ‘shucks’ and just manually added my controls to a StackPanel instead of using the ListBox and DataBinding. I moved on to another List on my page which was a list of the Teams in our league. For each team I wanted to display all the players on their roster. This would be an active list, as their rosters obviously grow during the draft. Again, I was confronted with the same issue. I added an “AddPlayer” function to this ‘TeamRoster’ control but could not readily get at the control from outside the List.
Now I needed to give this some thought! What I determined was that I decided to use the ListBox because it was the most appropriate databinding control. I also realized I was not using the ListBox for its intended purpose. In neither case was I displaying controls for the purpose of selecting an item from the list. With this enlightenment, I decided it would pay great future dividends to me to design the List that I do want.
Goal
When I set out to develop my list class my goal was really quite simple. Do everything as close to the ListBox as possible while providing indexed access to the visual controls within the list. I’m using visual control to distinguish between the UIElement placed within the List and the Data Item from the usual ItemsSource databinding property.
Conceptual Components:
I started looking at the Conceptual components that make up a list. This work was pretty easy because after all, I had the ListBox to look at. J I quickly identified the following components.
1) List Class – the list class (i.e. ListBox)
2) List Panel – the panel within where the individual items were added
3) Item Container - a Container to wrap the visual controls
4) Item Control – The Visual Control (UIElement) produced for each Data Item
5) Data Object – The DataContext for the visual control.
Conceptual Components
At this point, the component I was immediately finding both the most interesting and the most irrelevant was the Item Container. It’s in the Item Container where the ListBox places selection logic. In the ListBox, we are free to override the appearance for each of the visual states but we cannot add logic or define our own states. I started thinking about what logic could go in the Container and I came up with very few possibilities. Logic that applies to the container would be logic that is data/visual control independent. The best possibilities I came up with, besides selection logic, were visual states for 1) when an Item was inserted/removed from the list and 2) when an item was moved within the list. Ultimately, I realized that this container was very dynamic. Selection logic would be highly useful but needs for custom logic would be few and far between. Because I didn’t need the selection logic right away, I decided I would figure out how it would be implemented and move on. These were my thoughts:
1) It would be easy to inject the Container around the ListItem. Since I manually instantiate and insert the ListItem’s, all I needed to do was make this Initialization logic overridable.
2) There would be multiple communication options for calls between the item Container and the List. The Item Container could provide events the list could subscribe to or the container could even be initialized with a reference to the parent list. Further, the List would obviously have access to the individual item containers.
Great! Simple yet even the complex is possible! I’m moving on …
