Justin Deoliveira ha scritto:
Great, thanks Jody, your feedback as always is great. While I do think the UI requirement is a bit premature, its definitely on the list of things to look out for after we assert this process as successful. I am going to add a section to the proposal and resulting process doc called "Future Amendments" to track things like this that we may want to add to the process later.
Hey all,
sorry to chime in late to the UI party.
I too believe that a module does not have a requirement for a UI when
it does not add any configuration option, but it seems to me it's a good
idea to ask for one when there are extra config options added by the module.
Jody's suggestion to try and find an excuse for the module to show
up in the UI sounds kind of like trying to fit a square peg in a round
hole. The "plugin" setup of GeoServer is very free form, you just add
a jar with an applicationContext.xml and with that you can contribute
new output formats, new transaction listeners, new datastores, none
of them _needs_ to add config options, so none really needs a UI.
Certainly, for a few well known extension points we could have some
sort of a UI, list listing all the output formats (and allow to
disable them), or listing all the datastores, and so on.
On the other side, when you're adding a new module like WPS, well,
yeah, in that case new configuration is in order, for that I would
really like to see a config UI as well. In that case the new UI
required is substantial, meaning it's worth the extra effort to learn
wicket.
In the case of a very small extra UI, I'm wondering if the "monkey
see/monkey do" approach would work: if the UI contribution is small, is
it conceivable that the module maintainer builds the required
extra UI by copying an existing one? I mean, the dev already went
some miles to integrate the extra configuration in the config subsystem
and hook it up so that it can be saved, is asking for a one wicket
page that much?
Cheers
Andrea