I think this looks like a huge improvement over the tree structure.

The only question I had from the mockup was about the links on each  
row of the result table:

http://skitch.com/dimmerswitch/bfa45/layerlist

It's not immediately clear (from looking) where those links would take  
me. Would adding "[Edit]" buttons or text potentially clarify where  
each of those might point?

Chris

On Feb 19, 2009, at 10:25 AM, Andrea Aime wrote:

> 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.
> <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

Reply via email to