[XSTR-500] Provide wildcard for field names

Details

Type: Improvement
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 1.4
Component/s: Core
Labels:
None

Description

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

Issue Links

is related to

XSTR-344 Allow convert element with string body and attributes

Activity

Hide

Permalink

Jörg Schaible added a comment - 25/Jun/08 2: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.

Show

Jörg Schaible added a comment - 25/Jun/08 2:35 AM Looks like a nice idea at first glance, however there have to be some considerations taken into account: wildcards for attribute definition: the wildcard assumes that all matching fields are handled by SingleValueConverters 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: 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: 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 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.

Hide

Permalink

Jörg Schaible added a comment - 13/Oct/11 4:39 PM

Since XStream 1.4 there's no a wildcard support, but the new ToAttributedValueConverter exists that allows you at least to use attributes for all fields or for all fields but one. There is no need with this converter to declare all the other fields as attributes anymore.

Show

Jörg Schaible added a comment - 13/Oct/11 4:39 PM Since XStream 1.4 there's no a wildcard support, but the new ToAttributedValueConverter exists that allows you at least to use attributes for all fields or for all fields but one. There is no need with this converter to declare all the other fields as attributes anymore.

Provide wildcard for field names

Details

Description

Issue Links

Activity

People

Dates