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. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
