Home → Problems →

Large number of Signals/Commands/Mediators/Views

• Edit

Columbus

12 Mar, 2012 02:18 PM

Hello all,
I am new to MVC and new to Robotlegs. As a series of choices that we made for the technology of choice for our project, I ended up attempting to list the elements (signals, commands, views, etc.) that I would need for all possible user-interfaces and options. Now this project is a large one - and going by some of the examples prescribed, I ended up with about a thousand signals, commands, To give an example, here are 4 signals that I think I need:

MemberAddSignal (to add a new member)
MemberAddedSignal (triggered once service successfully adds a member)
MemberUpdateSignal (to update a member information)
MemberUpdatedSignal (triggered once service successfully updates the member)
MemberDeleteSignal
MemberDeletedSignal
MemberDownloadSignal (to download all members into the datagrid)

Let me know if you need me to go into more details about the commands, models, and so on. I have 140 elements similar to the 'Member' in the signals listed above - each with their own set of signals, commands and so on.

At this scale, on a prototype project that I am attempting using Flash builder, I run into 'Java Heap Space' issues that cause the build to be interrupted. I am not 100% sure that the heap space issue is as a result of the number of signals, commands, etc that I have - but it does appear to be the case.

Anyway, I would appreciate it very much if you can point me in the right direction. Should I just throw more memory at my Flash builder and continue on my path? Is there any optimization possible that I can use? May be reuse signals, or have signal properties for add/delete/update action instead of separate signals? I am not sure.

c

1. 1 Posted by matt on 12 Mar, 2012 02:39 PM

   

   sounds like good old fashioned events might be a better fit - ElementEvent with a type property ( ElementEvent.ADD, ElementEvent.ADDED etc) and an elementType property ( Member, or any of your other 140 types!) - after running into similar conundrums with purely signal based projects getting out of hand with the sheer volume of singleton instances of signal types and injections i went back to mainly using events for this type of thing, signals still great for the view/mediator layer though.

   • Edit

2. 2 Posted by Stray on 12 Mar, 2012 02:51 PM

   

   Hi there,

   As you indicated, the usual fix for the Java Heap Space issue is to allow Flash Builder to use more memory:

   http://technophi.com/2010/08/12/flash-builder-4-java-heap-space-issues/

   On the subject of re-use, on my similar project (a complicated content management / account maintenance system) I've found ways to use the same signal for all data types in many cases, and pass the data class as an argument upon which the centralised data services then choose what to do next. So - messages coming back from the data service (which is a module) are always specifically typed (member / account / content etc) but the requests from the specific editing screens to the data service are generic.

   That helps to keep the complexity down I find.

   In your case - MemberAdd / MemberUpdate / MemberDelete would all become generic Add / Update / Delete requests - usually with 2 arguments - the class of data, and the actual data payload. That pretty much halves the number of unique Signals, and you don't lose any type safety because the argument checking on signals is only runtime based anyway, and doing the check (payload is payloadClass) is a virtually free check in the triggered command (the 'is' operator is extremely efficient).

   Rob Penner's team at Club Penguin came up with the idea of SignalKeyChains - they grouped together Signals as properties of "KeyChain" objects to reduce the number of individually injected objects - so that's another option. (Not necessarily better or worse, just an alternative approach).

   A benefit of the 'keyChain' approach is that you can quite cheaply add compile-time type safety for dispatching - by wrapping the dispatches (which each expect the same type of payload) like this:

   public function dispatchSignal(signal:Signal, memberData:MemberVO):void
   {
   signal.dispatch(memberData);
   }

   which you would then use like this...

   memberDataSignals.dispatchSignal(memberDataSignals.added, someMemberData);

   Whether that's a more or less useful approach for you, only you can tell (and maybe then only later!),

   hth,

   Stray

   • Edit

3. 3 Posted by Stray on 12 Mar, 2012 02:54 PM

   

   Just to add - I'm with Matt on this. I use Events for my data, and only use Signals for view->mediator comms and specific situations where I want to hook up a 1-to-1 relationship between the request and the response.

   Stray

   • Edit

4. 4 Posted by Abel de Beer on 13 Mar, 2012 09:03 AM

   

   (offtopic)

   Hi Stray, do you have a link to more on Penner's SignalKeyChains? If not, would you care to elaborate? Are they just simple objects with a set of Signals as properties? Thanks!

   • Edit

5. 5 Posted by Columbus on 13 Mar, 2012 04:58 PM

   

   Matt, Stray,

   Thanks for the amazingly fast responses, I will go with Matt's suggestion - using events for the data side of things and signals for the view-mediator interaction.

   c

   • Edit

6. Ondina D.F. closed this discussion on 19 Mar, 2012 08:42 AM.