Hi...
El 29/11/11 17:50, Thomas Broyer escribió:
I haven't looked at the code yet (not easy to read code on mobile) but I wonder
how you manage the case where an activity can be used totally distinct places?
In our project for instance, we show the same activity for an IllustrationPlace
and a LegendPlace (a legend being the use of an illustration within a file): we
show the information about the illustration in both cases.
The way things are wired up right now, there are a couple options:
1) Set the activity's generic Place parameter to a common ancestor of
the places where it'll appear.
This could be the abstract class WebClientPlace, which is the ancestor
of all places used in the framework, or it could be some other common
ancestor lower down on the class hierarchy. In this case your activity
could look like this:
public class SomeCommonActivityImpl
extends WebClientActivityBase<
SomeCommonView,
AncestorOfPlacesWhereThisActivityIsUsed,
SomeComponentProvidingCommonFunctionality>
implements SomeCommonActivity {
[...]
}
Then, in the components that set up activity/view/ui-region bindings for
the specific places where you want to use this activity, you'd just
inject in an appropriate activity factory and bind it to a ui region,
just like you'd do for any other activity. So you could have any number
of components more or less like this:
public class SpecificPAVComponentImpl extends PlaceActivityViewComponentBase<
SpecificPAVComponent,
SpecificPlace>
implements
SpecificPAVComponent {
@Inject
public SpecificPAVComponentImpl(
SpecificPlaceProvider specificPlaceProvider,
ActivitiesFactory<AncestorOfPlacesWhereThisActivityIsUsed,
SomeCommonActivity>
someCommonActivitiesFactory,
[...]
) {
super([...]);
addRegionAndActivitiesFactory(SomeUIRegion.class,
someCommonActivitiesFactory);
[...]
}
}
Note that I haven't tried this yet, though I did think of this
possibility, and in theory it would work.
Note also that if you do it this way, the return type of the getPlace()
method available in your activity would be
AncestorOfPlacesWhereThisActivityIsUsed. For cases where you want to
deal with your place instance as something more specific, see option
(2), below.
(Problems will arise if one needs to do this really a lot, and in many
different ways, to the degree that the single-inheritance class
hierarchy of Places becomes insufficient to express relevant
commonalities and differences between places. Still, I'm sure the
framework could be adapted to accommodate this---for example, rather
than inheriting a common abstract Place class that inherits back to
GWT's Place class, places could implement a common Place interface.)
2) Create an abstract class that provides the common functionality you
need, and make specific activities that inherit it.
This does work in the framework as it stands, and it's what I'm using
for common functionality in the banner region of our app. So I have a
StandardBannerActivityBase class that can be inherited by other activities.
Many thanks again for your comments, suggestions, etc.!
- Andrew
--
You received this message because you are subscribed to the Google Groups "Google
Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.