|
From: | David Ayers |
Subject: | Re: [Renaissance]platform objects' awakening |
Date: | Thu, 17 Jul 2003 16:57:06 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 |
Dirk Lattermann wrote:
Hello Nicola! Thanks for your instant help! I'm making some promising advances with the EOAssociation connector. Binding a text field to a database via an EOControlAssociation is working here now!
Wow! Great news!
How about adding a category to EODisplayGroup in the library to be that implementsI haven't factored out the new classes into a seperate library, but will do it after I have implemented some more. When trying to make EODisplayGroups available to Renaissance, too, I stumbled over the following: EODisplayGroups have an property fetchesOnLoad which, when set to YES, tells them to issue a fetch to their EODataSources after they have loaded from a nib (resulting in a fetch from the database). In Mulle's implementation of EOInterface, this is done in -[EODisplayGroup awakeFromNib], I don't know where it's done in Apple's version. To be able to use this feature, I suggest the following patch to GSMarkupAwaker.m. That way, the platform object can be a real EODisplayGroup and not a subclass which implements -awakeFromGSMarkup. Yet I don't know if that would harm some other platform objects.
@implementation EODisplayGroup (Renaissance) - (void)awakeFromGSMarkup { [self awakeFromNib]; } @endThat way, if we ever need to fo something special for GSMarkup, we can just alter this implementation accordingly. I don't know what the side effects of allways falling back to awakeFromNib within GSMarkupAwaker may be, but it feels dangerous.
Thanks for your effort! I hope to have that EOEditingContext patch ready soon, to fix that bug, but it's quite intricate and I need to fill a lot of holes.
Cheers, David
[Prev in Thread] | Current Thread | [Next in Thread] |