Is there any existing sample-projects which use this structure, with DI(gin/guice) ?
On 3 Des 2010, 14:08, Brian Reilly <brian.irei...@gmail.com> wrote: > > >>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/g...). > 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 google-web-tool...@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.
