|
With regard to Onyx, the ViewModel and View are not connected at compile time, but at runtime, as attached properties are a runtime concept. Out of the box, it also does not do dependency injection, but rather uses the Service Location pattern, though I am working on enabling DI to be done using one's own solution. IOW, there's no limitation in how you use Onyx for either point you try to make here. In fact, it would be fairly trivial to make a direct translation of your DialogService for use in Onyx. Currently, Onyx "injects" the View (which provides the Service Locator) via the ViewModel's constructor, but there's hooks available that would allow you to change this, and in the future I'll support other ways of injecting the View as well.
Your interpretation of MVVM is questionable. First, the View MUST know about the ViewModel in order to bind data and invoke commands/events. You try to distinguish this by basically saying runtime knowledge (reflection) isn't the same thing as compile time knowledge which is an extremely questionable stance to take. From a pattern POV, static vs. dynamic knowledge isn't relevant, as patterns are language agnostic. I also don't understand what you mean by the last bullet point. What would a ViewModel contain that's "used purely in tests"? I honestly can't think of any code that would ever be put in any class that's solely used in tests.
The dialog service itself is a fairly nice abstraction... though it suffers in a few areas. This only lets you show a dialog. It doesn't allow you to construct the dialog with parameters, set properties on the constructed dialog or access properties on the dialog after it's been dismissed. Granted, most of this can be dealt with by interacting solely with the ViewModel for the dialog instead, but that's not possible when dealing with legacy dialogs, such as the common dialogs. Nothing wrong with that, but it is a shortcoming that should be highlighted in the article, IMO. That said, I'll be adding a similar service to Onyx in the near future.
I'm disappointed that the article doesn't discuss testing the ViewModel's that use this, as that's a very important part of the reason to use IDialogService. Thankfully you've included tests in the code.
Despite the criticisms, I've given this a 4. Nice article.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: First, the View MUST know about the ViewModel in order to bind data and invoke commands/events.
Actually, you can bind the view to the viewmodel through use of a data template in the resource file. Doing that, the view has no idea what viewmodel it is communicating with. This allows one view to be used with many viewmodels so long as they implement a common interface.
It takes a bit more work to have one viewmodel work with many views, but it can also be done rather easily.
|
|
|
|
|
Using a data template doesn't change anything here. The View still knows about the ViewModel, and in fact, the knowledge is more explicit since a data template is based on a Type.
William E. Kempf
|
|
|
|
|
Perhaps we are debating semantics here, but I still say the view "knows" nothing.
There is nothing in the view that references either a viewmodel, a type, or even the data template. Similiarly, nothing in the viewmodel references either the view or the data template. It is only in the resource file that any association is made beteween the view and the viewmodel. In that resource file the same view can be associated with many viewmodels. Coupling is very loose.
The only requirement for view and viewmodel(s) to work together is the interface the view expects; an interface the viewmodel is not required to supply. Granted, if the viewmodel doesn't implement the interface the usefullness of the view becomes debateable, but nonetheless no errors are generated either at compile or run time if the interface is missing.
Just as a question, you said the data template is based on a type, by which I assume you mean a class/object. I've never tried (still new to WPF) but can't you base a data template on just an interface?
|
|
|
|
|
You can't use a data template without referencing the data (in this case, the ViewModel). So I don't understand most of your argument here? However, the fact that the "coupling is very loose" proves my point, as there's still coupling . I also have to disagree about there not being runtime errors if you fail to meet the requirements of the bindings. You're right in that the application continues to run, without unhandled exceptions being raised, but errors still occur and are visible through the tracing API. This is the magic of reflection, but isn't relevant with regard to the pattern. Again, patterns are language agnostic, and since some languages are purely dynamic, patterns don't generally distinguish between dynamic/static coupling. From the POV of the pattern, the View MUST know about the ViewModel.
An interface is a Type, and yes, data templates can be based on an interface. (BTW, an object is NOT a Type.)
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: You can't use a data template without referencing the data (in this case, the ViewModel). So I don't understand most of your argument here?
My point is that the view does not reference to viewmodel, the data template does. Examine the view and there is nothing in the xaml to tell you what viewmodel it will interact with. The view itself it totally ignorant of its purpose, just as the viewmodel is totally ignorant of how it is to be displayed. The data template in the resource file does not imbue either with any knowledge of the other's function or existence.
William E. Kempf wrote: You can't use a data template without referencing the data (in this case, the ViewModel).
William E. Kempf wrote: An interface is a Type, and yes, data templates can be based on an interface.
To me, the second statement negates the first. An interface , by definition, does not represent data directly or indirectly. An interface only defines a set of definitions for properties, methods, events, etc... No implementation, no data, is required.
William E. Kempf wrote: However, the fact that the "coupling is very loose" proves my point, as there's still coupling
If your requirement for "knows" is that there is some coupling, however faint, then by definition any two classes that interact -- even if that interaction is seperated by an arbitrary number of other classes and/or layers of abstraction -- "know" about each other. I disagree with this definition.
There will always be some degree of coupling between a view and a viewmodel by virtue of the fact they do interact. That is pretty much the definition of coupling. If the coupling is restricted to merely an agreed upon interface and runtime binding performed by a resource file, then I would maintian the coupling between the view and the viewmodel is so thin as to be almost non-existent. Neither knows anything significant about the other. Either can be replaced in its entirity with a very high degree of confidence there will be no side-effects. In a very real sense,low coupling equates to a fundamental lack of knowledge about each other.
William E. Kempf wrote: This is the magic of reflection
Again, perhaps a question of semantics, but the data template is not exactly using reflection in the way I think of it. Reflection, to my way of thinking, is used to create associations at run-time that you do not know at design time. The data template is a design time specification for how to handle binding at run-time. The differnce may be subtle, but I think it is relevant.
William E. Kempf wrote: ...patterns are language agnostic, ... From the POV of the pattern, the View MUST know about the ViewModel.
I must admit I don't have a strong reply to this point. It is part of the abstract pattern that the view "points at"/"Knows"/"references"/"is connected to" the view-model. That being said, specific language features of WPF make this connection almost invisible. Certainly far more so than would be possible in Windows Forms or even ASP. I may be wrong, but I think what the language brings to the pattern is worth consideration.
|
|
|
|
|
rbdavidson wrote: My point is that the view does not reference to viewmodel, the data template does. Examine the view and there is nothing in the xaml to tell you what viewmodel it will interact with. The view itself it totally ignorant of its purpose, just as the viewmodel is totally ignorant of how it is to be displayed. The data template in the resource file does not imbue either with any knowledge of the other's function or existence.
That's splitting hairs... but I'd argue that the data template IS the View in this scenario. That's what most of the folks I've talked with would say as well.
rbdavidson wrote: To me, the second statement negates the first. An interface , by definition, does not represent data directly or indirectly. An interface only defines a set of definitions for properties, methods, events, etc... No implementation, no data, is required.
Not really. You've got to remember that types are a compile time construct, while data is a runtime construct. A data template isn't going to be "inflated" unless you've referenced data. Which template is used is based on the type. So, both of my statements are valid and nothing was "negated".
rbdavidson wrote: Again, perhaps a question of semantics, but the data template is not exactly using reflection in the way I think of it. Reflection, to my way of thinking, is used to create associations at run-time that you do not know at design time. The data template is a design time specification for how to handle binding at run-time. The differnce may be subtle, but I think it is relevant.
Not really. The end result is, we have runtime UI code that does data binding. Data binding uses reflection to move data to and from objects that exist during runtime. There's further indirections in play with data templates, as the runtime UI objects are inflated dynamically as well, but I see no way that this is relevant to the discussion of this topic?
rbdavidson wrote: I must admit I don't have a strong reply to this point. It is part of the abstract pattern that the view "points at"/"Knows"/"references"/"is connected to" the view-model. That being said, specific language features of WPF make this connection almost invisible. Certainly far more so than would be possible in Windows Forms or even ASP. I may be wrong, but I think what the language brings to the pattern is worth consideration.
Implementation details are worth consideration only at the implementation level. I saw nothing in the article's usage of the bullet point that made the discussion relevant to an implementation detail.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: That's splitting hairs... but I'd argue that the data template IS the View in this scenario.
Consider
<!--
This template applies a CustomerView to an instance
of the CustomerViewModel class shown in the main window.
-->
<DataTemplate DataType="{x:Type vm:CustomerViewModel}">
<vw:CustomerView />
</DataTemplate>
I would say the view is CustomerView, which is ignorant of the viewmodel CustomerViewModel. The data template is just a static association between the two. i.e. When CustomerViewModel is displayed, the CustomerView will be used. The data template does not itself specify how the data will be shown, just which view is responsible for showing the data.
William E. Kempf wrote: That's what most of the folks I've talked with would say as well.
Citing unspecified others is not an argument that lends itself to objective analysis. Its pretty easy to find all sorts of examples where most people thought something that was demonstrably wrong.
William E. Kempf wrote: A data template isn't going to be "inflated" unless you've referenced data. Which template is used is based on the type. So, both of my statements are valid and nothing was "negated".
This really doesn't address my point that the view knows nothing about the viewmodel in this instance. It doesn't know which class it is associated with or anything about the class. The "inflation" at run-time is irrelevant. The knowledge is not there at compile time.
William E. Kempf wrote: The end result is, we have runtime UI code that does data binding. Data binding uses reflection to move data to and from objects that exist during runtime.
Perhaps we are using the term reflection in two different ways here. No doubt the .Net library makes use of reflection often to do a variety of tricks, but that is not the same as me using reflection. The data template to me is a black box. I tell it the association I want at compiler time and at run-time it enforces the asociation. How it does this is not relevant, so long as it enforces the association reliably. This is not, to my way of thinking, the same as me writing code that manually checks the type of an object at runtime and makes branching decision based upon the result.
William E. Kempf wrote: see no way that this is relevant to the discussion of this topic
You introduced reflection into the topic. I merely responded with an objection to the use of the word in this context.
William E. Kempf wrote: Implementation details are worth consideration only at the implementation level. I saw nothing in the article's usage of the bullet point that made the discussion relevant to an implementation detail.
You wrote:
Your interpretation of MVVM is questionable. First, the View MUST know about the ViewModel in order to bind data and invoke commands/events.
In resposnse to the articles claim that the view and viewmodel could be ignorant of eah other. This was a paragraph that referneced multiple WPF language specific details. This makes his claim implementation specific, and implentation details relevant.
|
|
|
|
|
rbdavidson wrote: I would say the view is CustomerView, which is ignorant of the viewmodel CustomerViewModel. The data template is just a static association between the two. i.e. When CustomerViewModel is displayed, the CustomerView will be used. The data template does not itself specify how the data will be shown, just which view is responsible for showing the data.
That CustomerView does data binding, so it KNOWS about the CustomerViewModel. Sorry, I just simply can't agree with any other interpretation. The knowledge is very loose, as you say, but it's still there.
rbdavidson wrote: Citing unspecified others is not an argument that lends itself to objective analysis. Its pretty easy to find all sorts of examples where most people thought something that was demonstrably wrong.
If that were the only argument I'd made, you'd have a point. However, this was not the basis of my argument, but only a comment. So, you're being defensive here.
rbdavidson wrote: This really doesn't address my point that the view knows nothing about the viewmodel in this instance. It doesn't know which class it is associated with or anything about the class. The "inflation" at run-time is irrelevant. The knowledge is not there at compile time.
I never said the View knows "which class". I said it knows about the ViewModel. You can't do data binding without knowledge of what your binding to, plain and simple.
rbdavidson wrote: Perhaps we are using the term reflection in two different ways here. No doubt the .Net library makes use of reflection often to do a variety of tricks, but that is not the same as me using reflection. The data template to me is a black box. I tell it the association I want at compiler time and at run-time it enforces the asociation. How it does this is not relevant, so long as it enforces the association reliably. This is not, to my way of thinking, the same as me writing code that manually checks the type of an object at runtime and makes branching decision based upon the result.
Whether you're doing it directly, or the framework is doing it for you, makes no difference. You're using reflection, or if you prefer, late binding. Data binding is not static, but dynamic. And I never once said anything about checking the type of an object at runtime and making branching decisions upon the result, as that is NOT what's happening here.
rbdavidson wrote: You introduced reflection into the topic. I merely responded with an objection to the use of the word in this context.
I talked about reflection in context, while the areas you moved the discussion were no longer in context.
rbdavidson wrote: In resposnse to the articles claim that the view and viewmodel could be ignorant of eah other. This was a paragraph that referneced multiple WPF language specific details. This makes his claim implementation specific, and implentation details relevant.
There was nothing in the claim that was relevant to any WPF specific implementation details in a way that negated the pattern's association of the View and ViewModel.
William E. Kempf
|
|
|
|
|
I am back to my original belief that we are dancing on the heads of semantic pins. The distinction between most of our positions appears to me to be a matter of how we define cetain words and which hairs we split.
For example:
William E. Kempf wrote: That CustomerView does data binding, so it KNOWS about the CustomerViewModel.
I see your point, but I object to the word "KNOWS". Nothing in the XAML of the CustomerView references, in any way, the CustomerViewModel either directly or indirectly. The only assoication between them is provided outside of either the view or viewmodel, in this case a data template with only a single line of code. Remove that line and I think we would both agree the view has zero knowledge of the viewmodel. Adding that line I agree provides the CustomerView a runtime reference to a particular viewmodel, but I cannot call that "knowledge" in the way I define the word.
William E. Kempf wrote: rbdavidson wrote:
Citing unspecified others is not an argument that lends itself to objective analysis. Its pretty easy to find all sorts of examples where most people thought something that was demonstrably wrong.
If that were the only argument I'd made, you'd have a point. However, this was not the basis of my argument, but only a comment. So, you're being defensive here.
I mean no offense here, nor am I accusing you of anything, but I have often seen people cite popular believe as a way of defending a position. It is a form of arguement I reject out of hand, for the reason I gave in my original post. That is all I meant.
William E. Kempf wrote: You can't do data binding without knowledge of what your binding to, plain and simple.
Again I think we are spltting hairs here.
My position is that at compile time, the view has specification for what it will expect at runtime, and that this specification is not coupled to any viewmodel. At runtime, when the binding actually occurs, the view is given a reference to a particular viewmodel and the managed environment attempts to bind the two together. If this binding fails, both view and viewmodel continue to act correctly, though their interaction becomes more limited.
If you claim this level of reference constitues the view "knowing" the viewmodel, then my reply is that we define "knowing" in different ways. "Knowing" to me implies a dependancy that can create unpredictable behavior when either the view or viewmodel is changed. That level of "knowing" is not present in this scenario.
William E. Kempf wrote: Whether you're doing it directly, or the framework is doing it for you, makes no difference. You're using reflection, or if you prefer, late binding. Data binding is not static, but dynamic. And I never once said anything about checking the type of an object at runtime and making branching decisions upon the result, as that is NOT what's happening here.
Late us agree to use the term "late binding" since reflection has a different connotation to me. An no you did not mention checking object types,I was using that as an example of what I call reflection. Once we restrict ourselves to late binding, then I agree with you.
William E. Kempf wrote: I talked about reflection in context, while the areas you moved the discussion were no longer in context.
I believe this tangent originates from the fact you conflate refelction and late binding while I do not. While you may have thought your comments where in context, I did not see them that way, just as you did not see mine as a response to your point. i.e. We were talking cross purposes because we defined words differently.
|
|
|
|
|
rbdavidson wrote: I see your point, but I object to the word "KNOWS". Nothing in the XAML of the CustomerView references, in any way, the CustomerViewModel either directly or indirectly. The only assoication between them is provided outside of either the view or viewmodel, in this case a data template with only a single line of code. Remove that line and I think we would both agree the view has zero knowledge of the viewmodel. Adding that line I agree provides the CustomerView a runtime reference to a particular viewmodel, but I cannot call that "knowledge" in the way I define the word.
We're certainly splitting hairs. Remove that one line of code, and nothing is displayed! That's pointless. The instant the runtime actually displays something (the View in the pattern), that something uses data binding to display data (the ViewModel in the pattern), and thus knowledge of the ViewModel is explicit in the View. In the WPF implementation this knowledge is loose, due to how data binding uses reflection, but it's still there. You can't ignore this fact, or minimize it's importance to the pattern. You're trying to hard to reason (incorrectly) about an implementation detail, ignoring the realities of the pattern.
rbdavidson wrote: My position is that at compile time, the view has specification for what it will expect at runtime, and that this specification is not coupled to any viewmodel. At runtime, when the binding actually occurs, the view is given a reference to a particular viewmodel and the managed environment attempts to bind the two together. If this binding fails, both view and viewmodel continue to act correctly, though their interaction becomes more limited.
It most certainly IS tied to a ViewModel. The relationship is loose, but it's still there. The pattern doesn't dictate coupling to a concrete static type, only a coupling. You'll be following the pattern if you use a concrete static type, an abstract static type (including interfaces), or a dynamic type. Those are implementation details, and aren't relevant to the pattern.
rbdavidson wrote: Late us agree to use the term "late binding" since reflection has a different connotation to me. An no you did not mention checking object types,I was using that as an example of what I call reflection. Once we restrict ourselves to late binding, then I agree with you.
Late binding and reflection are one and the same thing, really. In the .NET world, late binding is done via the reflection APIs.
rbdavidson wrote: I believe this tangent originates from the fact you conflate refelction and late binding while I do not. While you may have thought your comments where in context, I did not see them that way, just as you did not see mine as a response to your point. i.e. We were talking cross purposes because we defined words differently.
That's why we shouldn't make up our own definition of words.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: Late binding and reflection are one and the same thing, really. In the .NET world, late binding is done via the reflection APIs.
Now you are mixing an implementation specific detail with an abstract concept. Late binding and reflection are not one and the same. The fact that .Net achieves late binding through reflection does not make them the same. It is entirely possible to have reflection without late binding, and late binding without reflection. I'll grant you, reflection makes late binding significantly simpler to implement, but it is not a requirement in the defintion of the term late Binding. It MS later changed their late binding to not be dependant upon reflection, code would still compile but your point falls apart.
William E. Kempf wrote: You're trying to hard to reason (incorrectly) about an implementation detail, ignoring the realities of the pattern.
Actually, I am pointing out, correctly, that we use words differently and are deriving different meaning based upon how each of us interpret the other's words. Your definition is not better or worse than mine, but it is different. If we restrict ourselves to more formal language I doubt there is much difference between our positions. For some reason, you don't seem willing to grant this point.
I do not debate your points about the abstract defintion of MVVM. I do disagree with your word choice as it applies to implementation specific features of WPF. I think your word choice is accurate in other cases, say Windows Forms, because the language features do not support the same level of seperation that WPF provides. Abstract modeling cannot, by definition, capture implementation specific details. Specific implementations can, and do, bend and break abstract concepts. When that happens the language must be refined to describe what happens at the implementation level more accurately. To me, that is what is happening here. You disagree. It doesn't make me wrong, nor you right, nor vice-versa.
|
|
|
|
|
rbdavidson wrote: Now you are mixing an implementation specific detail with an abstract concept. Late binding and reflection are not one and the same. The fact that .Net achieves late binding through reflection does not make them the same. It is entirely possible to have reflection without late binding, and late binding without reflection. I'll grant you, reflection makes late binding significantly simpler to implement, but it is not a requirement in the defintion of the term late Binding. It MS later changed their late binding to not be dependant upon reflection, code would still compile but your point falls apart.
http://en.wikipedia.org/wiki/Reflection_(computer_science)[^]
There's a formal definition for reflection. It's impossible to do late binding without reflection. If you were to try and make a distinction between the two formally, the only distinction would be that late binding is used to invoke (which can only be done by first using reflection), while reflection is only used to inspect. That would be splitting hairs to the point of being meaningless, IMHO.
Yes, we certainly have a problem with communication, which I find surprising, considering I'm using the terms as others in the industry use the terms.
rbdavidson wrote: I do not debate your points about the abstract defintion of MVVM. I do disagree with your word choice as it applies to implementation specific features of WPF. I think your word choice is accurate in other cases, say Windows Forms, because the language features do not support the same level of seperation that WPF provides. Abstract modeling cannot, by definition, capture implementation specific details. Specific implementations can, and do, bend and break abstract concepts. When that happens the language must be refined to describe what happens at the implementation level more accurately. To me, that is what is happening here. You disagree. It doesn't make me wrong, nor you right, nor vice-versa.
Implementation specific features don't change the pattern, making everything else you've said here irrelevant. To prove the point, I could easily implement the pattern in either WinForms or WPF using any of the three methods of binding (to a concrete type, to an abstract type, or to a dynamic type). In every single case, the View still knows about the ViewModel, all that's changed is how it knows about it.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: There's a formal definition for reflection.
Which in no way mentions late binding. Congratulations, you proved my point that they are not one and the same.
William E. Kempf wrote: It's impossible to do late binding without reflection.
This is totally false. Means of doing late binding have existed since the earliest days of computer science, well before reflection was concieved.
For example, I could create a program that passes data between controls on a form and classes by wiring events to handlers at runtime based upon some set of dynamic conditions. The handlers can manually update the controls or class as needed. No reflection needed.
If that does not satisfy you, I can have a timer fire off one of several routines with a massive switch statment that manually updates class or screen as needed. Have which routine is executed determined by runtime conditions. Late binding with no reflection needed.
Still not satisfied? How about several routines, each running in seperate threads, that constantly loops over all the controls on the screen and the propertiess of the class to see if anything changed. Hardwire the references in the threaded routines to avoid using reflection and have which routine actually updates which class/screen determined by runtime conditions. Late binding, no reflection.
None of these approaches require reflection, but all would constitute a form of late binding. Granted, psychotic and deranged forms, but ones that meet the definition of late binding.
As I said, reflection makes it easier to do late binding, but is not a requirement. Reflection and late binding are two different concepts.
William E. Kempf wrote: Yes, we certainly have a problem with communication, which I find surprising, considering I'm using the terms as others in the industry use the terms.
I'm certain you often talk with people who use language the same way you do. So do I. I get my terms from books on the subjects I talk about, from classes I took, articles I have read, and so forth. I assume you do to. Guess what, my point about language still holds. We both work in the same industry, but that does not meen every single person in this industry uses language exactly like you do.
William E. Kempf wrote: Implementation specific features don't change the pattern,
I never claimed it did. I objected to your use of specific words and said that specific implementations can make certain description inaccurate. When that happens, language must be refined to address that inaccuracy. That was the point I was making, and it is a correct one.
|
|
|
|
|
rbdavidson wrote: Which in no way mentions late binding. Congratulations, you proved my point that they are not one and the same.
Lack of reference in no way proves anything.
rbdavidson wrote: This is totally false. Means of doing late binding have existed since the earliest days of computer science, well before reflection was concieved.
Wha?!?!! Are you kidding?!??!! I thought you read the Wikipedia definition.
Wikipedia wrote: In computer science, reflection is the process by which a computer program can observe and modify its own structure and behavior.
You can't do late binding without observing the structure. You can't argue against that point.
rbdavidson wrote: For example, I could create a program that passes data between controls on a form and classes by wiring events to handlers at runtime based upon some set of dynamic conditions. The handlers can manually update the controls or class as needed. No reflection needed.
That's also not late binding, at least not as I've ever heard the term described (it's harder to find a formal definition of this one, but it's generally used in terms of dynamic languages, which must observe the structure (reflection!) at runtime).
So, it seems, you've got a different definition for late binding. OK, I'll go with that. Your definition in no way changes any of the things I've said! All of my points still stand.
rbdavidson wrote: I never claimed it did. I objected to your use of specific words and said that specific implementations can make certain description inaccurate. When that happens, language must be refined to address that inaccuracy. That was the point I was making, and it is a correct one.
It's not "correct", but "argumentative", since IT DOESN'T INVALIDATE ANY OF THE POINTS I'VE MADE. Especially when one considers that WPF uses REFLECTION to implement data binding. If this hair is going to be split as finely as you want to, we should NOT call this late binding, but reflection, as that is precisely what the implementation uses.
What's extremely frustrating here is, NONE OF THIS META DISCUSSION MATTERS, and you've admitted it. The original point I made here stands, regardless of any of this. The View depends on/knows about/references/is coupled to the ViewModel. This fact is what was incorrectly argued against in the article.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote: Lack of reference in no way proves anything.
If they are the same, find me one authoritative source that states so. You quoted wikipedia, it does not state so. Any other sources you care to try?
William E. Kempf wrote: Wha?!?!! Are you kidding?!??!! I thought you read the Wikipedia definition.
Exactly how is this a response to my statement. My statement can be backed up, if you so desire, by examining the history of computer science. Go do the research, let me know if you find anything wrong with what I said.
William E. Kempf wrote: That's also not late binding, at least not as I've ever heard the term described (it's harder to find a formal definition of this one, but it's generally used in terms of dynamic languages, which must observe the structure (reflection!) at runtime).
You are refering to implementation specific versions of late binding, not the abstract concept. (The irony here is delicious.) The abstract concept is merely that data relationships between different elements in a program are determined at runtime, not design time. Reflection came along much later and allows for things that use to be very hard to do to now be much easier.
Reflection is also not late binding, because some of the things you do with reflection have nothing to do with binding. For example, you can have an if statement determine which calculation to perform or function to call depending on the type of an object. Reflection without any binding.
William E. Kempf wrote: Your definition in no way changes any of the things I've said! All of my points still stand.
I never claimed it did. I said you were conflating the two concepts and I was not, which caused us both to misunderstand the other and sent us off onto a tangent. You continued to insist they were one and the same and that I was wrong to think otherwise. To be honest, I found the way you expressed your view to be condescending and decided I needed to justify my point that they are different. I think, at this point, I have.
William E. Kempf wrote: It's not "correct", but "argumentative", since IT DOESN'T INVALIDATE ANY OF THE POINTS I'VE MADE. Especially when one considers that WPF uses REFLECTION to implement data binding. If this hair is going to be split as finely as you want to, we should NOT call this late binding, but reflection, as that is precisely what the implementation uses.
I said quite a few posts back that I thought we differed mainly by our use of language. You keep insisting I'm somehow wrong and argumentative because I don't agree with you.
Go back and I think you will find it hinges on you saying the view must "know" about the viewmodel. I disagreed with use of the word "know" as that carries connotation I think are not accurate. I did grant that the view must, at some point, be bound to the viewmodel.
Replace "know" with "dynamically bound" and there is little deifference between our positions. For some reason, you seem unwilling to allow for there to be a distinction between the view "knowing" about the viewmodel and it being "dynamically bound" to the viewmodel. "Knowing" and "bound" are very different in my mind, and hyperventalating about how they aren't different isn't going to change my mind.
I tried end this a while back by saying we were defining words differently, that neither of us was wrong just miscommunicating. You seem to really want to win this debate. Apparently that means making me admit you were right all along in your choice of words. I'm not going to do that, because I fundamentally disagree with what those words imply in this context.
If you want to go round and round on "knowing" versus "bound" and whip out definitions of terms, I'm game. Truthfully though, I don't see the point. It is a matter of semantics, which is subjective. Something I said many posts ago. Still, I'm game if you are.
|
|
|
|
|
I think I have to step in and put a halt on this. Consider me to be Switzerland
I don't think either of you are making constructive arguments anymore, seems to be a game of "you said/I said". I thank you for your interest on the topic, but if you are going to flame each other, please do it elsewhere and not on my post.
Sorry that one of you got the last word, but there is nothing to be done about that.
Best regards,
Disore
Why is it drug addicts and computer afficionados are both called users?
--Clifford Stoll
|
|
|
|
|
I knew I would get my ass kicked by a Disciple
William E. Kempf wrote: With regard to Onyx, the ViewModel and View are not connected at compile time, but at runtime, as attached properties are a runtime concept.
My point is that View and ViewModel are declared in compile time even though they are connected at run time. Let me rephrase and instead ask you whether it's easy to change the ViewModel (type or class) of a View in runtime when using Onyx?
Don't get me wrong, I think Onyx is a fantastic framework, actually the best attempt to handle MVVM issues, but my concern is that it's the only one. This idea of the article was to bring forth a different solution.
William E. Kempf wrote: Out of the box, it also does not do dependency injection, but rather uses the Service Location pattern, though I am working on enabling DI to be done using one's own solution. IOW, there's no limitation in how you use Onyx for either point you try to make here.
My bad, I will make appropriate changes tonight.
William E. Kempf wrote: What would a ViewModel contain that's "used purely in tests"? I honestly can't think of any code that would ever be put in any class that's solely used in tests.
The last time I saw it was in a post by Kent Boogaart. The ctor of the ViewModel is written in a way that both handle application execution and testing. I think it would have been better to use DI, since the same code then would have been executed both when application is running and during tests. Btw, I think Kent Boogaart has written some very important blog posts and admire his work.
William E. Kempf wrote: Granted, most of this can be dealt with by interacting solely with the ViewModel for the dialog instead, but that's not possible when dealing with legacy dialogs, such as the common dialogs.
I agree, one should interact with the ViewModel instead of the View when possible. Tawani Anyangwe asked me the same question, but I have yet no answer to give you.
Best regards,
Disore
Why is it drug addicts and computer afficionados are both called users?
--Clifford Stoll
|
|
|
|
|
disore wrote: My point is that View and ViewModel are declared in compile time even though they are connected at run time. Let me rephrase and instead ask you whether it's easy to change the ViewModel (type or class) of a View in runtime when using Onyx?
It's no more declared in compile time than your DataContext code here was. Yes, it is very easy to change the ViewModel of a View during runtime in Onyx.
View.SetViewModel(myView, new SomeNewViewModel(myView));
The view isn't aware of the ViewModel's Type in Onyx. The View.ViewModel attached property just supports type coercion from a Type to an instance of that Type. View.ViewModel is an Object property.
disore wrote: Don't get me wrong, I think Onyx is a fantastic framework, actually the best attempt to handle MVVM issues, but my concern is that it's the only one. This idea of the article was to bring forth a different solution.
I encourage alternate solutions, and this is a nice little concept. I only want to set the record straight with regards to incorrect assumptions you've made about Onyx.
disore wrote: The last time I saw it was in a post by Kent Boogaart. The ctor of the ViewModel is written in a way that both handle application execution and testing. I think it would have been better to use DI, since the same code then would have been executed both when application is running and during tests. Btw, I think Kent Boogaart has written some very important blog posts and admire his work.
There's no code there that's used only in testing, which is how I read your quote. I'd agree that DI might be a better solution here, but it's also a whole lot more complicated to do. I see nothing wrong with this specific example.
disore wrote: I agree, one should interact with the ViewModel instead of the View when possible. Tawani Anyangwe asked me the same question, but I have yet no answer to give you.
I believe the only answer is the one used in Onyx (not the specific implementation, but the concept). Legacy Views won't support this concept of working with the ViewModel, as they don't have one.
Again, though, don't take the criticism as "getting your ass kicked". This was a very good article, with a very nice solution.
William E. Kempf
|
|
|
|
|
Dead on excellent simple approach. You have my 5.
I have also used Marlon Grech's mediator approach before to broadcast and trap Dialog Requests. But I think this approach is simpler and to the point when opening Dialog Windows .
Question:
How do you plan to handle arguments and callback functions when handling cases such as OpenFileDialog ?
something of the format:
<font color="blue">bool</font> ShowDialog<T>(<font color="blue">object</font> ownerViewModel, <font color="blue">object</font> viewModel, <font color="blue">out object</font> result) <font color="blue">where</font> T : <font color="teal">Window</font>
modified on Tuesday, May 26, 2009 3:37 PM
|
|
|
|
|
Haven't actually thought about the OpenFileDialog. Let me think about it and get back to you on that.
Why is it drug addicts and computer afficionados are both called users?
--Clifford Stoll
|
|
|
|
|
The dialog service have now been updated with a method capable of showing the OpenFileDialog, and adding more framework dialogs is easy.
Sorry for the wait, my priorities have been elsewhere.
Why is it drug addicts and computer afficionados are both called users?
--Clifford Stoll
|
|
|
|
|
This is the most elegant way I've seen yet to handle dialogs and messageboxes in MVVM. Nice work.
|
|
|
|
|
Thanks, glad you liked it
Why is it drug addicts and computer afficionados are both called users?
--Clifford Stoll
|
|
|
|
|