Thank you, much appreciated :) On Aug 14, 2:25 am, Thomas Broyer <[email protected]> wrote: > On 14 août, 01:07, dmen <[email protected]> wrote: > > > Hi, consider a panel that starts by showing a couple of buttons. When > > you press a certain button, the panel expands with a form and an > > anchor link. When you click the link, the panel expands once again > > with some html content. The actual business purpose of the panel is > > the form. > > > Everything is coded within the component and works fine. Now I'd like > > to experiment with the View/Presenter pattern and move behavior from > > the panel (view) to the presenter. > > > My questions are: > > 1. Should the presenter handle all interactions (e.g. the expanding) > > or just the "business" form submit? In other words, should the > > presenter also handle behaviors that only affect the internal state of > > the view? > > This is a presenter, not a controller. The goal is that the presenter > updates the view in response to events (listened to in the view and > forwarded back to the presenter). > Whether you'll have a onHyperlinkClicked with the presenter toggling > the view's expanded state, or an onExpanded with the presenter loading > data and pass it to the view (the view then toggling the display) > depends on which widget you use in your view (DisclosurePanel, > possibly with a LazyPanel as its child) and how the expandable > panel's content comes from. > If you use a DisclosurePanel with static content, for instance, then > you won't have the toggling logic in the presenter, everything will be > in the view only. > > > 2. In the case of moving all behavior to the presenter, should it fire > > application events in all circumstances? e.g. panel-expanded event and > > so on.. > > On the event bus? No! only events that are deamed "external" (is your > panel currently firing such events?) > And remember: stay pragmatic, don't code things if YAGNI. > > > 3. In the case of firing app-events in all circumstances, would you > > delegate the call to the actual handler method (within the same > > presenter class) to the event-bus handler or would you call it > > directly from the presenter? > > n/a > > > 4. Swing component architecture has View and Presenter integrated in > > the same class. Would you consider using separate classes for all > > components or maybe for "heavy" cases? > > Swing uses MVC, not MVP. MVP is (should be?) at a higher level. You > could even keep the same presenter but give it a Swing view (instead > of GWT view) if you liked. There are precendents (a chess game in GWT > for the Web, and Android for handsets) > FYI, the new Cell widgets in GWT 2.1 have an internal presenter helper > object. This is so that you use them just like any widget, and not as > an "MVP component" in your "MVP application" (this is the business of > Activities in GWT 2.1, which are where you do MVP in an "MVP > application"). > > It all depends what you consider your panel like (and how you'll use > it in your app): a widget or a higher-level component (business > component?)
-- 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.
