[#XSTR-500] Provide wildcard for field names

XStream

Provide wildcard for field names

Created: 24/Jun/08 01:52 PM Updated: 25/Jun/08 02:35 AM

Component/s:

Core

Affects Version/s:

None

Fix Version/s:

Upcoming

Issue Links:

Related

This issue is related to:

XSTR-344 Allow convert element with string body and attributes

Description

« Hide

Provide funcionality to execute some operations in all attributes of a class. For example:

xstream.useAttributeFor(Book.class, "*") //all fields of Book class
or
xstream.useAttributeForAllType(Book.class) //all fields of type Book

insted of write all the field like:
xstream.useAttributeFor(Book.class, "author")
xstream.useAttributeFor(Book.class, "name")
xstream.useAttributeFor(Book.class, "price")
.... and so one

This can be made in several methods like these:

xstream.omitField
xstream.addImplicitCollection
xstream.alias

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Joerg Schaible - 25/Jun/08 02:35 AM

Looks like a nice idea at first glance, however there have to be some considerations taken into account:

wildcards for attribute definition:
1. the wildcard assumes that all matching fields are handled by SingleValueConverters
2. the attribute definition can only be defined for the fields declared in the type, not for the inherited fields. This might be surprising using a wildcard

wildcards to omit a field:
1. the omit field definition can also only be defined for the fields declared in the type, not for the inherited fields. This might be surprising using a wildcard

wildcards for an implicit collection:
1. the membership to an implicit collection is defined at least by the type of the collected items. If two implicit collections define the same item type (which will be implicitly Object.class if none has been defined), their elements cannot be distinguished anymore and after deserialization the first collection will contain all elements, while any other will contain none. Therefore a wildcard does not make sense here at all.

wildcards for aliases
1. a type (resp. field) and an alias is always a 1:1 relationship. Mapping more types (fields) to the same alias will cause all serialized objects to be deserialized with the type (resp. field) the alias has been defined for last. Therefore a wildcard does not make sense here also.