Hi Dalla, There are quite a few variations on MVC, I my opinion GWT is best implemented using A MVC variation similar to swing. First consider this article; http://www.javaworld.com/jw-04-1998/jw-04-howto.html?page=1
Often the whole MVC Framework (dealing with a button component in the above example) is packaged into a Component (Widget). For instance look at the GWT Button Class http://google-web-toolkit.googlecode.com/svn/trunk/user/src/com/google/gwt/user/client/ui/ Do you see a ButtonModel or ButtonController in the GWT code (.java files)? No Does this mean the GWT Buttons violate the MVC pattern? No This means that the developer who wrote this code decided to package the MVC concept as a single Component or Widget. The MVC variation that you describe below seems to what I call the Active Model variation. Personally I don't use this but use the Passive Model variation which is more similar to most Struts (and Spring) MVC applications. Where the model classes are just a pojo (often something like a Hibernate entity). My main dislike of Active Models is due to all of the extra Observible code and some memory leaks that I have had to chase down in my career which were caused by the listners hanging on to references that should have been removed (because they were no longer used) . So the debate in a GWT project really comes down to the question; When is breaking out the code into Models, Views and Controller(s) better than keeping them together as a component? So heres my opinion on that; Models, almost always break out models into classes except when the model will not be used outside of the component or widget. I argue that pojos make the best models and your probably already doing this for something like Hibernate. Or in other words; If the model is used by more than one class (Person entity model) break it out. If the model is only needed to maintain the component keep it in (Button Model). Views(Panels (according to the Ivar Jacobson deffinition), Composites according to the GWT defennition). I think most of the time it makes sense to keep the control code packaged with the component. Also for control code packaged this way, I believe it only makes sense for this control code to manage or control things inside or under of the scope of the component. For things that are not in the scope of the component, the Observable pattern should be used, which may (and often does) lead to one Panel (View) controlling another Panel (View). So when should the control code not be placed in the ui (View, Panel)? When the control logic is no longer scoped to a view. So to finally answer your question. I think it would be fine to have your Composite(I think u called this a flex table) implement HasSelectionHandlers and show a dialog with the details, as this is all with in the scope of your Component And finally; I do think breaking out code into MVC classes is justified in GWT, for instance when the control code can configured in a manor for reuse. Here is a Example; http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true source http://cvs.adligo.org/viewvc/gwt_util_demo/ In this MVC framework I use the Mediator pattern for a Singleton I call the Controller. You may find this similar to the ControllerServlet in Struts or the DispatcherServlet in Spring. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/I_Controller.java?view=markup http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/Controller.java?view=markup This class then has two maps of Observers; One map mediates communication to the control logic (I_Listener's) view -> sends event -> controller mediates to -> I_Listener The other mediates communication from the control logic (I_Listener's) view<- calls setFoo() <- I_Listener <- controller mediates to <- I_Listener So whats a good rule of thumb? Break out your Control code for RPC calls. It will help you to reuse your Panels (Views, Composites, Widgets). It will allow you to reuse your RPC callback instances. It will give you more maintainable code, which will adapt to changing requirements faster. Also it will allow you to change out your code to enable client side caching if you need it. exc... Cheers, Scott On Jun 15, 4:02 pm, Dalla <[email protected]> wrote: > Any MVC / GWT experts out there? :-) > > On 14 Juni, 14:09, Dalla <[email protected]> wrote: > > > Hi all! > > > I´ve been working pretty much with MVC in Struts 2, but it´s a pretty > > different story using MVC, so I have a question. > > > From what I´ve read, It´s pretty much: > > > On user input, View calls Controller. > > Controller updates Model. > > Model fires event, which is observed by the View. View updates based > > on fired events. > > > I´m wondering if it´s possible for the View to update itself without > > breaking the MVC pattern? > > > For example, let´s say that I have a composite Widget containing a > > FlexTable inside a scrollpanel, with a list of objects, showing just > > one or two properties for each object. > > When the user clicks on a row in the flex table, I want to show a > > dialog box containing all the details about the clicked object. > > > In this case there would be no reason to update the model now would > > there? So there would be no reason to call the controller? > > Would it be OK to let my flex table implement the HasSelectionHandlers > > interface and have the widget implement SelectionHandler, > > telling the widget to show a dialog box when the SelectionEvent is > > fired? > > > Or would this be breaking the MVC pattern? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
