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

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

Cheers
Andrea


-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

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

Reply via email to