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 > <webobjects-dev@lists.apple.com> wrote: > > P.S. > >> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> 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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com > > This email sent to hill.ch...@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com