Hmm, got stuck again and have to go offline too now. The problem I spot now is in the DefinitionUtil#defineObserverMethods line 1077:
> NotificationManager manager = NotificationManager.getInstance(); So we have to change this to first get the current Manager and then get the NotificationManager from there. I will be online again in the evening ~20:00 CEST. LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Sa, 25.4.2009: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: ChildActivityManager problems > An: [email protected] > Datum: Samstag, 25. April 2009, 21:05 > Hi Mark; > > I understand from the spec is that child managers can > access to the parent's bean and observer instances but not > its siblings. So we have to separate their > NotificationManagers via "new" keyword. Because, > NotificationManager class has some instance variables that > hold managers observer instances. > > But as for InjectionResolver, it does not define any > instance variables and its sole purpose is to find > components using the Manager. So it is not necessary to > create new InjectionResolvers for child managers. > > Thanks; > > Gurkan > > > > > ________________________________ > From: Mark Struberg <[email protected]> > To: [email protected] > Sent: Saturday, April 25, 2009 2:59:56 PM > Subject: ChildActivityManager problems > > > Hi folks, need your help :) > > I'm not sure if my implementation of the > ChildActivityManager leads into the right direction, so I > need a bit reflection about this! > > The basic idea behind the creation of child activities is > to form a 'tree' of Manager instances where every > child Manager derives information from the parent Manager, > but isolates it's own specialities from it's parent. > > The implementation trick behind the ChildActivityManager > was to keep references 2 a freshly generated ManagerImpl > (self) and to the parent Manager, and then doe some kind of > 'conditional' delegation pattern. > > What I didn't thought off was the fact that ManagerImpl > currently has notificationManager and injectionResolver not > via new() but as singletons. > > injectionResolver = InjectionResolver.getInstance(); > notificationManager = NotificationManager.getInstance(); > > which means that we currently have no chance to isolate > information between child and parent Mangers, isn't? > > Imho ManagerImpl itself is a singleton, so it should be no > problem to change this to 'new InjectionResolver()' and 'new > NotificationManager()', but I'd like to have your ok before > I change this very basic parts! > > txs and LieGrue, > strub > > >
