Durk van Veen
4/3/2002 9:24:00 AM
To continue my previous post. I've had a chance to look into the problems
with overriding the MobileListItem a bit more. As I mentioned before, I have
basically two problems:
- the SoftKeyLabel property on my inherited myMobileListItem does not
survive post-back
- pagination with myMobileListItem does not work
My research highlights some basic problems with the current MMIT
implementation, in that it is really hard to inherit implementation from the
Microsoft-provided base controls:
The first problem seems to stem from the way that MobileListItemCollection
handles saving of the ViewState. This is what I found out with ILDASM. When
MobileListItemCollection::IStateManager::SaveViewState() is called, the
collection class will loop through all the items that it manages and query
the "Dirty" property. This property is a "hidden feature" of the
MobileListItem class (it's marked "assembly", a.k.a "internal" meaning
nothing outside System.Web.Mobile.DLL can call it). The "Dirty" property of
course only looks at the values of the Text and Value properties to
determine whether the item in question should be saved. Therefore no items
are saved to the ViewState if my custom SoftKeyLabel property changes if the
Text or Value don't change at the same time.
I can't override the Dirty property since it is marked "internal". I could
provide a "new" implementation for it, but then I'd have no way to call the
original implementation, which means that the Text and Value are no longer
saved properly. Alternatively my "Dirty" could always return true, which
would cause every single item to be saved to the view state. This has
obvious implications for the amount of useless state information that would
end up being saved to the view state.
The second problem is more serious for me right now because it renders my
inherited control completely useless: When you enable Pagination and pop
about 10 items in the inherited list, everything works fine for the first
page. However, on the second page, when the control re-instantiates the list
items, it uses MobileListItem objects instead of myMobileListItem. For some
reason the inherited "myListControlBuilder" is not used to determine what
type the children should be. So now my list has MobileListItems instead of
myMobileListItems which causes my adapter to throw an exception when it
attempts to examine the now non-existant SoftKeyLabel property.
From what I can tell right now, to get this to work I need to at least
provide my own implementation of List, ListControlBuilder, MobileListItem
and MobileListItemCollection.
Unfortunately because MobileListItemCollection internally uses classes that
are completely "internal", I'd also have to redefine ListDataHelper (an
undocumented class from System.Web.Mobile.DLL), DataSourceHelper (another
undocumented class) and IListControl (an internal interface).
This is turning into a heaping pile of code you'd have to write just to get
one simple property to behave correctly. It looks like there are some
serious issues with the useability of MMIT in it's current state as it
pertains to building your own stuff if you need to go a little beyond the
trivial stuff that is in the documentation.
I'm also worried that once you start writing custom implementations of all
these classes, there will eventually be problems because classes that are
all expected to share certain base classes, no longer do. For instance, if I
were to define an IMyListControl interface to replace IListControl, any
Microsoft code that scans a Form for objects implementing IListControl would
miss my own controls since they have IMyListControl instead.
Durk