Support Staff2 Posted by Shaun Smith on 02 Jul, 2012 10:51 PM
Yup, the filterFunction is keeping the command instance pinned
in memory - normal Flash Player GC stuff. Robotlegs releases all
internal references to commands after execution, but can't do
anything about references that it didn't create.
Personally, I don't mind the actual mechanics involved in your
setup - but I would move that stuff out of the command and into an
explicit persistent construct (like a service). Commands are
supposed to be fire-and-forget, and the fact that this particular
command persists is not being made clear. It doesn't reveal its
Thanks for the reply, Shaun! That does clear things up.
I've struggled with the best place for locating the
filterFunction, since it needs to reference multiple
(data-selection) Models, and its complex churning feels like
business logic. That's why I initially went with Command; but I
agree that the lack of clarity on its quirky persistence is not
ideal. And I suppose injecting the (data-selection) Models into the
Service is preferable to injecting them into the data-storage Model
As to getting a M's ArrayCollection to update in a V: after a
one-time initialization of the V's instance by passing it in
through the VM, is it normal/expected to see it automatically
update, simply by calling refesh() on the M's ArrayCollection? I
had thought I would have to explicitly pass it down (M to VM to V)
on every update - but I'm seeing it happen without that effort.
Again, I'm assuming this is because I initialized the V's instance
with a reference to the M's instance; but I didn't know if this
kind of "implicit update by reference" was considered
loosely-coupled best-practice for a RL architecture.
So I may have answered my own questions (but I'd be interested
to hear if you have different design opinions):
I located the complex filterFunction (that needs multiple
injected Models) in a separate FilterFunctionService, injected
that Service into my data-retrieval Service, and then
called its setFilterFunction(myArrayCollectyion) method. So it now
persists in a RL-expected way (in a Service). It is somewhat
unusual (I think?) to inject a Service into a Service; but it
seemed sensible for this purpose, and also has the advantage of
being reusable by other data-retrieval Services in the app.
As to getting a M's ArrayCollection to update in a V, I have the
VM listen for a "model initialized" event, and do a one-time
setting of V.dataSource = M.dataSource. Updates then automatically
happen whenever I call M.dataSource.refresh(), and I can optionally
have the VM listen for a "model refreshed" event if I need to
invoke any additional view-specific refreshing.
Thanks again for the assistance! Again, really loving working
with the framework (and hoping it helps us extend the viability of
Flash/Flex in the enterprise against the tidal wave of HTML5).