That's OK, I can see the difficulty.
Personally I would not expect
xstream.useElementFor(Foo.class, "name");
to reverse all three calls anyway. Assuming that there is a good reason
why both
xstream.useAttributeFor("name", String.class);
and
xstream.useAttributeFor(Foo.class, "name");
exist, and I confess I'm not totally sure on why you have those two
different API calls for indicating an attribute should be used for a
particular field, it seems reasonable that useElementFor(Class, String)
would reverse a call to useAttributeFor(Class, String) only.
There could be further useElementFor(Class) and useElementFor(String,
Class) methods to reverse the other two calls.
On 05/11/12 07:44, Jörg Schaible wrote:
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
--
Antony Warner
Software Developer
Gresham Computing PLC
e: [email protected]
w: http://www.gresham-computing.com
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Computing plc Registered in England and Wales. Company No. 01072032 Registered Office: Sopwith House, Brook Avenue, Warsash, Southampton. Hants. SO31 9ZA Further information about Gresham Computing can be found on our website: www.gresham-computing.com
