In my opionion if you release a functionality and tell people "it's better if you use it", you have to be aware of impacts this new functionality can have on existing code.
In my opinion use of DockLayout or TabLayout / Panes is not a rare use case, think about a mail reader.
MVP approach is very good, and I think that GWT team did a great job about it, but, given implementation does not consider complex web gui.
What I find inacceptable is documentation, the last paragraph, where GWT team says:
"What about apps with multiple panels in the same window whose state should all be saved together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite Place; however, your app could create a CompositePlace, CompositeActivity, and CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the composite objects would need to be registered with your app's ActivityMapper and PlaceHistoryMapper."
In my opinion if you speak about CompositePlace you should describe what you are talking about, too easy to say "yes, you could create a CompositeActivity, but do it by your own"
Anyway, I repeat, GWTeam did a great work about MVP and it's very useful having directly inside GWT an pattern implementation for organizing classes about guis, but in my opionion there are a lot of complex gui that difficultly can be migrated to this approach with actual solution
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to email@example.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.