Hi There.
Sorry, I was not clear. All I wanted was for the line to come out
like this:
private Relationship _relationship;
i.e. without the package name, so classNameWithoutPackage suits my
needs fine.
Totally off this topic, I don't use EOGeneric record because I like
to have both accessors that begin with underscores and accessors that
do not begin with accessors. That way, I know whether it's the
framework stuffing values into my EOs versus my code (i.e. use
action) changing an EO. If you use EOGenericRecord and
takeStoredValueForKey, you cannot achieve this. You get infinite
recursion calling your _ method.
As an example, these are my typical attribute accessors:
private NSTimestamp _createdDate;
public NSTimestamp _createdDate() {willRead(); return
_createdDate;}
public void _setCreatedDate(NSTimestamp value) {willChange();
_createdDate = value;}
public NSTimestamp createdDate() {willRead(); return _createdDate;}
public void setCreatedDate(NSTimestamp value) {willUpdate();
_createdDate = value;}
Am I wrong? Is there a way to achieve this and still use
EOGenericRecord?
Thanks!
-Kenny
On Jan 28, 2008, at 10:47 AM, Mike Schrag wrote:
>> My to-one relationship declarations are currently coming out like:
>>
>> private com.hexdreams.framework.model.Relationship _relationship;
>>
>> with a template like
>>
>> private ${relationship.actualDestination.classNameWithDefault} _
>> ${relationship.name};
>>
>> which I copied from the example method declaration for to-one
>> relationships. I thought I could just make it:
>>
>> private ${relationship.actualDestination.javaClassName} _$
>> {relationship.name};
> Not sure I follow what the problem is here, but what I'm seeing
> appears correct. Exactly what output are you trying to produce? It
> looks like you're creating ivars for relationships in your model
> classes, which is definitely a bit on the odd side. You probably DO
> want classNameWithDefault here (generally), to support when your
> relationships are to entities of EOGenericRecord type. If your
> complaint is that it's fully qualified, consider that your classes
> may cross packages (very commonly, actually), so the general case
> is that you want fully qualified class names. If you know you will
> never cross model boundaries (again, you will :) typically you're
> join to an entity from a model from another framework, which would
> cause this) then you can use classNameWithoutPackage.
>
> ms
>
This archive was generated by hypermail 2.0.0 : Mon Jan 28 2008 - 13:58:30 EST