Sorry, I'm an idiot, I forgot you cannot have Controller.getGroups() just return groups because of it's (possibly) asynch RPC call it should return void, and of course this is really your original question. You can pick up an event that Controller fires when it's ready, you can use a secondary callback mechanism (i.e. GroupWidget sends itself to Controler.getGroups(....) and has a callback method used by Controller to kick off the display update, or (possibly) you can get away with having Controller pre-load the group list at start up time so that Controller.getGroups(..) never causes an RPC call at all (only addGroup(..)). Obviously this will only work if you can be sure that initial load is complete by the time any widget that calls getGroups() is instantiated.
On Dec 3, 12:55 pm, gregor <[EMAIL PROTECTED]> wrote: > I think it depends on this question: How many views (i.e. primary > widgets) in your app need to know about Groups (and therefore need to > get notified if a group is added, deleted or changed)? > > If the answer is one, then the simplest answer is to integrate the > "Create Group" dialog into it and move List<Group> groups into it as > well. The create group dialog could be a pop up, disclosure panel, > whatever, and an inner class of this view. Job done. > > However if the answer is more than one then you probably do need to do > what have been suggesting, i.e. you need to separate Groups out and > treat them as part of an application "Model" independent from the > Views. I think a reasonably classical way to go about this is as > follows: > > 1) You have a Controller that has method List<Group>getGroups(). This > method checks if the groups have already been loaded and if not > executes RPC to get them before returning the group list. It maintains > reference to this list (which is now part of the model). > 2) "Create Group" widget calls this method to get existing groups for > its display, and if a new group is created, it calls a second method > Controller.addGroup(Group group). > 3) Controller.addGroup(..) calls the RPC service to add group to > server model, and if successful adds the new group to the Group list > (the model). > 4) At this point Controller.addGroup() (or possibly the Group list > itself) fires an Event announcing the change. Many people refer to > this as something like a PropertyChangeEvent. So Controller (or > possibly as I say the Group List model object itself) implements a > SourcesPropertyChange interface, and the views implement a > PropertyChangeListener interface. > 5) The views are then registered as PropertyChangeListeners either > with Controller or via Controller with individual model classes (e.g. > Group List). > 6) They will now all have a method (say) onPropertyChanged > (PropertChangeEvent event) from which they can call > Controller.getGroups() again to refresh their displays with the new > data. > > If you have more than one model object that gets handled like this the > question arises as how the listeners (i.e. the views) "know" which one > has changed. Indeed, if your app has a lot of views the question also > arises as to whether they all need to get notified of every event. As > things get more compilcated, you run the risk of creating an "event > storm" that slows the app's responsiveness. > > There are various ways of dealing with both issues, for example. > > a) if ProperrtChangeEvent is equipped with an enum of possible events > (ADD_GROUP,ADD_SOMETHING_ELSE,...,ACTION_A_PERFORMED ETC), client > views can conveniently use a switch statement in their > onPropertyChanged(...) methods to determine if they need to respond to > an event and to ask controller for the appropriate model objects if > they do.. > b) you can use sub classes to create different listener interfaces and > event classes to deal with different functional areas of the > application, and thereby fine tune which views need to listen to which > model changing events thereby reducing the overall number of events > processed. > > This sort of thing isn't directly supported in 1.5.x (you really have > to write it yourself, but you can sort of copy e.g. ChangeListener > stuff), but the new GWT event model (due I believe in 1.6 and > available now via svn in trunk) is much more suited to supporting this > idea. Check out incubator: > > http://code.google.com/p/google-web-toolkit-incubator/wiki/ProposedEv... > > Anyway I hope this has given you as few ideas, and also explains why I > suggested you should make sure you really do need to do this. > > regards > gregor > > On Dec 3, 9:55 am, raxelo <[EMAIL PROTECTED]> wrote: > > > Thanks a lot, Gregor, for such full answer, > > and thanks for link > > > About Controller, i meant that i want to separate business of > > creating > > item in group widget and removing from it from widget itself - it is > > only visual representation of list of groups. > > It only know that he can hold group, provide interface to manage it, > > but what exactly happen with group - it doesn't matter for widget. > > > " What works simplest usually works best." - gold phrase . Thanks > > > Now, i provide two methods for some business action with group > > - first one notifies client app that widget created some group, > > calling controller method with newly created > > group as parameter > > - and second simple method to add new group to widget. So Controller > > implementor decides > > what to do with that "request for group creation" > > > On 2 дек, 20:45, gregor <[EMAIL PROTECTED]> wrote: > > > > Hi Rexalo, > > > > My 2c. What you seem to asking is if there is a standard "right" way > > > to do Model-View-Controller with GWT and/or what is the "best" way to, > > > as you put, "separate this transport/business layer fromwidget.". IMO > > > the answer is that there isn't a standard one, rather several options > > > or approaches. But I would search the group for "MVC" to get a flavour > > > of how many different opinions there are about this. Check this > > > discussion, for example, which is top of the list: > > > >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa... > > > > IMO the difficulty is that both "Controller" and "Model" are slippery > > > concepts in an AJAX web application, whereas "View" is a straight > > > forward concept - it's awidgetof some kind. Some reasons are: > > > > 1) The real "Controller" in an AJAX application is the browser - > > > anything involving a change to the DOM ultimately runs through its > > > event queue (and it also handles request dispatches and fields the > > > responses as well), therefore it is natural forWidget(i.e. view) > > > classes to interact with the browser event queue directly, and this is > > > what GWT does. Because GWT widgets catch, process and sink events > > > routinely anyway it is difficult (but not impossible) to separate them > > > from a separate "Controller" in a clean or meaningful way. > > > > 2) What might we mean when we refer to a "Model" maintained client- > > > side in a GWT application? Is it the "real" domain model for the > > > application, some sub-set of it, or maybe a snapshot of some some sub- > > > set of it? If you think about it, the "real" domain model resides on > > > the server and ultimately whatever sub-set of this is transported to > > > the GWT client must at some point be reconciled with the "real" server > > > model (i.e. the one actually persisted to backing store) always > > > bearing in mind that another client might have changed the "real" > > > model independently in the meantime. > > > > Both these issues can introduce significant complexity. This is not to > > > say that there are not sometimes good reasons to introduce > > > "Controllers" and "Models" client side. An example might be a chat > > > application that uses blocking requests (i.e. comet style) to pick up > > > new messages. But it does imply that doing so introduces layers of > > > complexity to a GWT application that may be unnecessary. > > > > For these reasons I don't think it is automatically the case that "i > > > want to separate this transport/business layer fromwidget" is a > > > necessarily a good design/engineering decision in a GWT app. What > > > works simplest usually works best. However, sometimes it is and there > > > are several approaches to doing it - it depends on what you are > > > actually trying to achieve, not on a matter of (MVC) principle. > > > > regards > > > gregor > > > > On Dec 2, 1:01 pm, raxelo <[EMAIL PROTECTED]> wrote: > > > > > Hi, Gregor! > > > > Thanks forreply. > > > > > I understand that i can't simply use rpc call right inwidgetevent > > > > handler, > > > > but i want to separate this transport/business layer fromwidget. > > > > > Mywidgetsimply shows list of items of some class(Group) and provide > > > > control elements > > > > to manupulate them: edit, delete, add etc. > > > > > I am simply interested in a approach. maybe there is some standart way > > > > advices > > > > > For now - i provide two methods forwidgetclient - > > > > void add(Group) > > > > void onAdd/onSuccessAdd(Group) > > > > > maybe there is some more cultural way ? =) > > > > > On 2 дек, 13:37, gregor <[EMAIL PROTECTED]> wrote: > > > > > > Hi Relaxo, > > > > > > The simplest way is to make your RPC call from addBtn.onClick() using > > > > > an anonymous Callback where this callback's onSuccess(..) method adds > > > > > the new Group List<Group> groups and changes the view as required. > > > > > There may be reasons why this would not meet your requirements, but it > > > > > is not possible to say from your example, i.e. on the face of it you > > > > > do not need the controller interface. There isn't a single "right" way > > > > > to do asynchronous RPC - it is possible to over-engineer it and > > > > > equally it's possible to under-engineer it. > > > > > > If in fact your situation is more complicated than the example > > > > > (leading to a motivation for using this controller interface), > > > > > probably best to give some idea of the overall problem to get further > > > > > advice and options (of which there are several). > > > > > > regards > > > > > gregor > > > > > > On Dec 2, 8:15 am, raxelo <[EMAIL PROTECTED]> wrote: > > > > > > > First of all sorry for my english. > > > > > > > I want to write simple GUIwidgetthat will help me to add and delete > > > > > > some business groops > > > > > > like this. > > > > > > > public class GroupWidget extends Composite implements ClickListener > > > > > > { > > > > > > private Controller controller; > > > > > > private List<Group> groups; > > > > > > > public GroupWidget(List<Group> groups, Controller > > > > > > controller) { > > > > > > this.controller = controller; > > > > > > //buildwidgetskeleton > > > > > > //init > > ... > > read more >> --~--~---------~--~----~------------~-------~--~----~ 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-Toolkit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
