tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/1457-placing-sound-manager-in-mvcRobotlegs: Discussion 2012-12-11T12:55:30Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/225020332012-12-11T11:28:53Z2012-12-11T11:28:53ZPlacing sound manager in MVC<div><p>Hi Vishwas,</p>
<p>There are 2 questions you’re asking:<br>
1-How to mediate a non-visual element?<br>
2-What is a SoundManager? A View, a Model, or a Service?</p>
<p>1-If your SoundManger is not a visual element and you want to
mediate it, you can do this:</p>
<p>mediatorMap.mapView(SomeSoundManager,
SomeSoundManagerMediator);<br>
var someSoundManager:SomeSoundManager= new SomeSoundManager();<br>
or<br>
//var someSoundManager:SomeSound=
injector.instantiate(SomeSoundManager);
mediatorMap.createMediator(someSoundManager);</p>
<p>But, in this case, if you wanted to dispatch events from
SoundManger to SoundManagerMediator, you’d have to let
SoundManger extend EventDispatcher. And, you’d have to remove
the mediator manually, if need be.</p>
<p>2-If we wanted to follow MVCS strictly, then the loading of
sounds should be performed by a Service, and the controlling of
sounds– play, pause, rewind, stop, etc – would be
certainly View logic. But, maybe your application would not benefit
too much from forcing this separation of concerns on a media
player, so having a SoundManager loading <strong>and</strong>
controlling the sounds in a View might be an acceptable compromise.
In this case, where you also have components for controlling the
sound, thus user interaction, you’d better have a SoundManger
extending a display object container, and the mediator, as you well
know, would be created/removed automatically.</p>
<p>On the other hand, a SoundManger (or SoundController or whatever
name you give it) isn’t always interactive, meaning the user
has no control over the playing, stopping of sounds. Maybe the
sound data is generated dynamically, and in this case having a View
with a Mediator might not be the best solution, or just too
complicated. Perhaps all you need is a class that can communicate
with the rest of the application, thus have a shared event
dispatcher injected, or extending Actor. Also, look at this
discussion: <a href=
"http://knowledge.robotlegs.org/discussions/questions/664-mediating-a-non-displayobject">
http://knowledge.robotlegs.org/discussions/questions/664-mediating-...</a></p>
<p>In my opinion, whether a SoundManager should be treated like a
View or not, depends on the specific project, and in the end all
that matters is that it is well encapsulated and reusable.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/225020332012-12-11T12:47:38Z2012-12-11T12:47:38ZPlacing sound manager in MVC<div><p>Thanks, for the quick response.<br>
Your post in reply is very helpful and informative. :)</p></div>vishwas.gagrani