MapPanel should listen for ownerCt move

Drag the window in the mappanel-window.html example to see this issue in action. After dragging the map jumps on the first drag pan. Apply this patch to see better behavior.

update map size when owner container moves

Replying to tschaub:

Drag the window in the mappanel-window.html example to see this issue in action. After dragging the map jumps on the first drag pan. Apply this patch to see better behavior.

Tim, I don't understand what the issue is. Could you give the exact steps to reproduce the problem? Thanks.

Replying to elemoine:

Replying to tschaub:

Drag the window in the mappanel-window.html example to see this issue in action. After dragging the map jumps on the first drag pan. Apply this patch to see better behavior.

Tim, I don't understand what the issue is. Could you give the exact steps to reproduce the problem? Thanks.

Sure. Here's what I do:

1) browse to trunk/geoext/examples/mappanel-window.html 2) drag-pan map (not window) to confirm map dragging behaves as it should 3) drag window containing map panel (this ghosts the panel, moves it, then unghosts it) 4) drag-pan map (not window) to see map quickly jump before panning normally

The map is still using cached offsets after the move.

Hey Tim, looking at your patch I have one question: when should we use destroy and when should we use onDestroy instead? I would tend to use onDestroy in this case but I can't really provide a clear distinction when to use which one.

Yeah, I wondered the same thing. I decided to use destroy based on thinking like this:

1. destroy is documented as part of the API, onDestroy is not - of course we wouldn't be overriding "constructor" and a whole lot of other stuff if we were strict about this, but it seems like a good thing to consider first.

2. I generally like the idea of having constructor call constructor on the super first (or very early in the constructor function) and having destroy call destroy on the super last (or very late in the destroy function). The onDestroy method gets called somewhere in the middle. It is not important here, but it seems like it could cause trouble elsewhere.

That said, it seems like onRender, onDestroy, etc are the accepted ways of extending in ExtJS. I'd be happy adopting either convention. And we could also wait until we have enough of this code to settle on a pattern.

I was looking at TreePanel, GridPanel and Window (all extending Ext.Panel) and they all use onDestroy. Also this post [1] by somebody from the Ext development team seems to suggest that things extending Component use onDestroy, and other objects destroy. At least that's what I can make of it all.

[1] http://extjs.com/forum/showthread.php?p=298178#post298178

Therefore, I would be in favour of using onDestroy.

Replying to bartvde:

[1] http://extjs.com/forum/showthread.php?p=298178#post298178 Therefore, I would be in favour of using onDestroy.

Interesting. My read of that thread is that it is a caution *against* using onDestroy - though not explicitly. It demonstrates how moving onDestroy around in a parent can wreak havoc on children. And we don't control the position of onDestroy. At least if we override destroy, we control the order.

That said, I am ok going either way. And I also see that onDestroy is used where others extend.

update map size when owner container moves (version 2)

Ok, a patch for every preference. I'm happy to commit either. And, I don't think we need to labor the point right now. We can easily change from destroy to onDestroy (or the other way) at any point without harming our users.

Tim, looks good to me, please commit.

I'm also +1 on using onDestroy, thanks Tim for the patch and taking the time to explain the problem to me.

(In [283]) If a map panel is rendered inside of a parent container, it will listen for move events on the parent. This allows us to clear the map's cached offsets. r=bartvde (closes #32)