Comments on: Fluent Silverlight – Part 1

By: Ashish

Ashish — Mon, 21 Sep 2009 05:35:02 +0000

Nice articles, thanks.

By: Ross

Ross — Thu, 20 Aug 2009 18:21:50 +0000

Any chance that you’ll be adding support for other controls soon…like ComboBox?

By: John

John — Wed, 03 Jun 2009 09:34:59 +0000

Nice

By: Gabriel N. Schenker

Gabriel N. Schenker — Tue, 02 Jun 2009 21:18:38 +0000

@Fabian: validation is a concern we have not adressed so far but it is definitely on our pending list. But with our approach of data binding we are certainly on safe grounds and we will be able to extend the framework to include validation

By: Fabian

Fabian — Tue, 02 Jun 2009 15:14:08 +0000

How do you guys deal with validations, by validations I refer to checks that need to be performed so the view does not let something happen that should be be. e.g. user wants to enter a end date that is less than the start date. Obviously we might not want to have this validation in the View. Then a choice would be the View Model, but then how would the View Model react and notify the Presenter or View on what the problem is? That seems to be a very tricky set of actions and responses.

Thanks

By: Merill Fernando

Merill Fernando — Tue, 02 Jun 2009 02:19:15 +0000

Cool. This is excellent stuff.

One warning though, if one of the goals of using WPF/Silverlight was to have designer’s own the UI and for the devs to own the business logic you should be careful about what you put in the code. For example the changing the label above would require a code change whereas if it were in xaml the designer could change it themselves.

Another example is if the the designers wanted to change the commands from being a command button to a drop-down menu or some other control, they wouldn’t be able to in this instance.

By: Gabriel N. Schenker

Gabriel N. Schenker — Mon, 01 Jun 2009 20:32:49 +0000

@Sandor: we do not use tools like Blend to design our UI. We have a very specific UI which is hierarchical and highly dynamic – not the UI that those tools are made for. This is the reason why for us XAML has (nearly) no advanatages but only the known disadvatages (not wrist friendly, not strongly typed, etc.)

By: Sandor Davidhazi

Sandor Davidhazi — Mon, 01 Jun 2009 18:21:31 +0000

I’ve been working on a LOB Silverlight application using the MVVM pattern and I can sincerely say that if this framework works as advertised here, it will revolutionize implementing the MVVM pattern.

Some notes and questions:

1. I don’t think that defining an interface layout should be done in the code behind. Blend works with the xaml file, and also does Visual Studio, but they won’t be able to work with properties that were set in the code-behind.

2. I didn’t understand why people insist on defining everything in xaml, and celebrate that with commands they can implement event handling in the code-behind. I don’t think a designer has anything to do with implementing functionality, and he would never mess with rewiring a usercontrol’s events to commands.
Your whole idea of placing binding logic into the code behind just feels right! Not to mention how awesome it is to use a well designed fluent interface, and strong variable references to do that!

3. Can you pass parameters to commands?

4. How do you define the converter for the bindings?

I’m really looking forward for the coming posts, because MVVM development in Silverlight is really a PITA. Everybody is hyping the MVVM pattern, but really when it comes down to implementing it in a real-world, complex application, you have to face serious limitations and writing messy code. It just isn’t fun.

By: Krishna

Krishna — Mon, 01 Jun 2009 12:19:35 +0000

Love the idea…especially the properties one. But I am not personally attracted to the databinding in code. I think all the nice tooling features with blend/vs would go in vain….again not an expert and I appreciate your effort for the community.

By: Gabriel N. Schenker

Gabriel N. Schenker — Mon, 01 Jun 2009 07:47:57 +0000

@Michael: I will forward your question to Ray … but seriously: how would you define the binding or a (existing XAML based) view to the view model if not in the code behind? Of course you could define the binding in the XAML but this is exactly what we want to avoid. Ultimately we want to define most of our controls without using XAML at all (except for templating).