So, I thought we talked a while ago about replacing the old way that I
handled this with the new way (ext- there's a config option for that).
http://github.com/sbenthall/geonode/commit/c8e4c0251e291e08194be2afe479ac09a2427f4d
What's wrong with this approach?
--
David Winslow
OpenGeo - http://opengeo.org/
On 07/20/2010 06:06 PM, Sebastian Benthall wrote:
This commit moves the header and the top bar out of the Ext app and
into the template:
http://bit.ly/94kqBo
Unfortunately, it raises a problem. Before, we loaded the Ext
application into the Viewport, which fills the whole browser window.
With this change, GeoExplorer renders to a panel in the DOM.
The problem is: how do we set the height of the GeoExplorer app so
that it fills the space between the header wrapper and the bottom of
the window?
Related Stack Overflow question:
http://stackoverflow.com/questions/90178/make-a-div-fill-the-remaining-screen-space
I was going to throw up my hands and try to implement a heavy JS-based
solution, calculating the necessary offsets and listening for the
browser's onresize event, but I'm hoping that I'm missing a cleaner,
Ext-based way of doing it.
Any thoughts?
On Thu, Jul 15, 2010 at 2:41 PM, Sebastian Benthall <[email protected]
<mailto:[email protected]>> wrote:
This doesn't seem too objectionable to me. I wonder, though,
whether it makes sense to start making changes to accommodate
theming now when we will be getting some consulting time with
a CSS guru next week.
I have the CSS guru in mind. However, my concern is that Chris is
a CSS and markup guru, not a JavaScript developer. So I was
seeing one good side-effect of this change that the markup for
this stuff would be in the templates rather than embedded in the
rather heavy GeoExplorer.js file.
In other words, I think it makes sense to make changes that
will accommodate the theming guru before he starts working so that
he can work as efficiently as possible.
btw, one objection I had when I set up the original header was
that the header was visible before the map loaded. If I am
reading your proposal below correctly, then you'll need to do
something explicit to hide the header until the application
lays itself out.
Ok, good to know. I think that will be possible by listening for
the map application's 'ready' event and triggering visibility when
it fires, or something like that.
On 07/15/2010 02:18 PM, Sebastian Benthall wrote:
Andreas and I have been discussing the way to set up the
layout on fullscreen GeoExt applications over here:
http://github.com/sbenthall/geonode/commit/8b776956579ad7daf03a7af9089d6554439954c9#L0R848
The issue is that according to the new design spec for the
Map Composer, there is an additional DOM element (containing
the map's title and a link to the map info page) that should
be themed according to the site theme (not the Ext theme) and
wedged in between the site header and the map composer's
toolbar. (See attached wireframe) The content here needs to
change in response to GeoExplorer events, particularly when
the map is saved (so the Title can be updated).
In his review, Andreas recommended that since this stuff has
the web application feel, it should be removed from
GeoExplorer.js and moved into the template, and then use the
gxp.Viewer's renderTo config property to get the application
into the right place (as opposed to trying to lay out those
elements in Ext). I agree that it makes much more sense to
do it this way.
In order to do this, we also need to move the site header
(i.e., the thing that currently says "CAPRA Geo Node") out of
the GeoExplorer.js script (where it is pulled in as an
element). I think this is a good thing because it means we
get the functionality of the site-wide header (login-links,
etc.) back into the Map Composer page, which we will probably
want.
I don't know yet whether the new theme will will include tabs
in the fullscreen application view--it seems ambiguous in the
wireframe because the tabs are embedded in the header. The
sneak previews of the new theme from Rollie that I've seen do
not have this kind of embedding.
I'm going to go ahead and implement all this unless there are
any objections.
--
Sebastian Benthall
OpenGeo - http://opengeo.org
--
Sebastian Benthall
OpenGeo - http://opengeo.org
--
Sebastian Benthall
OpenGeo - http://opengeo.org
