This is how I see things too. Note that in Silverlight, you cannot bind to ElementName (yet) so the high road is the only road available ;)
No virus
found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.12/1822 - Release Date: 12/1/2008 8:23
AM
________________________________
From: wpf-di...@googlegroups.com on behalf of Josh Smith
Sent: Mon 12/1/2008 8:08 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Thought: MVVM eliminates 99% of the need for ValueConverters
1. If the value you need is unique to presentation, you should
consider still using a converter. Visibility is a classic example.
If one of your reasons to be using MVPoo is to be able to use multiple
presentation frameworks (WPF, WinForms, WebForms, ASP.NET MVC, etc.)
then the last thing you want to do is expose a property of type
Visibility. Even if you're sticking to WPF, there's two possible
"hidden" values with differing characteristics (hidden and collapsed).
Choosing among these is a view concern, not a view model concern.
(It actually bugs me that the BooleanToVisibilityConverter doesn't
support this choice out of the box!)
2. Formatting is generally a presentation concern, and should be
handled by the view. It may be tempting to add a property that
formats that date in some specific way, but down the road when you use
a different view that wants to format that date in another way, you
have friction between views that may not be easily resolved. Again,
if the conversion is to facilitate presentation, let the view handle
it.
--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
wow.. you all folks think (and email) faster than I can read : ) …. So I apologize for keeping the thread alive ( specially life cycle) if you had all moved on..
1) On avoiding ValueConverters when you have a ViewModel … I agree with Bill … Value Converters are OK for me (some times). Imo, ViewModel has logic and if it makes it readable to use Booleans instead of Visibility, I do it.. I try to keep ViewModel agnostic of presentation details like visibility, and ValueConverters does this nicely..
a. I am
also a TypeDecriptorProvider virgin so I need to learn more about it…
2) On the “life cycle” of ViewModel (and Initialize method) … I would love to better understand the decomposition of your lifecycle.. Does anyone have a hardcore rule?
a. When is the data fetched?
b. When are Commands wired and exposed??
c. Does the ViewModel wire up for Loaded ?? I kind of read on that…. Or Does the ViewModel implement an Interface that the view calls?? ( I opted for the latter the few times I did this, it is interface driven so generic) ..
d. Dispose
() on a view model is new to me …. Never needed it before…
what kind of scenarios need it??
My experience:
I hate thick constructors and I hate to delay Views… but a common gotcha for me is that if I wire up a DataContext to a form and it has not been fully initialized, then my Commands either do two or three times as much work (if I wire them after initialization) or can get into funny states where a command’s CanExecute logic returns wrong result just because proper state was not ready…
If any one can share their practices on Initialize () of a ViewModel I would love to know more about the logical and consistent approach…
[Yes, the issues below have easy workarounds…. I am just trying to better read pros & cons to other’s experiences J ]. .
Thanks..
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: Monday, December 01, 2008 9:47 AM
To: wpf-di...@googlegroups.com
I’m with Marlon on this, while I agree that the VM can eliminate all converters I don’t like the idea of having a ViewModel too tied to the view and, after all, converters are very reusable J.
Just had a look at Silverlight validation model, think there’s a lot of work to do to fit it in a M-V-VM environment…
-Corrado
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Marlon Grech
Sent: lunedì 1 dicembre 2008 20:16
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need
for ValueConverters
I also think that this should be 50% 50%... If there is something strongly UI coupled then I would probably put it in a ValueConverter...
yet I must say I hate those creatures so called IValueConverters :/
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappl...@gmail.com> wrote:
--
I want to chime in on that one.
Yes, patterns are guidelines more than rules. I followed that discussion with very much interest and can’t wait to try some of that in my next app, and it’s really interesting to see the different streams of thoughts. So far I think I see two major variations in the exposed practices, one which considers that VM is a kind of replacement for code-behind (let’s call it a top-down approach) and thus a VM is very tightly bound to a View. The other is rather a bottom-up approach and puts the VM as an extension of the model, but formatted for the View.
In the project I worked last, we took a very pragmatic approach, and used VM for various reasons, the most important being avoiding that our designers have to write any code. Josh’s point is really valid, designers should not have to worry about code, period. It’s not their job. My role as an integrator (IM calls that “Interactive Developer”) was to specifically avoid designers to have that kind of problems. This results in a series of roundtrips between developers and designers coordinated by the integrator. In that sense, a well thought VM can avoid a number of roundtrips. To me, this is the most important aspect of the VM, because every roundtrip costs a lot of money, and designers are damn expensive in a project.
When I say we were pragmatic, I mean that because some in the team were quite unexperienced, we ended up having quite some code in the code-behind. If I had to do it again today, I would probably be stricter about that. But on the other hand, I saw another team take a much stricter approach (Josh: That was Linus’ team, you probably remember him from our memorable dinner in NY) and they spent a lot more time on some details than we did. Also, some of the development was done in India, and their strict approach cost quite a lot of time round tripping between India and Switzerland, or worse, having to refactor much of the code that the Indian team delivered.
Anyway… my next project should be a much smaller one (Silverlight), and I want to apply MVVM in a stricter way there. That should be interesting J
--
--
I love this kind of discussions they helps spreading opinions and helps me (and hope others) play better with this “quite young” but promising pattern.
I’m not absolutely saying your solution is bad, e.g. I use it when I need to enable an element as result of a complex condition (DataTrigger/Multibinding? No thanks! J) and, my point of view is that patterns are ‘indications’ and I feel free to adapt them in the way the best fits my solution.
Unfortunately I keep seeing architects that apply patterns “as-is” even if that results in more complex code.
-Corrado
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: lunedì 1 dicembre 2008 22:41
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need
for ValueConverters
Thanks Corrado. I get
where you're coming from with this, but I'm still unsure of where the
"boundary" is. One could take this reasoning and push it to the
extreme by stating "Why bother with a ViewModel at all? Why not just
bind directly to the Model and use Value Converters to handle all other
transformations that need to be applied to make the Model show up in the UI
correctly?"
Clearly, I know that nobody here is promoting that idea. The balance of
power, so to speak, between ViewModel and View is a spectrum in which I lean
toward the left and many others seem to lean more toward the right. I'm
wondering what guiding principles one should use to find the sweet spot between
the two opposing forces.
Josh