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: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Doberenz
Sent: Tuesday, January 16, 2007 1:54 PM
To: flexcoders@yahoogroups.com
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: flexcoders@yahoogroups.com [mailto:
flexcoders@ <mailto:flexcoders@> yahoogroups.com] On Behalf Of Mark
Doberenz
Sent: Tuesday, January 16, 2007 11:50 AM
To: flexcoders@yahoogroups.com
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: flexcoders@yahoogroups.com
[mailto: flexcoders@ <mailto:flexcoders@> yahoogroups.com] On Behalf Of
Mark Doberenz
Sent: Monday, January 15, 2007 10:31 PM
To: flexcoders@yahoogroups.com
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.
On 1/15/07, Battershall, Jeff <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >
wrote:
This is a tough one - and I'm getting a
similar behavior with fileupload - duplicate completion events in
subsequent calls to the same Event/Command/Delegate. I'm having to parse
out the duplicates on the client side and I've yet to determine the
culprit. You'd think that there's a new instance of each Event,
Command and Delegate classes responding to each gesture, but somehow
something is getting persisted and producing a ghosting effect after the
first call to the same class. The remote object instances in
ServiceLocator are getting persisted, that's for sure, and I don't know
if that has anything to do with it.
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] ups.com
<http://ups.com/> [mailto: flexcoders@ <mailto:flexcoders@>
yahoogroups.com] On Behalf Of Thijs Triemstra
Sent: Monday, January 15, 2007 4:04 PM
To: flexcoders@yahoogroups.com
<http://ups.com/>
Subject: Re: [flexcoders] Cairngorm
Duplicate Remote Object Return Events
I'm having the same problem with
NetConnection and Cairngorm, it triggers more and more NetStatus events
everytime I reconnect to the server. The server doesn't show any
reconnects so it's a clientside thing but not sure why.. I also tried
removing the listeners but nothing changed.
Thijs
Op 15-jan-2007, om 19:01 heeft Martin
Wood-Mitrovski het volgende geschreven:
> One theory I have about what 'might'
be happening is that before I make
> my servce call, I'm adding event
listeners for the result/fault and
> these may be duplicate ones, because
the remote object instance is being
> persisted in ServiceLocator. However,
I tried explictly removing the
> listeners before adding them and no
dice.
sounds like the most likely thing to be
happening.
try setting a breakpoint on where you
remove / add the listeners and check that
the references are the ones you expect,
i.e. you are not trying to remove a
different listener or something.
