I'm using Cairngorm 2.1 here so I don't think it's something that
changed in the newest version.. :(
Your idea of the UID sounds like it will work but I'd prefer not send
extra data back and forth and it also won't clean up these redundant
event notifications.. It seems that cairngorm creates new instances
of the delegate/event listeners etc every time, maybe there is a way
to find a unique reference for them that you can use to filter out
the extra events? but I guess that still creates a memory problem and
the application will get slow after a while, something that would
easily happen in a chatroom application for example.. question is:
how does someone kill these event listeners with cairngorm?
Thijs
Op 16-jan-2007, om 20:08 heeft Battershall, Jeff het volgende
geschreven:
Well using mx.utils.UIDUtil.createUID() to give each RO call a
unique marker and then checking for a match on result is a way to
go, biut it certainly feels kludgey. I'd like to see some input
from the Adobe consulting folks - perhaps this has been addressed
in Cairngorm 2.1 - I'm using 2.0.
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Doberenz
Sent: Tuesday, January 16, 2007 1:54 PM
To: [email protected]
Subject: Re: [flexcoders] Cairngorm Duplicate Remote Object Return
Events
You're right, I was just calling them duplicate events, but
repeated ones from earlier events is a much better way to say it.
I'm coding up a Fluorine app for the middleware... I'm not all that
sure how to use CF :(
I'm basing my Flex app off of Sam Shrefler's Flex 2, Cairngorm,
Fluorine tutorial:
http://blog.shrefler.net/?p=10
Maybe his code needs to be tweaked for Flex 2.0.1 ??
Mark
On 1/16/07, Battershall, Jeff <[EMAIL PROTECTED]> wrote:
Mark,
Interesting discussion - interesting problem. BTW, I don't think
these return events are really 'duplicates' per se, but repeats of
the earlier return events. LIke
First invoke
returns event1
Second invoke
returns event1 then event2
etc.
Out of curiosity, what middleware are you using? I'm using CFMX 7.02.
Jeff
-----Original Message-----
From: [email protected] [mailto:
[EMAIL PROTECTED] On Behalf Of Mark Doberenz
Sent: Tuesday, January 16, 2007 11:50 AM
To: [email protected]
Subject: Re: [flexcoders] Cairngorm Duplicate Remote Object Return
Events
OK, so maybe having a Singleton delegate wouldn't be a good idea.
Here's a bit more I've found on the topic.
I put a breakpoint at the Command result method and found that the
address location for the commands were changing. So, essentially,
the commands are being persisted which in turn are persisting new
instances of the delegate and the event listeners that are a part
of those delegates. Removing the event listener in the delegate
first won't work because the memory locations of the responder (the
command) are changing.
Essentially, every time you create a new cairngorm event, you will
create new instances of the delegate and then the event listeners,
so the same result will fire the event listeners multiple times
when you've created multiple cairngorm events.
That's at least my take on the issue.
I have an app where I'm trying to perform a LoginEvent and I
noticed that every time I hit the Login button, I was creating a
new LoginEvent and so the more I tried to login, the more results I
was getting back. I tried making the LoginEvent a private var on
the view, and that seemed to work the first time, but after that it
wasn't passing the user data anymore. Not sure what that's about.
I don't like this fix because it would mean that there's only one
instance of each of the cairngorm events in the whole app.
On 1/16/07, Battershall, Jeff <[EMAIL PROTECTED] > wrote:
I'm not sure a singleton delegate would do the trick - and then you
might have threading issues - right? I'm kind of suspicious of the
fact that the RO instances are being persisted in the singleton
ServiceLocator. It's those RO instances' methods that are getting
listeners attached to them.
I'm going to try a couple of things - one is to explictly remove
the event listener when the result comes over the wire. I've
determined this - the remote object is invoked only once outgoing
from Flex. It is the duplicate result events that are happening.
One way to work around this would be to add a unique token to the
rpc call as described in the Flex docs (search ACT in the Flex Dev
guide) and only execute your return code when the token matches the
one coming over the wire. I'm going to experiment with that as
well. I think this may well be some sort of scoping issue caused
by the level of abstraction that the Cairngorm framework stipulates.
-----Original Message-----
From: [email protected] [mailto:
[EMAIL PROTECTED] On Behalf Of Mark Doberenz
Sent: Monday, January 15, 2007 10:31 PM
To: [email protected]
Subject: Re: [flexcoders] Cairngorm Duplicate Remote Object Return
Events
I was seeing this same thing today with some stuff I was working
on. I hadn't spent any time trying to remove the event listeners
before adding them again though. So, I don't know if that would
work, but apparently not.
I wonder if the delegate should actually be set up as a Singleton
so that multiple instances of the delegate weren't floating around
cathing the events every time. This way, you could guarantee that
only one instance was being used. Just a thought.
I don't have the code in front of me, but if you're
reinstanciating the delegate every time the command is called, then
this could explain it.
Try setting a breakpoint in your delegate and look at the memory
address for "this" and see if it's changing each time the
delegate's called.
.
