Andrea Aime wrote: > Justin Deoliveira ha scritto: > >> First off I want to say that its looking great, some great work was done >> while I was away. However there are a few things i noticed today while >> hooking up persistence. I am curious as to other peoples thoughts. >> >> * use of word "Manager" >> >> It seems redundant. I mean... we could call everything a "manager" that >> is used to configure. What was wrong with "Resources", "Namespaces", and >> "Styles" in the menu? >> > > I don't mind the names either way. > > I am in agreement with Justin on this. >> * feedback under page heading >> >> Feedback messages appear above the page heading and description. I think >> it might be a bit nicer if it apperd below the heading, and above the >> rest of the page content. Or maybe on the right hand side of the page so >> that none of the main content on the page shifts up and down. >> > > jdeolive++ > It's easy to move too, just change its location in the main page. > > I don't think we should put the feedback messages in the sidebar, they are a 'local' thing and sidebar stuff is 'global.' Above or below the title doesn't feel like it makes a big difference to me though. (Maybe we could move page titles into the page header?) >> * use of icons vs buttons >> >> On the resources page, we have icons for add,edit,delete, but on the >> namespaces and style pages we have buttons with words on them. I am >> wondering if we could make these consistent, or if there is an explicit >> reason. I suspect maybe because of the limited real estate in the >> resource tree? >> > > I think it was just because icons looked nicer, but buttons with text > you understand at a glance. One problem with buttons is that they use > lots of vertical space, that I perceive as a problem. > It shouldn't be a problem to reduce the padding on the buttons or just make them simple (borderless) links. Best of both worlds? > >> * line between data and publishing seems blurred >> >> If you look at the ResourceConfigurationPage, the data tab seems to have >> content that i would think belongs on the publishing side of the fence. >> Things like title,keywords,abstract, and published bounding box all >> belong on the layer that is published, not the native resource. I cant >> remember if we came up with this at the sprint, i apologize for being >> out of the loop for so long. >> > > I don't remember exactly me neither. I kind of remember something along > these lines: provide some basic publishing infos in the resource as > well, and have them play the role of the default for the layers, and > also be _the_ values for the "default" map, the one that you don't have > to manually configure and that shows everything by default (to avoid > adding extra steps that weren't there in the old interface, for the > simple case where just one map is sufficient). > > Having title/keywords/abstract in a separate section is ok to me, > I'm a little disturbed by the idea of having the wgs84 bbox away > from the native one, since they do pretty much depend on each other. > The ResourceConfigurationPage is divided up based on where settings are stored in the catalog API. Everything that comes from a ResourceInfo is on the Data side, everything that comes from a LayerInfo is on the publishing side.
The Publishing tab on a ResourceConfigurationPage should contain all the default settings for Layers based on that resource. -David Winslow ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
