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?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
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.
Justin Deoliveira ha scritto:
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".
Yup, I'll rename them (DataStoreEditPage and CoverageStoreEditPage)
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) FooEditPageNot saying that is what we should we must choose, but I would like to choose a convention.
Agreed, I would love to see this convention applied too
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.