We handle such things automatically with custom template files for
EOGenerator.
Put this into your template:
// Constants for all attributes and relationships
<$foreach attribute classAttributes..eversedArray do$>
public static final String ATTRIBUTE_<$attribute.name$> =
"<$attribute.name$>";<$endforeach
do$>
<$foreach ToOneRelationship classToOneRelationships..eversedArray do$>
public static final String TO_ONE_<$ToOneRelationship.name$> =
"<$ToOneRelationship.name$>";<$endforeach
do$>
<$foreach ToManyRelationship classToManyRelationships..eversedArray
do$>
public static final String TO_MANY_<$ToManyRelationship.name$> =
"<$ToManyRelationship.name$>";<$endforeach
do$>
You then use this in your code like
removeObjectFromBothSidesOfRelationshipWithKey(parent(), TO_ONE_parent);
Have fun
---markus---
On 21.02.2005, at 12:10, Jean Pierre Malrieu wrote:
> You are probably right: costs would exceed benefits. And thanks for
> the idea of wrapping keys within an inteface.
>
> Now if I look at where I spend more debugging time, it is probably on
> missing or wrong keys. I would love to have a refactoring tools that
> would update source files and component .wod files whenever I change
> the name of an atribute in an EOModel.
> I guess this can't be done: key-value coding is here to free us from
> type rigidity, but it also forbids any checking before run time.
>
> JPM.
>
> Le 21 févr. 05, à 11:06, Anjo Krank a écrit :
>
>>
>> Am 21.02.2005 um 10:48 schrieb Jean Pierre Malrieu:
>>
>>> Eclipse is such a good IDE, and you guys who wrote WOLips are so
>>> clever that I am wondering whether it would be possible to enhance
>>> Eclipse code completion to include EOModel based information. For
>>> example, in functions like takeStoredValueForKey or
>>> addObjectToBothSidesOfRelationshipWithKey, or objectsForEntityNamed,
>>> I would appreciate to be proposed a set of keys. And if a key I use
>>> does not exist for a given entity, I would appreciate to be warned
>>> exactly the same way I am warned of java syntax errors.
>>
>> One could probably do this, but as you could also use key paths or
>> not call addFooToBar directly, it would probably be not so useful
>> anyway.
>>
>> Why not simply auto-generate an interface like:
>>
>> public interface MyEOModel {
>> public interface MyEntity {
>> public String someKey = "someKey";
>> public String someOtherKey = "someOtherKey";
>> }
>> }
>>
>> you could then import MyEOModel.MyEntity in your classes and let the
>> the code completion handle the rest (you'd use MyEntity.someKey
>> instead of "someKey").
>>
>> Cheers, Anjo
>>
>>
>
>
>
Markus Ruggiero
rucotec consulting and technologies email
mailto:marku..uggiero.ch
rucotec GmbH web
http://www.rucotec.ch
Steinentorstrasse 8
4051 Basel Mobile +41 (0)79 508
4701
Switzerland Phone/Fax +41 (0)61 271
4990
This archive was generated by hypermail 2.0.0 : Tue Feb 22 2005 - 11:06:17 EST