Andrea Aime wrote: > Justin Deoliveira ha scritto: >>> Drawing some parallel with the way Hibernate works, what >>> about a: >>> Catalog.attach(Info info) >>> that does reconnect the impl with the catalog after it >>> has been deserialized. This has the advantage of not having >>> the UI code explicitly know about what needs to be done >>> and to make it stay away from the *Impl classes. >> Hmmm... I am not against it but I want to be sure we are not adding a >> method to the catalog interface just to get around an implementation >> detail. If we did have a hibernate catalog implementation, would a >> similar method be necessary? > > Well, it is an implementation details, those are serializable classes > that have fields that do not survive a serialization cycle, that's not > normal, it's something that one has to document. > So, it's an implementation detail now, if you document it in the > javadoc, it's no more. My point is that I want to avoid polluting the Catalog interface with methods that only apply to the in memory implementation, trying to keep the interface clean and resist the temptation of just adding methods as needed. This is what happened more or less to the old catalog code, and you know where it left us :) > > We can also change those classes so that they get back the catalog > during de-serialization, adding a readObject method that first > calls the super, and then sets the catalog by using > GeoServerExtensions to reach to it. I would like to avoid adding any specific java serialization to those classes... it adds a quite a bit of complexity. > > Anwyasy, to get back to the point, the wicket serialization occurs > in memory, has nothing to do with the hibernate long term one, > so the two are orthogonal, a hibernate backed catalog would > have the same problem. > OK, so lets add the method then. Although Catalog.attach(Info) will not really do it since Info applies to configuration objects as well. The pattern in the catalog as of now is to have a method for each type of object, look at add(),save(),remove(), etc..., so:
attach(StoreInfo) attach(ResourceInfo) etc... The reason is because we did not have a root object. We could add a CatalogInfo root object for all catalog objects but i would like to keep the interface methods consistent for now. So i would prefer we either: 1) add attach() methods for each of the type of object, this means 8 methods. 2) add the method to method to CatalogBuilder for now. And perhaps refactor the Catalog interface a bit to use a root Catalog interface. > So what should it be, Catalog.attach(Info) or we do try a > reattach on the fly during deserialization? > > 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
