As far as maintaining state in the display, Yaakov is right for how I use it. I don't store the model beans in the display. I wonder if other folks model classes are more involved than mine; my model classes are basically just baskets of primitives (or other model classes) with semantic names. I have started with Ray's suggestion to decouple the model. Model classes are cached at the AppController level and are attached to eventBus events, but there is not one overarching model available to all presenters and I don't have ValueChangeListeners.
Re: previous message: By "trivial" I meant basically "single line". Not "unimportant", but "immediately, visually obvious" In other words, I wouldn't be tempted to write a unit test to see if it really does it. Perhaps an example would help. I'm writing an Electronic Court Filing Application. I have a presenter that lists a bunch of filings, each filing has three links 1) clicking or the ID of the filing takes you to view/edit for that filing 2) clicking the case info takes you to details for that case 3) clicking on the lead document name downloads that document. The contacts example has a similar situation, in which the presenter captures click events for the whole table, queries the display to find out which row was clicked, looks up in the row number in a list of Contacts stored in the presenter, and takes action. This even seems a little kludgy in the simple example (again I'd be excited to know why I'm wrong about this). Wouldn't it be more robust and straight forward for a CaseLinkClickedEvent(Integer caseId) to just get fired by a link that already knows that it is styled like a CaseLink and has the text of filing.getCaseId()? Also there are two main types of filings: those that initiate a new case and those that are adding to an existing case. They are different enough to have their own view/edit presenter class, but they also share a lot in common. I would like to have each of these two mid-level presenters contain a list of subclasses of FilingStepPresenter, but have run into a number of obstacles to doing this in practice. Thanks, Eric On Feb 15, 2:06 pm, Yaakov Chaikin <[email protected]> wrote: > On Mon, Feb 15, 2010 at 11:01 AM, Nathan Wells <[email protected]> wrote: > > The main reason (for me) for removing and dependencies on the model > > from the view is that as you add dependencies, you will also add > > state. > > You will then be managing your application state in your view, > > which is (1) something you would want to use JUnit for, and (2) a > > major reason for the presentation layer in the first place. > > Well, that's not really true or at least it certainly doesn't have to > be. Your display.setContacts(List<Contact) method doesn't have to > *store* the list (and therefore introduce state into your view). It > can just do the same thing that setData(List<String>) does (in the MVP > Contacts example). I.e., it can remove all entries from the table and > iterate through the Contact list, populating the table with contact > values, throwing the List<Contact> away after it's done. > > Yaakov. -- 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.
