On Thu, 2009-02-19 at 17:25 +0100, 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
This sounds dicey; I am a bit concerned by the idea of a selection model
that survives page loads, if only because that's not how things usually
work in my experience. I'd like to bring this up with the design team
as well.
> - a remove link, that should pop up a dialog asking
> delete confirmation, with a list of the
> actual selection contents
If we allow global selection this list may be quite large. I suppose
some sort of summarization could be done (perhaps just listing
namespaces and the number of layers from each or so) to avoid the sorts
of issues that the paged list is supposed to fix in the first place.
Perhaps we can ignore this for now and revisit when we've made some more
final-ish decisions about the store list.
> - 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 :)
it took me a minute or two to parse this out and I'm still not sure I
got it right. I think what you are saying is that we need two more
page-able lists, one of workspaces and one of stores, and that you see
two options for how to present the three lists (layers, workspaces,
stores) to the user:
* as tabs in one giant "Resources" page, or
* as separate pages linked from the navigation sidebar
and that you prefer the latter. I would tend to agree with that. Having
a "Resources" link in the "Data" section of the sidebar seems pretty
confusing to me.
I also have a couple of observations:
* There is an SRS field in the layer table. Is this appropriate
information for the layer list? It seems like a configuration detail
that is not likely to be useful for {sorting,searching} to me.
* Should the 'enabled' field be editable? Actually, come to think of
it, the 'enabled' attribute may need some revisiting in the light of the
new multiple map concept. If I disable a layer, but it has been added
to a map, does it show up in that map? What if it is used in several
maps? Maybe we should scrap the 'enabled' attribute and leave its role
to be played by security permissions. Or maybe 'enabled' should be an
attribute of published layers and not the data itself.
--
David Winslow
OpenGeo - http://opengeo.org/
------------------------------------------------------------------------------
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
