Thank you, David, for your explanation, but unfortunately they do not help me much. I will try to explain what I want to do.
I intend to programmatically create a display group for a detail data source. Until now in my test setups of EOInterface, I created all the interface elements (or have them awake from nib), then I created the data sources and display groups and connected everything together via associations. Then, before the user gets control, I told the data source(s) to fetch their data. Obviously, this isn't the way to go because the detail data sources get their editing context only after fetching data in their master data source, which qualifies the detail data source via an EOMasterDetailAssociation. But how can I proceed if I don't want to fetch before the UI is set up (e.g., if the user should be able to restrict the query before starting it)? Even with an implementation of EOInterface that supported putting display groups, associations (and data sources) into a nib file, wouldn't this work only if fetchesOnLoad of the display group is set? Or, when modelling everything in IB (I guess the detail data sources where created when dragging an EOMasterDetailAssociation from the palette and connecting it to the two display groups?), did IB fetch objects and qualify the detail data source before setting up the display group? There is a similar problem related to the last column display group implicitly created by EORecursiveBrowser which I'm implementing, but I fear my writing here is already confusing enough... David Ayers <[EMAIL PROTECTED]> schrieb am 18.03.2005, 12:49:20: > Dirk Lattermann wrote: > > Is it safe to assume that a data source will never > > "switch editing contexts"? > > Hello Dirk, > > I would believe so. The abstract class only declares the > -editingContext method and the concrete EODatabaseDatasource is > initialized with an editing context and has no manipulation methods. What about creating an EODetailDataSource with its designated initializer initWithMasterClassDescription:detailKey: and subsequently qualifying it with objects in different editing contexts? Such a data source wouldn't be usable with an EODisplayGroup, I think, but this might be considered a very pathological case. > If you look at the documentation for EODetailDataSource's > -editingContext method: > http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Library/Frameworks/EOControl.framework/ObjC_classic/Classes/EODetailDataSource.html#//apple_ref/occ/instm/EODetailDataSource/editingContext > > It seems pretty clear to me that the master object has to be set for the > detail datasource to have access to it's editing context. > Yes, this is (fortunately!) clear from the docs, but it makes me wonder how and when the display group for this detail datasource is registered as an observer of the objectsChangedInEditingContextNotification. > Hope this helps, otherwise you'll need to explain your problem a bit > more in detail. I hope I did! Thanks, Dirk _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
