> > >>That's the exact use case for FilteredActivityMapper and > >>CachingActivityMapper (and how they're used AFAICT in "scaffold" > >>applications generated by String Roo for the "master" activities). >
Thanks for the confirmation, Thomas. I felt like it was a bit cumbersome to use, but it makes more sense as a consistent way to get that behavior in generated code (which is unfortunate, but it is what it is). > what about situations where a display region is master in some cases > (requiring to be cached), and > detail in other cases ? > > for example, when we have West, Center, and East Regions, > Center region can act as Detail for West Region in some use cases, > but in other use cases, be used as Master for East Region. > I can think of two approaches, depending on the specificity of the places. 1. Use an activity mapper for the center region but not the east region. This would be appropriate if the center region shows the item of interest and the east region contains some contextual detail that isn't worthy of being encoded into a place. 2. Have both the center and east regions react to the same place where, unlike option 1, the place contains enough context for both regions. The east region would use that extra detail to display something specific about the item of interest while the center region can ignore it if it doesn't affect what's displayed. I'm sure there are more ways to approach it. Just keep in mind that activity mappers are for mapping places to activities. Once you decide how granular you want your places to be, that will help determine the best use of activity mappers. > what happens if we use CachingActivityMapper for ALL of our > ActivityMappers ? > would there be a performance problem, what are the implications, > benefits or drawbacks ? CachingActivityMapper "caches the last activity it returned, to be re-used if we see the same place twice" ( http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/activity/shared/CachingActivityMapper.html). If your concern is memory, there should be little to no overhead when using a CachingActivityMapper. As for performance, the goal of CachingActivityMapper is to avoid initializing a new activity (and potentially fetching data from the server, doing client-side processing, etc.) when the current activity already represents the requested place. I can't think of any downside to using CachingActivityMapper... as long as the wrapped activity mapper and the places it uses are implemented as advised (be sure to properly implement equals() and hashCode() for your places). -Brian -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
