Home → Questions →

Listening to modifications versus requesting state updates

Maciek

22 Sep, 2011 07:11 PM via web

Admin Functions

• Edit
• Remove

I'm working with a very dynamic system, where mediators are added/removed rather frequently. When a mediator needs to deal with a list of objects (say, a list of Contacts (first, last, e-mail)), it seems that there are two ways to approach this. The first (assuming you don't particularly care about the ordering):

[Inject] public var onAdded:ContactAddedSignal;
[Inject] public var onRemoved:ContactRemovedSignal;
[PostConstruct]
public function initialize():void {
    onAdded.add(handleAdded);
    onRemoved.add(handleRemoved); 
}

The problem with this is that if the mediator has not been created by the time a Contact is added, the mediator will miss it entirely. Another solution is to just have something like this:

[Inject] public var listState:ListStateSignal;
[PostConstruct]
public function initialize():void {
    listState.add(handleListState);
}

Unfortunately, this puts a lot of burden on the mediator: it needs to go through the whole list each time, and see which contacts have been massaged for the view already, which (if any) are new, and which (if any) have been removed.

Is there a best practice around dealing with something like this? Is it to have both signals, use addOnce() for the list state signal, and thereafter only deal in the change signals?

1. Support Staff 2 Posted by Joel Hooks on 22 Sep, 2011 07:36 PM

   

   I would put the the contacts in models that describe current state:

   MassagedContactsModel
   ContactListModel
   SelectedContactModel

   The mediator can query the model in onRegister, as well as adding listeners for "live" updates.

   If I am understanding the problem correctly. How/what the models were named would be something you'd be able to suss out better.

   Admin Functions

   • Edit
   • Remove

2. 3 Posted by Maciek on 22 Sep, 2011 08:33 PM

   

   You mean injecting the model directly into the mediator? I was hoping to avoid that (i.e., have mediators only depend on signals), although that may be more trouble than it's worth.

   Admin Functions

   • Edit
   • Split
   • Remove

3. 4 Posted by Maciek on 23 Sep, 2011 06:20 PM

   

   I've been thinking about this some more, and avoiding injecting Models into Mediators is probably of little benefit, as long as you present the Model to the Mediator only via a read-only interface.

   The big RL raison d'être is decoupling, and the difference in coupling between depending on

   interface IContactList {
       get contacts():ArrayCollection;
   }
   

   and

   class ListContactsSignal {
       function ListContactsSignal() { super(ArrayCollection); }
   }
   

   is minimal, and in fact, in favor of the interface, since the compiler can't type-check the signal argument (okay, bad example, since without generics or a custom wrapper class, the type check for ArrayCollection isn't worth much, but the principle still applies).

   Of course, the danger is that if your Model becomes more complex, you don't want the Mediator to depend on an interface which defines methods that it doesn't care about, and you don't really want your model implementing a dozen different interfaces to cater to everyone.

   In practice, I imagine this is not a terribly serious concern, since individual Models should be relatively small (at least I've found that to be the best separation of concerns in my code).

   Note that this doesn't apply to added/removed signals (just bootstrapping as Joel suggested), since the alternative is manually adding listeners to the model to check for change to the bound properties, which would be harder to manage and more awkward.

   Any thoughts?

   Admin Functions

   • Edit
   • Split
   • Remove

4. Ondina D.F. closed this discussion on 23 Dec, 2011 08:52 AM.

Comments are currently closed for this discussion. You can start a new one.