Although that’s not what you expected – not what anyone expects from TextBox data entry – it’s OK with Silverlight. The default Mode in Silverlight is " OneWay", which translates to "you don’t care about user input". You won’t get an exception there will be no binding failure reported in the output window. Nothing is wrong from the Silverlight perspective. By rule, the CanAskForIt guard property can never return true when the DrinkName is empty so the button never enables.
The value in the TextBox isn’t passed along to the ViewModel. Do you know why?Ĭonfirm that the ViewModel’s DrinkName property remains empty no matter what you enter in the TextBox. Type anything into the TextBox and tab out. Remove it now and run the application again. What if you forgot? Would you notice it was missing? Would you have remembered to write " Mode=TwoWay"? I often forget. Look again at the TextBox binding in the MainPage. That's annoying.Īnother source of complexity lurks in those data bindings. Worse, this expedient exists solely to satisfy the XAML binding technology. We can live with that.īut what if you choose to use native Silverlight commanding as we did in the 01-HappyHour sample? That will cost you another nine lines for the AskForItCommand property. The AskForIt and CanAskForIt members carry their own weight you’d implement them in roughly the same way whether in the ViewModel or in the View code-behind. You don’t want to repeat that in every ViewModel so we should expect to push that into a base class … one more thing to remember. We also carry the eight lines at the bottom devoted to INotifyPropert圜hanged. We’ll be stuck with this same 9-fold expansion for each of the many properties we add to this ViewModel as it grows to support a real use case. Now it takes nine lines just so it can notify the UI via NotifyOfPropert圜hange when the property is set. It could have been a one-line auto-property were it not for the need to notify the View when the drink name changes. The DrinkName property is a stand-in for the kind of Model object that you would display in a typical business application. We could cut the 5 lines devoted to the disused AskForIt_Click handler. The code-behind is about the same length (20 lines) it was before we added the ViewModel. Did we cut 50 lines somewhere else? No we did not. Start with the MainPageViewModel itself … which is inevitable when you follow MVVM. Or you can skip to the next section and get on with the business of fixing it.
CLICKY CRISP VIEWMODEL CODE
You can stick with me in this section as I tear this code apart. Right now there is a lot of MVVM-inspired code that introduces plenty of complexity for no obvious benefit. The Lesson 1 solution is still in its pre-Cocktail state. Type into the TextBox, tab out, and click the button to see the behavior depicted above.
CLICKY CRISP VIEWMODEL ZIP
Alternatively, you can start over with the original contents of the folder 01-HappyHour from the tutorial zip file.īuild and run to confirm it still works. You could continue with the solution from Lesson 1 exactly as you left it. The 02-HappyHour tutorial folder holds the state of this solution at the end of the lesson. Then we will see what Cocktail can do to alleviate them. In this lesson, we’ll identify the many hazards and complexities involved in our original design. Then, in keeping with the MVVM (Model-View-ViewModel) pattern, we factored out a MainPageViewModel class from the MainPage’s code-behind. We implemented it first with a single MainPage class. You enter the name of a drink, press the button, and the application promises to deliver it to you. In Lesson 1 we created a simple, one-View Silverlight application. Should I delete a View code-behind that does nothing?.Add HappyHour project dependency to Cocktail.
0 kommentar(er)
