David Winslow wrote:
> 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.
The are not actually "page loads" as the things flips page with AJAX,
but yeah, I get the point, the user is actually not seeing the current
selection fully, so the results of a delete might be confusing.
That's why I added a confirmation box for the delete with a list of
the resources that are going to be deleted.
Having a per page selection is doable, but harder (the selection
state is kept on the server, not in the page).
It also makes the use case of willing to delete layers that match
a certain filter awkard, as you have to delete one page, realize
there is another one, delete that, and so on.
> 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.
Yep, you got that right, and yes, I would like to have a total of three
pages to handle resources, one for workspaces, one for stores, and one
for layers.
>
> 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.
It depends. SRS is kind of a cornerstone of geographic data, you don't
have that, you're not doing GIS. If you're in the simple case and all
your data are in the same SRS, then yes, it's obviously not useful.
If on the other side you have data in different projections, it's
actually a quite effective way to get all the data in a particular
projection. For example, in Italy we have 4 main based on transverse
mercator plus a cadastral one plus the wgs84. Each municipality I've
seen in Italy has data in at least 3 of them, and conversions between
one and the other are not trivial. So that can become a very effective
filter (what data is based on the cadastral system?), especially when
combined with some other filter.
> * 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.
Enabled is not a user editable element at the moment, it's a reflection
of an inner state of your data. Enabled is true if data loading went
fine, it's false if the datastore could not be connected, or the feature
type could not be found in the datastore (as tables can be deleted on
your back).
From an admin point of view spotting quickly which layers are not
enabled is important, as it tells you that something is not working
as expected, and that you should take corrective actions (we should
actually reinstate the green/gray/red bars in the config as that
gives you a quick summary on the condition of the catalog,
then you can drill down and find what's not working).
Cheers
Andrea
------------------------------------------------------------------------------
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
