Ok, I meant to send some of these earlier, but they are all quite minor
little things we need fixed up. I don't need most of them for the beta.
And some may have been fixed in the past few days, so don't yell at me if
you already took care of it 
And if there are just random things that
are part of my install just let me know, I haven't dug into the code
completely. If you know that it's something to be done and it's yours
then make a task in jira and assign to yourself. If not we can meet on
irc tomorrow and task them out.
UI -
MaxFeatures should not default at 2147483647. That looks weird, and means
nothing to most people. It should just be unbounded, or blank. Perhaps
if that number is the one (it's the max for an integer, which is how we
store the max features), then it should just not show up.
The schemaBaseUrl default is really weird. It should default to a web
address - the default of none will use geoserver's schemas, located at
http://localhost/data/capabilities/… So the default should maybe say
something like 'local'. Then people can put in http://schemas.opengis.net
for example.
BaseUrl should be gone, as we don't have users set it any more (I want
this for beta)
Apply should be renamed to 'test it'? Was that what we decided? I find
the apply word a bit weird, when compared to save. I'm not sure what does
what. This is just a reminder to change it.
The style page should also allow a user to write sld directly and save
that in the styles directory. Then if someone knows sld they don't have
to figure out where to put it, and how to reference it, they can just go
through the ui interface and write it out directly. Eventually it'd be
dope if we had some interactive style builder going, where you could
selecct the various style params that you wanted, and even preview how it
looks. Ah to dream. But at the least I think a box to input a style when
you hit new would be nice. And a bit nicer would be if edit displayed the
style in a box that you could change around.
(warning anal coding request (sorry))
I don't understand why Request has getWMS() and getWFS(), while WMSRequest
and WFSRequest each have their own getGeoServer methods. Seems to me like
getGeoServer should be in request and each of getWMS() and getWFS() should
be in their requests.
Currently (these may be fixed)
* The new namespace button doesn't seem to do anything.
* All the style buttons (edit, new) seem to give null pointers.
* The color of the new datastore link blends in too much with the
background, I missed seeing it a few times. Might be also better as a
button, as we seem to have the button thing going for other 'new's
* Submitting a new postgis datastore from DataConfigDataStoresNew.do
leads to a null pointer exception: java.lang.NullPointerException
at
org.vfny.geoserver.form.data.DataDataStoresEditorForm.reset(DataDataStoresEditorForm.java:96)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:816)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
I tried it with a few different options and they all seemed to fail.
* A new datastore should be enabled by default - you currently have to
check the box. If you're making a new datastore you probably want it
enabled.
Other:
* The contact info on the main page should show up in the WMS
capabilities response - this is why we had it in there originally.
* We should define the 'normal' style programmatically - I had errors
when that file wasn't present - we shouldn't depend on it being there,
users may accidentally delete it or something, and it shouldn't be hard to
build that style with the stylebuilder.
* Can we precompile the jsps? Starting up the web admin app takes awhile
on the first run, since the servlet container is spending a bunch of time
compiling the jsps, making it so the first impressions that users get of
it is a slow piece of software. It's actually not that slow, so I'm
wondering if we can fix that somehow?
* The release war should have some documentation - at the very least a
link to the online docs. If we do the versioning of docs on the website
we were talking about then a link would be fine, if not then we should
reference locally.
* Related to this, I think that the admin tool should perhaps be at
http://localhost:8080/geoserver/admin, instead of at the root geoserver
directory. If this is a bitch to do then it's ok, but it seems to me that
it's just another service that geoserver offers. I think the root should
have an index page, I liked the approach of gt2wms, which loaded up a few
maps using the wms, so you could instantly see if the install was correct.
And it had a few quick tips as well. I think something like that would be
perfect, with links to the documentation, the admin interface, and some
sample wms maps, maybe some sample gml as well. With a nice root index
page then people downloading the release war will know will have a nice
obvious entry point. Right now they just get some weird admin tool, not
even the core wfs caps document. I think something should be done about
this before the beta release, so that the downloadable war has some
documentation.
* Why does confPostGis.zip have a bunch of shapefiles under the cblf
namespace? I'm guessing these are for wms? If so then they should go in
the confShapeFile.zip instead, and the postgis zip should just have the
info.xml files along with an expanded cite_data.sql, that adds the cblf
features to the postgis install.
Ok, I think that's all from me for now. And I think I may actually be
able to start testing cite now... I'll try to be online more tomorrow
than I was today.
Chris
Or on the other hand it would be a great introduction to Struts for you ...
But knowing struts is