>>hierarchy.
>>AppPlace or just Place
>>Type1Place extends AppPlace (or Place)
>>Type2Place extends AppPlace (or Place)
>>Type3Place extends AppPlace (or Place)
>>HomePlace extends Type1Place
>>ContactUsPlace extends Type2Place etc....
I believe it should be the other way around.
instead of organizing by "Place" types, we have to organize by
"Activity" types.
"one place" can be mapped to "many" different Activities.
(upon navigating to "a" new place, you can start activities in
different regions: eg. west and center )
therefore we would have:
abstract class ApplicationActivities implements ActivityMapper
class ApplicationWestRegionActivities extends ApplicationActivities
class ApplicationCenterRegionActivities extends ApplicationActivities
// and the same for North and East Regions
and in these xxxxRegionActivities we override getActivity() method to
return the Activity that matches the currently passed in place, or
null to hide the region.
however, in most cases we require two regions to be visible, and as
user interacts with one region, the other get updated (as a result of
navigation).
using the approach I described, both regions fetch the data, while in
fact only one should do it.
as a general question,
is it better to organize/split the application by Places, or by
Activities ?
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment