GWT MVP Activities and Places

[metalhammer29a]

I am using GWT 2.1 MVP in my project.

I have identified 4 display regions (North, West, East, Center),
each managed by a corresponding Activity Manager.

Each display region also has a corresponding ActivityMapper that maps
a place to the appropriate activity.
when I don't need a region, I just return null in the Activity Mapper
for that region, and the display region is removed, as expected.

However, in some cases where I have for example West, Center and East
display regions,
when navigating to a new place, I want to West and East display
regions (activities) to remain as they are,
and only the Center display region get updated with new data as a
result of navigating to a new place.

What currently happens is that West and East regions are called as
well, resulting in unnecessary calls to fetch data. I want to avoid
this.

For example I would want the List of Items in the West region, to
remain as they are, and selection of an item, triggers navigation to a
new place, causing Center Region to display details of the selected
item.
with my current implementation, in addition to Center Region, West
Region is also refreshed, causing the List of Items get loaded,
despite the data being the same.


Could you please provide some pointers on how I can update "only one"
display region upon navigation, while keeping other display regions as
they are ?

[Brian Reilly]

I haven't done this in a real project yet, but I was experimenting with something similar. I think I was able to get this kind of behavior by wrapping the ActivityMapper implementation in a CachingActivityMapper and wrapping that in a FilteredActivityMapper. The idea is that the filtered activity mapper recognizes some places (like detail views) and changes them into whatever place invokes your list activity. Then, the caching activity mapper, having already seen an equivalent place, doesn't invoke the wrapped activity mapper since the display region is already showing that place.

It seems rather roundabout to me, so I don't know if this is the best way to do it, or if this is exactly what Caching/FilteredActivityMapper are for (the documentation is pretty light there). I'd appreciate if others could chime in with agreement or other options.

-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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Ashton Thomas]

Depending on how your app is structured you can implement a Place
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....

and you main content area updates with each new place while the others
only respond to the Types (instanceof)

You probably already know this but this is how I would solve it if the
app is organized in a particular way

On Dec 1, 3:36 pm, Brian Reilly <br...@ireilly.com> wrote:
> I haven't done this in a real project yet, but I was experimenting with
> something similar. I think I was able to get this kind of behavior by
> wrapping the ActivityMapper implementation in a CachingActivityMapper and
> wrapping that in a FilteredActivityMapper. The idea is that the filtered
> activity mapper recognizes some places (like detail views) and changes them
> into whatever place invokes your list activity. Then, the caching activity
> mapper, having already seen an equivalent place, doesn't invoke the wrapped
> activity mapper since the display region is already showing that place.
>
> It seems rather roundabout to me, so I don't know if this is the best way to
> do it, or if this is exactly what Caching/FilteredActivityMapper are for
> (the documentation is pretty light there). I'd appreciate if others could
> chime in with agreement or other options.
>
> -Brian
>

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .

[metalhammer29a]

Ashton,

if you have a List of items in the West Region,
and are going to display the details of each item in Center Region
(upon selection from the list in west region),

do you think we are going to need One Place or Two Places ?
how about Activities ? One Activity or Two Activities ?

I think we need One Place:for example CatalogPlace,
and then map this CatalogPlace to Two Activities

ItemListActivity

and

ItemDetailsActivity

ItemListActivity and ItemDetailsActivity are managed by two different
ActivityManagers.

we can use WestRegionActivityMapper to map CatalogPlace to
ItemListActivity
and use CenterRegionActivityMapper to map CatalogPlace also to the
ItemDestailsActivity

however, with every selection from the itemList (in the west), as we
navigate to a new place (to display the details in the center region),
the ItemListActivity is again called by its ActivityMapper, resulting
in data from the list being reloaded.


I am also thinking we need to use CachedActivityMapper/
FilteredActivityMapper as Brian mentioned.
but i am not sure.

regardless, what do you think is the best approach in implementing the
use case described above with GWT MVP 2.1 Activities and Places ?

[metalhammer29a]

>>Depending on how your app is structured you can implement a Place
>>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 ?

[Ashton Thomas]

I am not too sure of the final goal but I have two sample projects
that do something similar using places with parent class (sub-class
defines main content activity, and parent class defines a different
area that does not update every time)

Both activity mappers are wrapped in a cacheActivityMapper

https://github.com/ashtonthomas/gwt-seminar
https://github.com/ashtonthomas/beans

Not sure if this will help you or not

[Thomas Broyer]

On 1 déc, 21:36, Brian Reilly <br...@ireilly.com> wrote:
> I haven't done this in a real project yet, but I was experimenting with
> something similar. I think I was able to get this kind of behavior by
> wrapping the ActivityMapper implementation in a CachingActivityMapper and
> wrapping that in a FilteredActivityMapper. The idea is that the filtered
> activity mapper recognizes some places (like detail views) and changes them
> into whatever place invokes your list activity. Then, the caching activity
> mapper, having already seen an equivalent place, doesn't invoke the wrapped
> activity mapper since the display region is already showing that place.
>
> It seems rather roundabout to me, so I don't know if this is the best way to
> do it, or if this is exactly what Caching/FilteredActivityMapper are for
> (the documentation is pretty light there). I'd appreciate if others could
> chime in with agreement or other options.

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).

Of course you could do the exact same thing right into your
ActivityMapper (the need here is to return the same Activity instance,
so te ActivityManager will detect it and won't do the stop/start
dance); you'd however loose a bit of "separation of concerns".

[metalhammer29a]

>>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).

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.

what happens if we use CachingActivityMapper for ALL of our
ActivityMappers ?
would there be a performance problem, what are the implications,
benefits or drawbacks ?

[Brian Reilly]

>>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

[Frank Bølviken]

Is there any existing sample-projects which use this structure, with
DI(gin/guice) ?

> if we see the same place twice" (http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...).