> > So I have been given some new default configuration data to stick
into
> > GeoServer and I have done so.. a set of six shape files added to
the
> > UserBasic configuration.
> Uh. Ok, I guess that's fine. Perhaps an explanation on why we feel
> these are needed in the default configuration? I'm sort of inclined
to
Ah my bad - explaination is that we are making a demo. Demo will be
available as
examples/docs. We never got around to creating validation examples,
and we need
a couple layers to do so.
Ok, validation in user conf would be a good thing. I still don't
understand it really, and forget about it (like in that email about
geoserver's capabilities, as it's actually something that no other
wfs's have, but I just forgot about it).
> Actually, I meant to bring something up on the size issue. How
> necessary is our dependance on xercesImpl? As far as I could tell
our
> XML configuration writer uses some Output classes. Is there another
> way to do this, or do we need xerces? I guess that could be another
> argument for the avalon stuff (though it may rely on xerces as
well).
> I think everything else that xerces does can be done by whatever the
> servlet container is using for xml stuff.Um isn't xerces included in Java 1.4 these days?
Uh yeah, I guess it is? I just tried out making the war without
including xercesImpl and it totally built and ran fine on tomcat, jetty
and resin. Which is weird because I'm sure that before I needed it. I
was seeing what jars we could live without and it didn't work if
xercesImpl wasn't there.
> this stuff if it wasn't in UserBasic, because UserBasic is what goes
> out to all of our users, so it really should look good and make
perfect
> sense. And having a geoserverdemo folder in their main conf/ folder
> makes it seem like its a standard folder, when it's really not.We can do that - I would like to have a validation test or two in the
UserBasic.
So there is something that makes sense to start from when they open up
the
validation processor ui.
Ok, sounds good. Could you just keep it really clean? Like put the
shapefiles in the same directories as info.xml, as that's how we
recommend people do it? And don't use the generated services and
catalog xml files? Just add what you need by hand, so they
have the extra comments and formatting? I would maybe be a bit less
anal about this if our web interface totally worked across all servlet
containers, but it really doesn't, so I want users to have an easy time
working with the config files directly.
Also, the other thing you could consider doing for you demo files is to
do them with postgis instead of shapes. Actually, thinking on it, you
may have to do that, since transactions don't work with shapefiles, so
you wouldn't be able to do things like show the results of an insert or
an update. Then you would only need one extra datastore in catalog.xml
(or you could even change local.postgis to suit your needs). You can
change the default parameters to be exactly what you need and/or make a
public postgis instance (even if just for the length of your demo).
And then also include a postgis sql script to allow others to create
the features as well. Up to you, and you could just do both. It would
be nice to have some postgis demos though, some creation scripts that
people could get started with right away. You could even include a few
extra tables that you don't initially give info.xml's to, that you can
show how to create with the web interface.
Chris
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/