Right, this is done intentionally because we assume that an empty 
getAttributes() means derive them from the underlying feature type. The 
reason the persister uses getAttributes() and not attributes() is 
because if the attributes get stored on disk it then assumes the user 
has performed a manual override and then any ability to change the 
underlying feature type dynamically goes bye bye.

That said in some cases we do want to output the derived attribute list, 
like for REST output. In my opinion I think we should probably just add 
a flag to XStreamPersister which will control this behaviour. By default 
leave the behaviour as is but for rest set the flag. We do this with 
various other things too. See AbstractCatalogResource.createXMLFormat().

-Justin

On 3/18/10 2:24 PM, Andrea Aime wrote:
> Andrea Aime ha scritto:
>> Oh hum... looks like a trunk only change to me?
>> Well, in the meantime I'll play with a type creation GUI :-p
>
> Humm... tried to actually use the rest config instead but
> I'm getting stuck.
>
> So, I've added the necessary fields to AttributeTypeInfo
> and I was expecting to see them appear in the feature types
> xml descriptions.
>
> Unfortunately that's not happening. For feture types already
> configured, nothing changes, and for the new ones, there
> are no attributes at all in the output.
>
> For what I can see the issue is that the rest configuration
> is using FeatureTypeInfo.getAttributes(), that is, the stored
> ones, instead of calling to FeatureTypeInfo.attributes().
>
> If I'm recalling things right the AttributeTypeInfo were
> used only to drive the schema overrides in terms of hiding/showing
> an attribute, so trying to use them to actually describe the
> attributes in the feature type is probably the wrong way to go?
> Or else, some rework is needed in all REST outputs/inputs
> to actually make them play the role of the attribute descriptors.
>
> Opinions?
>
> Cheers
> Andrea
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

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

Reply via email to