On 01/06/2009, at 8:09 PM, Andrus Adamchik wrote:
there already is a CayenneMapEntry interface
The one I'd love to get rid of :-) We discussed that some time ago.
It was poor design back in the day, that now has life of its own.
Ah I'd forgotten. Perhaps you'd like to mark it as deprecated in the
code? With a superclass in place, we could move the functions in the
interface into the superclass as abstract and hasten the demise of the
interface.
I am still not convinced that we need anything but a String.
Remember in EOF this was called "userInfo", with "user" being the
keyword. This is for people to extend Cayenne in previously
unsupported ways. If *we* decide we need a new property for Entity
or Attribute class, we just add it in a normal Java way. What's the
point of a generic Info object then?
My argument for a real class is:
* it seems simpler (that way it works like all other elements in the
map)
* we can extend it: perhaps I didn't explain well enough. Say we want
to allow some MapEntryProperties to propagate to the client in ROP and
others not to (for security or speed reasons). Then we'll need a new
field in MapEntryProperty as "availableOnClient".
* we might like to type properties. Say a user wants to create
"maxCacheTime" as a MapEntryProperty with an int value in seconds.
They have code which does clever things in expiring caches for that
ObjEntity. But we need a way to ensure that particular
MapEntryProperty is stored as an int and they can define that in the UI.
So for these reasons, it seems simpler to me to have these properties
as their own real class rather than just a Map attached to the
superclass MappingObject.
I like MappingObject by the way, but this is getting rapidly bikeshed,
so I have no strong opinion about class names.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
