Re: More SharedEC woes: relationships into SEC not saved?!?
Re: More SharedEC woes: relationships into SEC not saved?!?
- Subject: Re: More SharedEC woes: relationships into SEC not saved?!?
- From: Chuck Hill via Webobjects-dev <email@hidden>
- Date: Sun, 12 Jan 2020 12:01:58 -0800
It only works for code that does _NSUtilities.classForName(). It only works
for code that defers knowing the class based on a string.
> On Jan 12, 2020, at 7:00 AM, OCsite via Webobjects-dev
> <email@hidden> wrote:
>
> P.S.
>
>> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev
>> <email@hidden <mailto:email@hidden>>
>> wrote:
>> As for the fixing... well, I guess I can generate the proper AOs myself, but
>> the trick is, how do I order them? I would need to reuse the standard
>> default ordering which EODatabaseContext does normally; but it does not seem
>> to be accessible anyhow, or am I overlooking something of importance here?
>
> It looks like
>
> ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
> ...
> class OCSDBOperation extends EODatabaseOperation { ... }
>
> does not work :( Do I do something wrong, or it simply can't be overridden?
>
> To be frank, I do not quite understand how the ERXPatcher (or, rather,
> _NSUtilities.setClassForName) magic actually works: should it work for any
> WO/EO class, or is there simply a dictionary somewhere inside the opaque
> Apple code, and it works only for classes which Apple explicitly addresses by
> some “Class clazz=dict[name]”, with no way to patch the others?
>
> Thanks!
> OC
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden