Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Andrea Aime wrote: >>> Hi, >>> I'm having some troubles with the catalog objects I'd like >>> to discuss. >>> >>> There are a few catalog objects that do require some access >>> to GT2 provided information. For example, FeatureTypeInfo >>> can return a FeatureType, AttributeTypeInfo an AttributeDescriptor. >>> The way things are done now, that information provided >>> by some external entity during the object construction. >>> >>> Which works fine only as long as the object is serialized >>> and deserialized... which happens when those objects are >>> used within Wicket models. Now, for pure editing a form >>> can be backed by a loadable/detachable model that will >>> grab again the same FeatureTypeInfo from the catalog, >>> it's more work, but it's doable. >> Question, I thought we abandoned using straight serialization for >> catalog objects and instead adopted loadable detachable models, or is >> this just in some cases? > > In some cases. You cannot use a loadable/detachable model > if there is nothing to detach, in particular, you cannot > detach a catalog object that has not been saved 'cause > there is nothing to reload from the catalog. > In this case, you're basically forced into saving the > object itself (or not?) Right, I guess my question was that for all objects that have already been added to the catalog, there should be no need to serialize? And a loadable detachable model should be used? > >>> 2) Mark a few properties as unsafe to use in the UI, >>> and build models that know how to handle them? >>> Let me know >>> >> I don't think I quite understand option 1, but I think I prefer option >> 2, with perhaps a spin: >> >> a) omit properties that require the external resources, making them >> available only on an edit, or: >> >> b) if the property is necessary on the new form, create a model that >> loads it "manually", ie not through the feature type. This is more or >> less what the old stuff did to get around this i believe > > Works for me, we just have a handful of these cases, so I guess > we can create reusable loadable/detachable models that know > how to re-instate the lost attribute programmatically on reload? > The candidates would be ResourceInfo and subclasses, by > extension LayerInfo (since it holds a ResourceInfo), and > AttributeTypeInfo? From what I can see all they need is to > have the catalog set back in once deserialized? > The loadable model could do this... > Sounds good to me. > 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
