[ROO-1309] Creating ActivityManager "on-demand" is impractical Created: 29/Aug/10  Updated: 23/Oct/10  Resolved: 30/Aug/10

Status: Closed
Project: Spring Roo
Component/s: GWT
Affects Version/s: 1.1.0.M3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Thomas Broyer Assignee: Chris Ramsdale
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


In complex applications, you'll quite often (I guess) have a need for nested ActivityManagers: an Activity starts an ActivityManager to handle child activities in nested "display" regions.
While it's easy to create an ActivityManager and have it react to later place change/change-request events, it's impractical to initialize it with the child-activity corresponding to the current place: because the ActivityManager is created in response to a PlaceChangeEvent, it won't receive the event itself. The only solution seems to be to fake a PlaceChangeEvent, taking advantage of ActivityManager directly implementing PlaceChangeEvent.Handler and directly calling its onPlaceChange method:

ActivityManager subActivities = new ActivityManager(mapper, eventBus);
subActivities.onPlaceChange(new PlaceChangeEvent(placeController.getWhere());

Comment by Ray Ryan [ 30/Aug/10 ]

I don't think it's a given that we need this kind of composition. Closing this until we get a more concrete use case.

Comment by Thomas Broyer [ 31/Aug/10 ]

After some more thinking during the week end (drafting my new blogpost about activities ), I tend to agree (though GWTP users and maintainers might not agree, let's wait for their concrete use cases).
But then I don't see a reason for starting/stopping an ActivityManager either... (see https://jira.springsource.org/browse/ROO-1310 which could then be fixed by having the Display passed as a constructor argument)

FYI, we found this when exploring different ways of solving a given use case (contextual activities, see point #5 in http://groups.google.fr/group/google-web-toolkit-contributors/browse_thread/thread/c47e97bdfb904928, where we have some kind of "hierarchy" between these sub-activities –what I called breadcrumb overview–) and trying to take advantage of the fact activity managers can be started/stopped dynamically; but we finally went for something simpler (have different activities –to reuse the MSOffice 2007 image, have one activity for the "basic ribbon", a different one for the "ribbon with table-related tabs", another for the "ribbon with image-related tabs", and if needed an activity for the "ribbon with both the table-related and image-related tabs"– instead of trying to nest them dynamically; our activities are different instances, but share some code through composition and inheritance, both at the presenter and view level).

Generated at Wed Jul 17 15:00:57 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.