I probably just did not explain very well - in both cases there should be no api shift for geoserver and no behavior should change at all.
Option 1 - pull up a superclass DTO. This is probably what we will do since there is an Eclipse Refactoring support for it and it can be done smoothly as a result.
Option 2 - push the DTO into a delegate
Option 3 - straight up separation
There is another unstated question here - how to make the Bean/DTO available? Option 1 can be done with an instanceof check; but you may wish to return a copy.
BEFORE
class FeatureTypeInfo {
XYZ xyz;
Catalog catalog;
XYZ getXYZ(){ return xyz; }
Catalog getCatalog(){ return catalog; }
}
OPTION 1 AFTER PULL UP SUPER CLASS REFACTORING:
class FeatureTypeInfo extends FeatureTypeMetadata {
Catalog catalog;
Catalog getCatalog(){ return catalog; }
// optional publish metadata
FeatureTypeMetadata toMetadata(){
return new FeatureTypeMetadata( this ); // return a copy for safety
}
}
class FeatureTypeMetadata {
XYZ xyz;
FeatureTypeMetadata( FeatureTypeMetadata origional ); // copy constructor
XYZ getXYZ(){ return xyz; }
}
OPTION 2 AFTER DELEGATION (same arrangement just using aggregation rather then superclass; works better with multiple inheritance of interface);
class FeatureTypeInfo extends FeatureTypeMetadata {
Catalog catalog;
FeatureTypeMetadata delegate;
Catalog getCatalog(){ return catalog; }
XYZ getXYZ(){ return delegate.getXYZ(); }
// optional
FeatureTypeMetadata toMetadata(){
return new FeatureTypeMetadata( delegate ); // return a copy for safety
}
}
class FeatureTypeMetadata {
XYZ xyz;
FeatureTypeMetadata( FeatureTypeMetadata origional ); // copy constructor
XYZ getXYZ(){ return xyz; }
}
OPTION 3 AFTER STRAIGHT SEPARATION
class FeatureTypeInfo extends FeatureTypeMetadata {
Catalog catalog;
FeatureTypeMetadata delegate;
Catalog getCatalog(){ return catalog; }
XYZ getXYZ(){ return delegate.getXYZ(); }
// optional
FeatureTypeMetadata toMetadata(){
FeatureTypeMetadata metadata = new FeatureTypeMetadata();
metadata.set( xyz );
return metadata; // externalise metadata content
}
}
class FeatureTypeMetadata {
XYZ xyz;
void setXYZ( XYZ value ){ xyz = value; }
XYZ getXYZ(){ return xyz; }
}
On 03/03/2010, at 10:45 AM, Justin Deoliveira wrote:
Not sure I agree here, or maybe I just don’t understand you. The beauty of the extension method is that there is no api shift for GeoServer. It is a straight refactor and no behavior should change at all.
I agree that we do walk a thin line providing straight pojos and classes that do data access in the same interfaces and classes. But something like this is a separate concern as far as i am concerned and should occur after the refactor is completed.
-Justin
On 3/2/10 6:28 PM, Jody Garnett wrote:
Thought about this a bit more… think it may be “safer” in terms of api shift to use aggregation rather then extension. The problem we had with the previous STRUTS stuff came down to duplicating methods every which way and I am worried about the same path …
class FeatureTypeInfo {
FeatureTypeMetadata bean; // wrapped
Catalog catalog;
… accessors and delegation
}
On 02/03/2010, at 7:46 PM, Jody Garnett wrote:
Catching up … I share justin’s frustration on this one (seen the catalog api too many times!).
One possible avenue forward would be to pull out a super class;
FeatureTypeInfo extends FeatureTypeMetadata …
That way you are not stuck removing setCatalog / getCatalog and other methods justin needs to make the catalog go? However I am not sure that helps you with your need.
Can you please clarify the purpose; are you really just wanting a “data transfer object” to send back and forth? ie you would like to send java beans back and forth between the applications?
Jody
On 25/02/2010, at 11:41 PM, Emanuele Tajariol wrote:
Hi all,
I created a GSIP about a refactorization of the catalog beans.
You can find it at
http://geoserver.org/display/GEOS/GSIP+45±+Moving+GeoServer+model+in+a+standalone+module
Here’s a little excerpt from the proposal:
==============================
At the moment, when an external app needs to exchange data with a GeoServer
instance (e.g.: via REST or by accessing a DB-based catalog), it has to
re-define its own set of beans representing Stores, Resources, Styles and so
on.
It could be extremely handy if external applications could use the very same
*Info beans used by GeoServer (both interfaces and related implementations).
In the present architecture this cannot be accomplished without importing in
the external app all the catalog logic, that is useless outside a complete
GeoServer instance.
All in all, this refactoring will make clear the boundaries of metadata
objects, making the creation of modules for marshalling/umarshalling them
much simpler.
==============================
Ciao,
Emanuele
Ing. Emanuele Tajariol
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
http://www.geo-solutions.it
http://geo-solutions.blogspot.com
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
