On Jul 21, 2010, at 23:37 , Sebastian Benthall wrote: > Cool. > > Only remaining question is: where should the behavior for those fields be > set, in the template or in the GeoExplorer.js file?
I would not refer to this as "fullscreen application" any more. It is just a map viewer where the map takes more space than on the other pages. If "those fields" means everything that is positioned around the map viewer, then read on. > > I could see arguments for either (it's nice to have all the JS in one place / > it's nice to keep non-Viewer related code separate and the necessary public > events are exposed) but am in fact completely apathetic about it myself and > just want the feature done. I'd say the one thing we should not do is say that just because it's javascript, it should all go in the same place. The map viewer is surrounded by Django templated layout and content. Behavior of these surroundings should be handled there. So I'd favor an approach where javascript code that adds behavior to layout and content generated by Django goes in the Django template. My 2ยข Andreas. > > Anyone with an opinion or should I just shoot? > > On Wed, Jul 21, 2010 at 5:29 AM, Andreas Hocevar <[email protected]> wrote: > Hi Seb, > > right, I forgot about this benefit of Ext.Viewport. But David is right: by > just changing the portalConfig and using the technique David linked from your > commit, you can both move the header to the template and take advantage of > Ext.ViewPort. > > -Andreas. > > On Jul 21, 2010, at 00:14 , David Winslow wrote: > > > 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]> > >> 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 > >> > > > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > > > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
