Hi Mark, >>So we have to change this to first get the current Manager and then get the NotificationManager from there. I think same.
Gurkan 2009/4/26 Mark Struberg <[email protected]> > > 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 > > > > > > > > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
