You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@maniatis.org> on 2009/06/01 07:50:41 UTC
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Jack is an intern at ish who has been working on this task. We
discussed the basic design strategy and class structure, and Jack has
put together some code. We'd like some feedback about the approach,
especially the idea of superclassing the CayenneMapItems to allow for
the code to live in one place.
The next step will be to implement the Cayenne Modeler UI, for which
I've drawn some mockups Jack will implement.
Ari Maniatis
On 01/06/2009, at 3:22 PM, jackCHEN (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/CAY-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> jackCHEN updated CAY-400:
> -------------------------
>
> Attachment: patch_2009-5-28
>
> On the basis of Ari's suggestion, i try to make most elements can
> use comment function.
>
> I add a Abstract CayenneMapItem Class which provides comment
> function.Through inheriting it, Entity, Relationship,
> EntityListener, Attribute automatically get the same function.
>
> According to the detailed key value, we can define different
> operations.
>
> I.E.
>
> Use "doc" key to generate Javadocs during class generation
> Use "annotation" key to generate JDK 1.5 annotations during
> class generation
>
>
>> Support for user properties of DataMap objects.
>> -----------------------------------------------
>>
>> Key: CAY-400
>> URL: https://issues.apache.org/jira/browse/CAY-400
>> Project: Cayenne
>> Issue Type: New Feature
>> Components: Cayenne Core Library, CayenneModeler GUI
>> Affects Versions: 3.0
>> Reporter: Andrus Adamchik
>> Assignee: Ari Maniatis
>> Fix For: Short term future
>>
>> Attachments: patch_2009-5-28
>>
>>
>> We need to support user defined properties attached to
>> * Entities
>> * Attributes
>> * Relationships
>> (Obj and Db). This feature is similar to JDK 1.5 annotations.
>> Basic support:
>> * allow to enter string key/value pairs in the Modeler and save
>> them in XML.
>> * Just like with JVM annotations implement some logic to load
>> annotations conditionally.
>> Ideas for using this info in Cayenne:
>> * Attach DB comments on reverse-engineer
>> * Use certain keys to generate Javadocs during class generation
>> * Use certain keys to generate JDK 1.5 annotations during class
>> generation.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 1, 2009, at 12:30 PM, Andrey Razumovsky wrote:
> "MappedObject" or "AbstractMappedObject"
"Mapped" logically sounds something like CayenneDataObject (i.e. a
persistent object that we mapped in Cayenne).
MappingObject implies metadata, which is what we want.
Andrus
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Robert Zeigler <ro...@roxanemy.com>.
The other main use I can see for an ObjEntity dictionary is to
generate annotations.
Robert
On Jun 1, 2009, at 6/18:30 AM , Michael Gentry wrote:
> The main thing I'd want to use a "user info" dictionary/map for is to
> generate JavaDoc documentation for the getters, setters,
> relationships, and class. It would also be nice if you could add
> documentation for the database tables and columns and for databases
> that support comments, when we generate the schema I'd like it to add
> the documentation as a comment for the table/column. For Java classes
> that don't have a user info documentation for a class/attribute, but
> the database entry does have documentation, use the database
> (DbEntity) documentation in the JavaDoc. It would also be nice if the
> documentation was very visible in the modeler to encourage use. In
> EOModeler for EOF, the user info dictionary was buried and not as
> useful.
>
> I'm sure there could be other uses that people dream up, but
> documenting the model would be the most popular I'd imagine -- at
> least among the people I know.
>
> mrg
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Lachlan Deck <la...@gmail.com>.
On 01/06/2009, at 11:34 PM, Aristedes Maniatis wrote:
> On 01/06/2009, at 11:30 PM, Michael Gentry wrote:
>
>> It would also be nice if the
>> documentation was very visible in the modeler to encourage use. In
>> EOModeler for EOF, the user info dictionary was buried and not as
>> useful.
>
> I've got a design for that which I think will work well.
>
>> I'm sure there could be other uses that people dream up, but
>> documenting the model would be the most popular I'd imagine -- at
>> least among the people I know.
>
> Yes, I think that javadoc and annotations will be two of the most
> popular uses. I'll be putting those into the default velocity
> templates since I think they will be a very common requirement.
Given that they're the two popular cases it might be worth thinking
about adding specific support for them rather than incorporating them
into the 'userInfo' equivalent. That way there's a clean separation.
Just a thought.
with regards,
--
Lachlan Deck
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 01/06/2009, at 11:30 PM, Michael Gentry wrote:
> It would also be nice if the
> documentation was very visible in the modeler to encourage use. In
> EOModeler for EOF, the user info dictionary was buried and not as
> useful.
I've got a design for that which I think will work well.
> I'm sure there could be other uses that people dream up, but
> documenting the model would be the most popular I'd imagine -- at
> least among the people I know.
Yes, I think that javadoc and annotations will be two of the most
popular uses. I'll be putting those into the default velocity
templates since I think they will be a very common requirement.
Ari Maniatis
-------------------------->
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
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap
objects.
Posted by Michael Gentry <mg...@masslight.net>.
The main thing I'd want to use a "user info" dictionary/map for is to
generate JavaDoc documentation for the getters, setters,
relationships, and class. It would also be nice if you could add
documentation for the database tables and columns and for databases
that support comments, when we generate the schema I'd like it to add
the documentation as a comment for the table/column. For Java classes
that don't have a user info documentation for a class/attribute, but
the database entry does have documentation, use the database
(DbEntity) documentation in the JavaDoc. It would also be nice if the
documentation was very visible in the modeler to encourage use. In
EOModeler for EOF, the user info dictionary was buried and not as
useful.
I'm sure there could be other uses that people dream up, but
documenting the model would be the most popular I'd imagine -- at
least among the people I know.
mrg
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
We already have this in the DataMap XML and cayenne.xml:
<property name="XXX" value="YYY"/>
So there are some properties that Cayenne recognizes. Some are used
for the core features (and probably should not be "properties"), such
as DataMap 'defaultPackage', some are properties for optional (but
bundled) extensions, such as JGroups module setup, which I think
should stay as properties.
I guess we need a different namespace for the user properties, but no
reason not to reuse the XML pattern. E.g.:
<!-- without a parent element -->
<user-property name="XXX" value="YYY"/>
This way we have some consistency.
Andrus
On Jun 1, 2009, at 1:36 PM, Aristedes Maniatis wrote:
> On 01/06/2009, at 7:30 PM, Andrey Razumovsky wrote:
>
>> Also could you please wrap "info" tags in XML to parent tag, e.g.
>> <infoset>
>> <info.../>
>> ...
>> </infoset>
>
>
> Why? I don't think that makes it any easier to parse or manipulate.
> And we don't have ObjEntity wrapped in ObjEntitySet, ObjAttribute in
> ObjAttributeSet, etc.
>
>
> 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
>
>
>
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap
objects.
Posted by Andrey Razumovsky <ra...@gmail.com>.
Well, I prefer to use treelike nature of XML more. We can have a lot of
descendant elements (e.g. we add comments afterwards, or something else) and
then XML stucture will become a bit messy. That's just my opinion. And I
didn't say I find current schema perfect :)
2009/6/1 Aristedes Maniatis <ar...@ish.com.au>
>
> On 01/06/2009, at 7:30 PM, Andrey Razumovsky wrote:
>
> Also could you please wrap "info" tags in XML to parent tag, e.g.
>> <infoset>
>> <info.../>
>> ...
>> </infoset>
>>
>
>
> Why? I don't think that makes it any easier to parse or manipulate. And we
> don't have ObjEntity wrapped in ObjEntitySet, ObjAttribute in
> ObjAttributeSet, etc.
>
>
>
> 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
>
>
>
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 01/06/2009, at 7:30 PM, Andrey Razumovsky wrote:
> Also could you please wrap "info" tags in XML to parent tag, e.g.
> <infoset>
> <info.../>
> ...
> </infoset>
Why? I don't think that makes it any easier to parse or manipulate.
And we don't have ObjEntity wrapped in ObjEntitySet, ObjAttribute in
ObjAttributeSet, etc.
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
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap
objects.
Posted by Andrey Razumovsky <ra...@gmail.com>.
Hi,
Yeah, Ari is right about my intention to wait. Maybe the new feature will be
enough so that adding 'comments' will not be required..
As for "CayenneMapItem" class, or whatever you call it (I'd prefer
"MappedObject" or "AbstractMappedObject"), it'd be good to see some more
logic there, like get/setName() (and probably make it implement
CayenneMapEntry). I understand this is impossible because EntityListener
needs user properties.. Maybe separate it to two different classes?
Also could you please wrap "info" tags in XML to parent tag, e.g.
<infoset>
<info.../>
...
</infoset>
Regards,
Andrey
2009/6/1 Aristedes Maniatis <ar...@ish.com.au>
>
> On 01/06/2009, at 6:46 PM, Andrus Adamchik wrote:
>
> There has been a discussion previously on whether properties and comments
>> are the same thing or not. The consensus was that those are two different
>> things. Comments are actually DB-related artifacts (and therefore won't
>> probably be attached to any Obj* metadata objects, or relationships, etc.).
>> Properties are arbitrary strings attached to any mapping object.
>>
>
> Jack is referring to 'comments' since a powerful use of the feature he has
> built is to use them to create things like javadocs with the velocity
> templates. This is not quite the same as Andrey's 'comments'.
>
>
> I assumed you are working on the later feature (properties, not comments)?
>> Also IIRC Andrey was looking at building comment support. Andrey please
>> correct me if I'm wrong.
>>
>
> He was going to wait and see what Jack did here in case there was useful
> overlap. One approach could be to reserve a MapEntryProperty keyword 'db'
> for what Andrey needs. The UI in Cayenne modeler will work well in that way
> I think, but let's see when that is done what you and Andrey think about
> this.
>
>
> 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
>
>
>
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 01/06/2009, at 6:46 PM, Andrus Adamchik wrote:
> There has been a discussion previously on whether properties and
> comments are the same thing or not. The consensus was that those are
> two different things. Comments are actually DB-related artifacts
> (and therefore won't probably be attached to any Obj* metadata
> objects, or relationships, etc.). Properties are arbitrary strings
> attached to any mapping object.
Jack is referring to 'comments' since a powerful use of the feature he
has built is to use them to create things like javadocs with the
velocity templates. This is not quite the same as Andrey's 'comments'.
> I assumed you are working on the later feature (properties, not
> comments)? Also IIRC Andrey was looking at building comment support.
> Andrey please correct me if I'm wrong.
He was going to wait and see what Jack did here in case there was
useful overlap. One approach could be to reserve a MapEntryProperty
keyword 'db' for what Andrey needs. The UI in Cayenne modeler will
work well in that way I think, but let's see when that is done what
you and Andrey think about this.
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
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi jackCHEN,
There has been a discussion previously on whether properties and
comments are the same thing or not. The consensus was that those are
two different things. Comments are actually DB-related artifacts (and
therefore won't probably be attached to any Obj* metadata objects, or
relationships, etc.). Properties are arbitrary strings attached to any
mapping object.
I assumed you are working on the later feature (properties, not
comments)? Also IIRC Andrey was looking at building comment support.
Andrey please correct me if I'm wrong.
Andrus
On Jun 1, 2009, at 11:38 AM, chen li wrote:
> Thanks Andrus. Cayenne is good project and there are a lot of
> genius
> who help it to grow up.
>
> "CayenneMapItem" is just a temporary name. The purpose of the
> class is only providing a set of method which related to comment.
> If the
> function of the class will be expended in future,it can be
> refactored and
> implements a interface which defining the behavior of comment. So i
> think
> the name maybe "CommentMap","AbstractMap", or "MappingObject". Just a
> suggestion.
>
> I think the info Class is necessary to deal with comment.
> Comment is
> a element node which can be added other element node such as
> Obj-Entity,Db-Entity,Obj-attribute etc in a DataMap tree. Any
> element node
> in DataMap Tree can have comment as their sub element node if they
> need. So
> a comment has to record its father element node for be reached when
> the
> whole datamap tree is dealed with.
>
> "Info" name is a temporary name.Maybe "Comment","Annotation"
> are much
> more close.
>
> jackCHEN
>
>
>
> 2009/6/1 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> On Jun 1, 2009, at 8:50 AM, Aristedes Maniatis wrote:
>>
>> Jack is an intern at ish who has been working on this task. We
>> discussed
>>> the basic design strategy and class structure, and Jack has put
>>> together
>>> some code.
>>>
>>
>> Great! Jack, welcome to the community :-)
>>
>> We'd like some feedback about the approach, especially the idea of
>>> superclassing the CayenneMapItems to allow for the code to live in
>>> one
>>> place.
>>>
>>
>> I am ok with a common superclass of mapping objects. I don't like the
>> CayenneMapItem name though. We have no current notion of
>> "CayenneMap", so
>> "CayenneMapItem" is confusing (not that I am happy with the name
>> DataMap,
>> heh :-)). Maybe something like MappingObject, which feels more
>> generic along
>> the lines of "Object Relational Mapping"?
>>
>> Also I am not sure we need a special Info object. A simple
>> Map<String,
>> String> attached to a MappingObject should be enough from what I
>> see. The
>> current Info object has a notion of a parent. Could you elaborate
>> why is it
>> a tree structure?
>>
>> "Info" name is a bit confusing, at least to a Java programmer (I
>> know it
>> was used in EOF). Everywhere else in Cayenne a similar unstructured
>> String
>> data attached to an object is called "property". I suggest we stick
>> with
>> this naming convention.
>>
>> Andrus
>>
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap
objects.
Posted by chen li <ka...@gmail.com>.
Thanks Andrus. Cayenne is good project and there are a lot of genius
who help it to grow up.
"CayenneMapItem" is just a temporary name. The purpose of the
class is only providing a set of method which related to comment. If the
function of the class will be expended in future,it can be refactored and
implements a interface which defining the behavior of comment. So i think
the name maybe "CommentMap","AbstractMap", or "MappingObject". Just a
suggestion.
I think the info Class is necessary to deal with comment. Comment is
a element node which can be added other element node such as
Obj-Entity,Db-Entity,Obj-attribute etc in a DataMap tree. Any element node
in DataMap Tree can have comment as their sub element node if they need. So
a comment has to record its father element node for be reached when the
whole datamap tree is dealed with.
"Info" name is a temporary name.Maybe "Comment","Annotation" are much
more close.
jackCHEN
2009/6/1 Andrus Adamchik <an...@objectstyle.org>
>
> On Jun 1, 2009, at 8:50 AM, Aristedes Maniatis wrote:
>
> Jack is an intern at ish who has been working on this task. We discussed
>> the basic design strategy and class structure, and Jack has put together
>> some code.
>>
>
> Great! Jack, welcome to the community :-)
>
> We'd like some feedback about the approach, especially the idea of
>> superclassing the CayenneMapItems to allow for the code to live in one
>> place.
>>
>
> I am ok with a common superclass of mapping objects. I don't like the
> CayenneMapItem name though. We have no current notion of "CayenneMap", so
> "CayenneMapItem" is confusing (not that I am happy with the name DataMap,
> heh :-)). Maybe something like MappingObject, which feels more generic along
> the lines of "Object Relational Mapping"?
>
> Also I am not sure we need a special Info object. A simple Map<String,
> String> attached to a MappingObject should be enough from what I see. The
> current Info object has a notion of a parent. Could you elaborate why is it
> a tree structure?
>
> "Info" name is a bit confusing, at least to a Java programmer (I know it
> was used in EOF). Everywhere else in Cayenne a similar unstructured String
> data attached to an object is called "property". I suggest we stick with
> this naming convention.
>
> Andrus
>
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 1, 2009, at 1:34 PM, Aristedes Maniatis wrote:
> * 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.
I don't really like complexity of a type system here. This feature has
to be simple. Supporting a type system for properties looks like an
overkill for what we are trying to do here. Although I am with you on
#2 - we need a way to filter properties from the client. So I guess I
am ok with some sort of Property/Info object, as long as the simpler
String API wrapper is available to the end user.
Andrus
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Aristedes Maniatis <ar...@ish.com.au>.
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
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 1, 2009, at 12:06 PM, Aristedes Maniatis 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.
>> Also I am not sure we need a special Info object. A simple
>> Map<String, String> attached to a MappingObject should be enough
>> from what I see.
>
> That's possible, but I'm thinking there might be some additional
> logic which could belong here. For instance, if we reserve some keys
> "javadoc", "annotation" to have special application then we can
> control their use here. And there may also be another attribute in
> the future to prevent some Info objects being passed from server to
> client in ROP.
>
> Also, currently there is no typing (all values are String). But
> there is the future possibility of creating typed values which give
> the user greater validation when entering data in the Modeler.
>
>> "Info" name is a bit confusing, at least to a Java programmer (I
>> know it was used in EOF). Everywhere else in Cayenne a similar
>> unstructured String data attached to an object is called
>> "property". I suggest we stick with this naming convention.
>
> Fair enough. How about MapEntryProperty?
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?
Andrus
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 01/06/2009, at 4:57 PM, Andrus Adamchik wrote:
> I am ok with a common superclass of mapping objects. I don't like
> the CayenneMapItem name though. We have no current notion of
> "CayenneMap", so "CayenneMapItem" is confusing (not that I am happy
> with the name DataMap, heh :-)). Maybe something like MappingObject,
> which feels more generic along the lines of "Object Relational
> Mapping"?
Well, there already is a CayenneMapEntry interface. So we thought that
it should look a bit like that. Really, it doesn't matter though, as
long as it is obvious. CayenneMapObject? Or just MapEntry or MapItem?
There is inconsistency here, but I don't know how to resolve it
without renaming existing interfaces and classes which we don't want
to do.
> Also I am not sure we need a special Info object. A simple
> Map<String, String> attached to a MappingObject should be enough
> from what I see.
That's possible, but I'm thinking there might be some additional logic
which could belong here. For instance, if we reserve some keys
"javadoc", "annotation" to have special application then we can
control their use here. And there may also be another attribute in the
future to prevent some Info objects being passed from server to client
in ROP.
Also, currently there is no typing (all values are String). But there
is the future possibility of creating typed values which give the user
greater validation when entering data in the Modeler.
> The current Info object has a notion of a parent. Could you
> elaborate why is it a tree structure?
That might be poor naming. parent is actually the CayenneMapItem that
the Info is attached to. We'll rename it.
> "Info" name is a bit confusing, at least to a Java programmer (I
> know it was used in EOF). Everywhere else in Cayenne a similar
> unstructured String data attached to an object is called "property".
> I suggest we stick with this naming convention.
Fair enough. How about MapEntryProperty?
Ari Maniatis
-------------------------->
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
Re: [jira] Updated: (CAY-400) Support for user properties of DataMap objects.
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 1, 2009, at 8:50 AM, Aristedes Maniatis wrote:
> Jack is an intern at ish who has been working on this task. We
> discussed the basic design strategy and class structure, and Jack
> has put together some code.
Great! Jack, welcome to the community :-)
> We'd like some feedback about the approach, especially the idea of
> superclassing the CayenneMapItems to allow for the code to live in
> one place.
I am ok with a common superclass of mapping objects. I don't like the
CayenneMapItem name though. We have no current notion of "CayenneMap",
so "CayenneMapItem" is confusing (not that I am happy with the name
DataMap, heh :-)). Maybe something like MappingObject, which feels
more generic along the lines of "Object Relational Mapping"?
Also I am not sure we need a special Info object. A simple Map<String,
String> attached to a MappingObject should be enough from what I see.
The current Info object has a notion of a parent. Could you elaborate
why is it a tree structure?
"Info" name is a bit confusing, at least to a Java programmer (I know
it was used in EOF). Everywhere else in Cayenne a similar unstructured
String data attached to an object is called "property". I suggest we
stick with this naming convention.
Andrus