Hi, so I've been working a little on a more scalable component for presenting the catalog contents.
First thing I noticed while working on it is that during the GeoServer IRC meeting, I forgot about workspaces and stores, which are the first two levels in the data tree. Workspaces do not really have a scalability issue, in most cases they will be only a handful... always less than 100 I guess, unless we move to a model in which one GeoServer instance is used to power an ASP that gives one/more workspace per user, and there is some uber-admin that can see them all. Stores should not be that many either. On the vector side the directory data store should cure the proliferation of shapefile data stores, on the coverage side, we can still have a ton, so until we fix that, a server with lots of coverages can still have a lot of stores. Layers wise, we already know, there can be many, many and ... many! Ok so attached here a first proposal of how the layer page could work: - a keyword based filter to get only the elements one is interested into listed - a table of layers, with links, lots of them. Each link points to an editing page, so from this one we can not only inspect layers, but also workspaces and stores - checkboxes for a global, full list, not per page, selection model - a remove link, that should pop up a dialog asking delete confirmation, with a list of the actual selection contents - a drop down with datastores, you chosee one, you get into a dialog/page that lists all the layers that are still un-configured for that store. If we don't any, we can just pop up a warning, if just one, go straight to the configuration of the layer, if many, have the user choose (for the moment, just one, later, choose a set and leverage some auto-config) - the headers should be clickable to get a globally sorted list (on a single column). Still have to implement this. It's pretty minimalistic, but should work. What about stores and worksapces? Well, I was considering using the same approach, in two separate pages, it's simple enough, and uniformity is a good thing. So for workspaces a very simple table, a link to remove the selected ws, and one to add a new one. In case of removal, show which datastores and layers will be removed, if confirmed, cascade delete. For stores, same deal. It's not as compact as the data tree, but scales up well, and seems pretty simple to use (and a lot easier to implement). Thoughts? Cheers Andrea PS: menu wise you see "resources" which is the old data tree, and layers, which is the page you're looking at. For workspaces and stores we could do something similar, that is, add two more menu items. Alternatively, we can decide to have a single "resources" page and have three tabs on top of it to switch between ws, stores and layers. Imho it would start to be too much nesting, but I'm happy to be convinced otherwise :) -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers.
<<inline: layerList.png>>
------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
