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.
