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
>
------------------------------------------------------------------------------
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
