Hi Anton,
Jörg Schaible wrote:
> Hi Anton,
>
> Antony Warner wrote:
>
>> Hi,
>>
>> Thanks for the quick response.
>>
>> Yes I can see now that it would be problematic in some cases, although
>> OK in others, so overall might be difficult to attempt to work it in as
>> a clean feature.
>>
>> The basic requirement is to apply default mappings to an XStream
>> instance that can then be selectively overridden (by some other piece of
>> external logic) to encourage a consistent (and particular) style of XML.
>>
>> This isn't possible currently then and based on what you said isn't
>> going to get implemented either, so I'll work around it.
>>
>> I can apply defaults that can be overridden (aliases), then have the
>> external logic indicate what it is interested in applying mappings to
>> (which fields) and then apply default mappings to any fields not
>> touched. It's not ideal but it will work well enough for our purposes.
>
> I just wanted to explain, why there is no general functionality in XStream
> to undo any possible setting, what your suggestion seemed to imply:
>
> [snip]
>
>>>> If not, would it be a reasonable feature request to allow these sorts
>>>> of mappings to be unset on an XStream instance? I think this can be
>>>> done by extra API calls on XStream that then unset things on mappers
>>>> like AttributeMapper and LocalConversionMapper. For example
>>>> XStream.useElementFor methods, XStream.unregisterConverter methods, and
>>>> XStream.unregisterLocalConverter methods. XStream.useElementFor for
>>>> example would ask AttributeMapper to remove a field from it's internal
>>>> Set.
>
> [snip]
>
>>> So, these were the facts. What do you really need of this? AFAICS it is
>>> currently only the possibility to remove the attribute flag again.
>
> As stated, I can imagine a method "useElementFor". Settings for aliases,
> global or local converters can already be overwritten (but not
> reverted/unregistered).
>
> If you're still interested, please open a new JIRA issue for it.
After looking at the current implementation, I have to confess, that a
useElementFor functionality is problematic ion a similar way to converter
registration:
xstream.useAttributeFor("name", String.class);
xstream.useAttributeFor(String.class);
xstream.useAttributeFor(Foo.class, "name");
xstream.useElementFor(Foo.class, "name");
Even if the last call reverses the 3rd one, it would not affect the setting
of the first two calls.
- Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
