Re: Request for comments on a custom framework

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