On Tue, Feb 16, 2010 at 8:53 AM, Supercobra Thatbytes <[email protected]> wrote: >> My first take away was that their were a few rules: >> 1) Presenters don't know about specific GWT widgets (so that you can >> test your business logic without GWTTestCase) >> 2) Displays don't know about business logic >> 3) Displays don't know about application logic >> 4) Displays don't know about model classes >> >> I still consider the first 3 to be sacrosanct, but I have pretty much >> dropped rule #4. > > Dropping rule #4 maybe saving time and make the code read more clearly > but it will still tie your display class to a model - which may be OK > - if you accept the constraints. For example if you have a speedometer > display and want to display your car speed > > new SpeedoMeterView(Car car)... > > then you won't be able to display a motorbike speed: > > new SpeedoMeterView(Bike bike) ... > > unless you modify your SpeedoMeterView which is why you should NOT use > a model but use primitive types instead: > > new Speedometer(float mph)
This seems like a very valid point. Thanks for pointing that out. You can't reuse your view code for other (similar, but not the same) models. That's certainly an advantage. The question in my mind (which I still have to think about): Aren't most (if not all) views already very much tied to what the model represents? Sure, if you are writing a view that's very generic in nature and you want to reuse it in several places in your app, but practically speaking are there a lot of cases like that? I.e., in practice, are there a significant number of views that you end up reusing with several different models in your app? Not sure that a lot come to mind. In general, I don't think *any* design patterns are sacrosanct. I very often find that parts of those patterns need to be tweaked a bit to better fit into a particular situation while still maintaining the original idea (and most other components) of the pattern. I think it's very helpful to try to come up with reasons pro/against a certain component of a pattern (MVP in this case). In my particular case, I am trying to convince myself that pure MVP is better (or worse - whatever it comes out to be)... So, I think so far, it looks like not having your View depend in ANY way on the Model has the following advantages: 1) Can't (easily) reuse the view for other Models. 2) Poses a risk (if not careful yourself, have other less experienced developers on the team, tempting to cut corners, etc.) of introducing state into your View. (from Nathan's next posting). Advantages of passing the Model object directly to the view 1) Since View knows its own visual components very well, it's easier to unwrap the property values of Model and set those components to those values. All this without having to expose every visual field to the Presenter. Did I miss anything we've mentioned? Can anyone come with some others (pro or against)? Regards, Yaakov. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
