On 7 sept. 2011, at 13:17, Sanne Grinovero wrote:
>
> We already have a simple interface for common use cases, it's StringBridge /
TwoWayStringBridge. FieldBridge is for complex use cases by essence. I might miss
something but it looks like you are inventing something that already exists.
Right that would fit perfectly, but the mapping annotations take a
FieldBridge implementation (@Field, @FieldBridge) so while the most
common case is likely applying a StringBridge via it's
TwoWayString2FieldBridgeAdaptor, we're still dealing with a
FieldBridge.
No, the mapping annotation accepts StringBridge / FieldBridge and their TwoWay
counterparts.
This seems to suggest we should treat the optimisations differently
by
checking if the implementation is a TwoWayString2FieldBridgeAdaptor,
and add what we eventually need to this internal class.
That made me realize. Most of our bridges are stateless wrt the field name. ie the field
name is passed as a parameter and we use it. Even many user provided FieldBridge will be
like that. Which means getTargetedFieldNames() is not implementable for such bridges.
One alternative approach would be to use annotations on the FieldBridge implementation
@TargetedFields(value=PROVIDED_FIELD_NAME)
@TargetedFields(value=FIELD_LIST, fieldList={"foo", "bar"})
@TargetedFields(value=ALL)
we can even later implement if that makes sense
@TargetedFields(value=FIELD_PREFIXES, fieldList="foo") //all fields starting
with foo
Most of our fields would use @TargetedFields(value=PROVIDED_FIELD_NAME)
The names are not good yet but you get the idea.