Andrea Aime wrote: > Hi, > org.geoserver.web.data contents seem a little mis-organised. > I already moved the classes in org.geoserver.web.data.table > into a layer and store packages, what's left to organise > a little is the root content of org.geoserver.web.data > that seems to contain layer/resource editing related pages. > Where do we move them? org.geoserver.web.data.resource?
Sounds good to me and thanks for organizing the packages. While on the topic of organization, I notice that a few of the names for components are inconsistent. I seem to remember us agreeing a while back that a class name should be suffixed with what type of component it is. For example, page class names should end in "Page", panel classes should end in "Panel", etc... I notice there are a number of inconsistencies. Examples: DataStoreConfiguration and CoverageStoreConfiguration should end in "Page". Another thing is naming conventions for related pages. For many of our "domain" objects we have 3 page classes: 1) a page to list all the instances 2) a page to add a new instance 3) a page to edit an instance (occasionally 2 and 3 are combined). The convention i have been following is: 1) FooPage 2) FooNewPage 3) FooEditPage Not saying that is what we should we must choose, but I would like to choose a convention. -Justin > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
