tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/12-listening-for-events-on-specific-instancesRobotlegs: Discussion 2018-10-18T16:35:06Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-11-26T14:02:35Z2009-11-26T14:02:35ZListening for events on specific instances. <div><p>Depending on where you want to listen to these events, a third
way<br>
might be to inject the collections and directly add listeners to
them<br>
instead of the shared eventDispatcher.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-11-26T16:33:14Z2009-11-26T16:33:14ZListening for events on specific instances. <div><p>Well, it depends on your design. You mention that you have "two
very similar collections": are they managed by two instances of the
same Model Actor? Might the list grow from 2 to N?</p>
<p>If I need to manage two list that are similar, but represent two
distinct parts of the application state, I would have two different
Model classes - each would dispatch a different concrete Event. But
that would only be suitable for certain designs.</p>
<p>It would be good to get a little more info about what you are
wanting to achieve.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-11-26T18:59:46Z2009-11-26T18:59:46ZListening for events on specific instances. <div><p>@tschneidereit: that also feels like sort of a hack, but it's
definitively an option!</p>
<p>@shaun: They are managed by two subclasses to a more generic
collection class, but that's really just to avoid naming the
injections and have more flexibility in changing the specific
methods, it might as well just be two instances of the same
class.</p>
<p>In this specific instance I am making a greenscreen keying
application (using air), so one collection is the "raw" images and
the other is the already keyed ones. So, two distinct collections
on which I need to do different things, but really the same type of
data.</p>
<p>And regarding list size; right now it's actually capped at
twenty or so images per list just to keep things nice and fast.
This might change depending on different requirements, but
realistically never more than a couple of hundred.<br>
Worth noting is that I do not keep all the full images in memory,
just thumbnails. I'm not crazy ;)</p></div>grapefrukttag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-11-27T11:06:32Z2009-11-27T11:06:32ZListening for events on specific instances. <div><p>Aha! I wasn't so much interested in the number of items as the
number of collections. It seems to me like you'd need two model
actors:</p>
<p>RawImagesModel and KeyedImagesModel</p>
<p>Each model would manage access to it's underlying collection,
and each would dispatch different events:</p>
<p>RawImagesModelEvent and KeyedImagesModelEvent</p>
<p>Even though the wrapped collection classes might be the same,
the models represent two distinct areas of application state.</p>
<p>As opposed to overriding the collections themselves (as you
mentioned above) the models simply wrap the collections, expose an
API to the system, and translate collection events
(ImagesCollectionEvent.ITEM_ADDED) into system events
(KeyedImagesModelEvent.ITEM_ADDED).</p>
<p>Other parts of your system would then listen to the event bus
for the appropriate concrete events. Be sure to use strong event
typing when listening for these events if any of the string types
overlap.</p>
<p>Does that help at all?</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-11-27T13:40:10Z2009-11-27T13:40:10ZListening for events on specific instances. <div><p>That is what I sort of expected I would have to do. I can see
how it's clearly the most robust way, I was just a bit hesitant
towards it because I felt I would be duplicating functionality.</p>
<p>I'm just worried that it's a bit boilerplate'y to need different
events just to be able to tell where they came from when they're
more or less the same implementation wise.</p>
<p>Would an option to listen for events dispatched by a specific
instance be something that could be considered as an addition to
the framework or do you think that will go too much against the
overarching architecture?</p></div>grapefrukttag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-12-07T14:43:06Z2009-12-07T14:43:06ZListening for events on specific instances. <div><p>Hi Grapefrukt,</p>
<p>I'm having a little trouble understanding your last question
(regarding an addition to the framework to listen for events
dispatched by specific instances), could you expand on that?</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372009-12-10T18:29:20Z2009-12-10T18:29:23ZListening for events on specific instances. <div><p>I believe grapefrukt is trying to determine which model is
responsible for dispatching the event, so he can retrieve the data
from that model. He is trying to avoid having two similar yet
different events such as "KEYEDDATA_READY" and "RAWDATA_READY". He
would prefer to just dispatch "DATA_READY" and be able to grab the
data from the responsible model. He's thinking of having multiple
instances of the event dispatcher.</p>
<p>What I would do is have a third model being a collection of both
keyed and raw data. When a model wants to make a data object
available it will send that data to the third model. Whenever the
third model receives new data it will dispatch an event of
"DATA_READY." Whatever is listening to that third model can then go
and retrieve the new data no matter if it's "raw" or "keyed". You
can add a "type" property to your data object so you determine it's
origin ("raw" or "keyed").</p></div>redblindtag:robotlegs.tenderapp.com,2009-10-18:Comment/6390372010-01-14T17:03:57Z2010-01-14T18:56:53ZListening for events on specific instances. <div><p>Here's an idea though. Use namespace suffixing. Here's how you
can go about it:</p>
<p>Let's say IXMLAssetModel extends from a base interface/class
called IAssetModel/AssetModel. IAssetModel can provide the
following getter for easy reference:</p>
<p>function get namespaceSuffix():String;</p>
<p>For a Gaia asset node in the Gaia Flash Framework, for example,
you could define a unique namespaceSuffix for each AssetModel (with
a Gaia asset IAsset supplied to the AssetModel as a data
dependency) from which a unique event string is dispatched by
default from that model (ie. AssetEvent.SOME_EVENT_CONSTANT +
namespaceSuffix).<br>
eg.<br>
<code><asset id="thumbnails" type="xmlRequestAsset"
src="someURLThatReturnsXML.php" namespaceSuffix="gallery"
model="com.blahblah.AssetModel"></code></p>
<p>Then, you could manually map a framework event type of
AssetEvent.ASSET_COMPLETE + thumbnailModel.namespaceSuffix to
ensure a specific mediator only listen for notifications restricted
to the "gallery" namespace within the framework, taking reference
from the thumbnailModel's supplied namespaceSuffix value. Another
way is to possibly read from the id of the AssetModel class and use
that as the suffix. It all depends on your needs, whether the
mediator just need to listen to a single asset, or to listen to a
bunch of assets that belong to some particular namespace.</p>
<p>Namespace suffixing for dispatched events might seem a bit
messy, but it should work with minimal need to write duplicate code
or unnecessary checks to filter off non-applicable mediators. Why
hog performance by dispatching a site-wide event that only a few
members within a specific context will respond to it? The solution,
just add a namespace suffix to the event, so only the intended
recipients will handle those.</p></div>glidias