Andrea Aime wrote:
Justin Deoliveira ha scritto:
Question. Is everything under org.geoserver.web.wicket intended to be totally generic? Or just any component used in more than once place? The reason i ask is because browsing through the directory I see the class "WorkspaceChoice", which makes me think that common widgets/controls for the catalog will go under this structure.
Well, isn't the UI meant to deal mostly with catalog configuration?
All the models I can think of that would go in wicket/models are
wrappers of catalog elements as well.
I agree that catalog is the majority, but service configuration, global configuration, etc... are orthogonal. And since we are building the UI in an extensible way who knows what is coming down the pipe.
Whilst there are a few classes that can be totally generic, I think
most of them would be GeoServer and catalog specific, and there
are classes that can be in a gray area.
For example, a bbox editor, is that catalog specific?
We'd use it only in catalog pages so far, but maybe some new demo page
could use it as well. But the same could happen to a layer chooser.
What I mean is, it's usage is specific today, but tomorrow a demo
or a new service configuration could make the component used outside
of the catalog "space".
So I would have trouble deciding where to put each component.
If we follow you lead we'd start having a component/model/converter
set of packages under wicket, but also one under data, and maybe
some under the services? And what triggers the creation of a new
subset of those packages?
Well we could adopt just a single reusable wicket package as opposed to four. Indeed at the moment it seems as if component is the only one with classes in it? With model soon to have some classes in it. That would reduce the proliferation of packages and we could have one for true reusable, one for catalog reusuable, etc... It does make sense imo from a package point of view. If the only user of a component is under the "data" hierarchy why not leave the component in the "data" hierarchy.
I don't really have good grips on this kind of classification,
and would probably put everything in that generic package until
some sort of evident pattern emerges, but if you feel strongly
about it, we could go for it anyways, and I'll ask you where
to put components/modules/converters I'm not sure about.
Well the line is pretty clear in my mind: If you take the catalog away does the component still function? Given this criteria the bounding box widget would make the cut.
Anyways, while I do feel strongly about how we organize classes and packages I am willing to wait and see what happens and re-organize later if it is deemed necessary. I just ask that such things are kept in mind and people remain open minded to a reorganization of the classes down the road. What worries me is that it is a lot easier to mash things together than to pull them apart. So trying to reorganize down the road could prove difficult.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.