Activity & Places - Remove & Add of a widget for every new activity - Why?

[Alfredo Quiroga-Villamil]

Hello All:

I had a quick question regarding the implementation of Activity & Places.

During the implementation of A&P, specifically when working with the activity, one overrides a method:

public void start(AcceptsOneWidget panel, EventBus eventBus) {

As seen above, the interface indicates that the container panel only takes on widget or child. The consequence of this is that every time a new activity is called, the child of the container panel is removed, the widget to be added is also removed from any potential parent and then added to the container panel.

Assuming I interpreted the code that handles this correctly, my question is: Why the decision of adding/removing Vs having a Container Panel with a Card Layout that takes widgets activating them when needed. In this case it could be done in the activity start area.

I have tried to look around to see if somebody else asked this before and I might even be missing the obvious, but I am particularly interested in the rational behind the add/remove vs card layout approach here. I am thinking it might be related to saving resources perhaps by having less elements added to the DOM, but one would think there is a penalty also to pay when adding/removing these views whenever a new place in the application is reached.

Appreciate in advance any explanations/clarifications regarding this.

Thanks,

Alfredo

--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

[Thomas Broyer]

I don't think adding/removing is any more costly than showing/hiding, but even then, you could make it work that way (show/hide) by simply providing a DeckLayoutPanel (or an AcceptsOneWidget wrarpper around a DeckPanel). The problem with such an approach is when your activities don't reuse their views, you'd absolutely need a way to clean-up the "widget cache".

[Alfredo Quiroga-Villamil]

Tx, appreciate the response.

Alfredo

On Sun, Feb 5, 2012 at 11:19 AM, Thomas Broyer <t.br...@gmail.com> wrote:

I don't think adding/removing is any more costly than showing/hiding, but even then, you could make it work that way (show/hide) by simply providing a DeckLayoutPanel (or an AcceptsOneWidget wrarpper around a DeckPanel). The problem with such an approach is when your activities don't reuse their views, you'd absolutely need a way to clean-up the "widget cache".

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/bvTvUgq93fAJ.
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.