Re: Structure of code with multiple ActivityManagers

I looked for hints on StackOverflow (http://stackoverflow.com/search?q=gwt+multiple+activitymanagers) and there are several questions regarding the same theme 

• http://stackoverflow.com/questions/13326657/whats-the-use-of-multiple-gwt-activitymanagers-and-activitymappers
• http://stackoverflow.com/questions/5879640/gwt-mvp-maintaining-multiple-displays-that-are-separate-of-one-another
• http://stackoverflow.com/questions/13014580/gwt-using-activies-and-places-when-screen-layout-changes-per-place
• http://stackoverflow.com/questions/13103795/gwt-granularity-of-places-and-activitymappers

It looks like I am on the right track however wondering is there anyone else except Thomas Broyer who can answer this question :)

вторник, 9 сентября 2014 г., 0:18:30 UTC+7 пользователь Petr Gladkikh написал:

Hello,

We have a GWT project whose UI requires showing several mostly independent parts. It is desirable to allow restoring state of these parts from URL, and show/hide them independently. It looks like approach from GWTP fits our requirements but we already have working code and not enough resources to rewrite it. So I decided it would be reasonable to organize existing code. 

To implement those independent fragments of UI we already use, although inconsistently, approach similar to one described in http://blog.ltgt.net/gwt-21-activities-nesting-yagni/ where each UI fragment has own ActivityManager and listener for PlaceChangeEvents that changes layout depending on current Place. 

We also have place change listeners that update some parts of UI which I believe is rather unclear implementation.

Also in one place we have type/category/sub-category tabs. For which hierarchical presenters are natural fit and we are using hierarchical Activity classes although start/stop on them is called explicitly (not from Activity manager). This part feels awkward since activity framework is not actually used.

I would like to refactor Places handling as follows:

1. Parse/store place as set of independent sub-places. Any activity mapper should look at this collection and, if sub-place matching current fragment is found, restores activity based on that sub-place. In other words I plan to make place structured so different UI fragments would only process relevant parts of it.

2. Use ActivityMapper's to pass all necessary parameters from place to activity and remove history listeners from other places in UI code.

3. Have own hierarchical presenters (not necessary Activities) for type/category/sub-category tabs since GWT activity framework does not seem help in this case.

So is this plan reasonable? Are there better (simpler or more natural to GWT) approaches to organize code in such situation? 

Hierarchical Activities, is it a bad idea? Is there support for parameters in place objects and is it OK for them to have internal structure?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.