On 20 oct, 14:02, Tobias <[email protected]> wrote: > I recently tried out the new cell-widgets in GWT2.1 and I'm planning > to replace my homegrown solutions with these. However I came across a > problem: All the examples, e.g. the "Expenses"-App, that use these > widgets use them within a Composite which at the same time implements > "Activity", apparently being Presenter and View at the same time. So I > was wondering would be the best approach to separate out those two > aspects? > > One obvious problem is the Cell-subclass itself, whose render-method > usually depends on the model object. If it's as simple as making a > "getName()" call to the model object, that is fine with me, although > it technically violates the MVP-pattern.
Actually not. Not if by MVP you mean Supervising Controller, and not Passive View (and even then, I'm not quite sure). MVP does not dictate that your view shouldn't know about your model objects. What it tells you is that the view shouldn't change the model by itself (use data binding with a supervising controller, or do it in the presenter when you have a passive view), and shouldn't ask for data (it should ask the presenter; or the presenter should give the view everything it needs pro-actively). http://martinfowler.com/eaaDev/uiArchs.html#Model-view-presentermvp http://martinfowler.com/eaaDev/SupervisingPresenter.html http://martinfowler.com/eaaDev/PassiveScreen.html > But if there are calculations > necessary for providing the cell content, e.g. calculating percentages > to visualize a value with a bar-chart in a table cell, it would be > better to do that in a separate presenter that can be tested. Do the coding in a static (stateless) method of your Cell, so you can test the method. Also, a Cell might very well be unit-tested (without reliance on GWTTestCase), but testing the "calculation method" should be enough IMO. > Should I > use a Delegate interface in the View for that, that the Activity/ > Presenter implements so the calculations can be done there? > > Are there any examples of using these widgets in a traditional MVP > environment? The "Large scale application development and MVP - Part > II" uses generics to hide the actual the model classes from the view, > would it be sensible to do the same thing when using the Cell-Widgets? > It seems possible, but from the current design of the Cell-Widgets and > the provided examples I get the feeling, that they are not really > meant to be used in that way. Cell widgets are, well, widgets; so all interactions with them should go into the view, unless you can do everything you want against the HasData interface (you could then ask the view for its HasData). But the use of this cell or this other one, which data columns to show, with which headers, is a "view" thing. (that being said, I don't know what "traditional MVP environment" means; and the fact that Martin Fowler split MVP into several patterns is a sign that there's no "one true MVP way") (note that I haven't carefully read and studied Martin Fowler's articles, as I don't think blindly following "best practices" is a good thing, so I made my own idea about how *I* would/should implement MVP; and the answer is: there's not one true way, it depends on what you need, such as whether you use Editors or not, etc.) -- 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.
