I currently don't use MVP, but more like MVC where the View and Controller are sometimes in the same class (when the views/controllers are rather trivial), but regarding the example that Supercobra gave, and to answer your question Yaakov:
Another way of sending model information is using interfaces. For instance, if I knew that I would be displaying a speedometer for car and a bike (and maybe something else as well), I would have done something like: new SpeedoMeterView(Vehicle vehicle)... where Vehicle is an interface with methods that provide access to all properties that the SpeedometerView needs. I do this a lot to with my views. To me, this is a lot better in terms of maintainability, readability and productivity, than just using primitives, especially when you have complex models. On Feb 16, 11:31 am, Yaakov Chaikin <yaakov.chai...@gmail.com> wrote: > On Tue, Feb 16, 2010 at 8:53 AM, Supercobra Thatbytes > > > > <dan...@metadot.com> 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 google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
