Re: [GDL2] EODetailDataSource and EODisplayGroup

[Dirk Lattermann]

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 <d.ayers@inode.at> 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