Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
Cheers
Andrea
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
IMHO you should add sample/demo requests for each feature type you deploy. This is usually critical for either approach - explaining how to use your "private" feature dumped from your database, or for conformance tests againsts an externally defined schema.
So, demo requests should be bundled into the feature type configurations.
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
IMHO you should add sample/demo requests for each feature type you deploy. This is usually critical for either approach - explaining how to use your "private" feature dumped from your database, or for conformance tests againsts an externally defined schema.
You mean, as a way to quick test if you feature type is working properly?
So, demo requests should be bundled into the feature type configurations.
Rob, most demo requests are set up with knowledge on attributes and
their values, it's possible to make them up inspecting a little data,
but what I'm suggesting is maybe 1 hour work, what you're suggesting
quite a bit more. I have time for the first, not sure about the second.
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
Is there any reason we can't just do both? Pick up both the classpath and the data_dir?
The other thing I've wanted for awhile is a 'save' button in the UI, so that if you type in a new request there you can just hit 'save' and supply a name and it will then go in to the data_dir. Which shouldn't be hard to implement, if programmers didn't hate our UI situation.
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
Is there any reason we can't just do both? Pick up both the classpath and the data_dir?
Sure, it's an easy one to implement.
The other thing I've wanted for awhile is a 'save' button in the UI, so that if you type in a new request there you can just hit 'save' and supply a name and it will then go in to the data_dir. Which shouldn't be hard to implement, if programmers didn't hate our UI situation.
Hem... let's try to fix the UI situation first, and then I'll promise you'll have a user interface that "does coffee" too, as we say
in Italy
Hey for the Demo request it is just a servlet (no coffee) so it should be easy to hack
Pretty long lived for a "day before the demo" hack.
Cheers,
Jody
Chris Holmes ha scritto:
Andrea Aime wrote:
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
Is there any reason we can't just do both? Pick up both the classpath and the data_dir?
Sure, it's an easy one to implement.
The other thing I've wanted for awhile is a 'save' button in the UI, so that if you type in a new request there you can just hit 'save' and supply a name and it will then go in to the data_dir. Which shouldn't be hard to implement, if programmers didn't hate our UI situation.
Hem... let's try to fix the UI situation first, and then I'll promise you'll have a user interface that "does coffee" too, as we say
in Italy
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
IMHO you should add sample/demo requests for each feature type you deploy. This is usually critical for either approach - explaining how to use your "private" feature dumped from your database, or for conformance tests againsts an externally defined schema.
You mean, as a way to quick test if you feature type is working properly?
yep, and to show others how to use them without inspecting data (painful over network for large data)
So, demo requests should be bundled into the feature type configurations.
Rob, most demo requests are set up with knowledge on attributes and
their values, it's possible to make them up inspecting a little data,
but what I'm suggesting is maybe 1 hour work, what you're suggesting
quite a bit more. I have time for the first, not sure about the second.
I'm suggesting best to leave alone (0 hours work) until a complete solution is on the cards. We have to focus more on users, and developers should have sample requests as part of an online test coverage, not a user focussed demo..
Hi,
as from summary, it would be nice to be able, play, and add sample
requests easily. Unfortunately, having them into the data directory
means that each additions should be made, and then added to the
config zips.
Can't we just have the demo requests among the web pages stuff, or
in the classpath, instead? I guess the tension is between having it
easy for the programmer to add new sample requests, and possible
for the user. Then again, a user adding sample requests does not
seem to be common to me.
IMHO you should add sample/demo requests for each feature type you deploy. This is usually critical for either approach - explaining how to use your "private" feature dumped from your database, or for conformance tests againsts an externally defined schema.
You mean, as a way to quick test if you feature type is working properly?
yep, and to show others how to use them without inspecting data (painful over network for large data)
Hum, I'm wondering if, in this case, it wouldn't be better to have a
small console that allows to build a GetFeatures graphically, or to
preview data in WMS with some filtering.
