Hi Steven;

 

Although I risk being accused of hijacking this thread, I can suggest one change to Cairngorm:

 

com.adobe.cairngorm.control.FrontController

 

      private function executeCommand( event : CairngormEvent ) : void

      {

         var commandToInitialise : Class = getCommand( event.type );

         var commandToExecute : Command = new commandToInitialise();

 

         event.stopPropogation(); //                                     ß change is here

         commandToExecute.execute( event );

      }

 

In the case where application A dynamically loads application B into a separate application domain that is not a child of application A’s domain, the FrontController of application A will get events from application B. Since an event from application B cannot be coerced into the event class with the same name in application A, a run-time error will occur unless propagation of the event is halted in application B’s front controller.

 

I mention this now because I’m in the process of converting our Flex 2B3 application to Flex 2 (final) and am copying the change in FrontController.

 

Tobias.

 


From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Steven Webster
Sent: Monday, July 03, 2006 3:03 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Re: Cairngorm Responder interface changes

 

Jesse,

 

I'd love for you to share the modifications you're making to Cairngorm, and to understand the rationale behind these changes.  It's not our intention that developers would typically  need to change the framework locally, and doing so certainly makes it more difficult for folks to follow us on any upgrade paths as time rolls by.  Different strokes for different folks though.

 

But if you can share your motives for changes, and the changes themselves, then we can consider rolling them into the framework if they satisfy general concerns. 

 

Best,

 

Steven

 

Steven Webster
Practice Director (Rich Internet Applications)
Adobe Consulting
Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK
p: +44 (0) 131 338 6108

m: +44 (0) 7917 428 947 
[EMAIL PROTECTED]

 

 

 


From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of JesterXL
Sent: 03 July 2006 20:13
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: Cairngorm Responder interface changes

Don't have Flex 2 open in front of me ( client hearts 1.5 ), but you can I
think do:

public function onResult(event:* = null):void
{
ResultEvent(event).result
// or...
var yourEvent:ResultEvent = event as ResultEvent;
}

I can't remember if you can cast in the function signature as:

public function onResult ( event:* as ResultEvent = null )

...but, either way, you can also do what I do; keep your own build of
Cairngorm locally! I've yet to work on a project where the team didn't
modify their build of Cairngorm to suit their needs.

----- Original Message -----
From: "ben.clinkinbeard" <ben.clinkinbeard@gmail.com>
To: <[EMAIL PROTECTED]ups.com>
Sent: Monday, July 03, 2006 3:00 PM
Subject: [flexcoders] Re: Cairngorm Responder interface changes

Ah ha. Actually, I had to change them to

public function onResult(event:* = null):void
public function onFault(event:* = null):void

so that they matched the signature exactly. I guess my confusion was
in that I was viewing the :* as meaning the developer could specify
whatever type they wanted. I was seeing * as a kind of superclass when
that is in fact not the case. I have to agree with Jester; I don't
really see the point of this change.

Thanks for your help,
Ben

--- In [EMAIL PROTECTED]ups.com, "Clint Modien" <[EMAIL PROTECTED]> wrote:
>
> you need to change these lines
>
> public function onResult(event:ResultEvent):void
> public function onFault(event:FaultEvent):void
>
> to this...
>
> public function onResult(event:*):void
> public function onFault(event:*)void
>
> On 7/3/06, ben.clinkinbeard <ben.clinkinbeard@...> wrote:
> >
> > Can someone explain why it is telling me I've implemented the
> > Responder methods with an incompatible signature?
> >
> > public function onResult(event:ResultEvent):void
> > public function onFault(event:FaultEvent):void
> >
> > The signatures shown in the docs are
> >
> > public function onResult(event:* = null):void
> > public function onFault(event:* = null):void
> >
> > What am I missing here?
> >
> > Thanks,
> > Ben
> >
> >
> > --- In [EMAIL PROTECTED]ups.com <flexcoders%40yahoogroups.com>,
> > "der_kotty" <kotty.tm@> wrote:
> > >
> > > Hi,
> > >
> > > I was just wondering why the com.adobe.cairngorm.business.Responder
> > > interface has been changed since it has been released on Adobe Labs.
> > > In Cairngorm 2.0 alpha (org.nevis.cairngorm.business.Responder) the
> > > parameters of the onFault and onResult handlers were typed events
> > > (ResultEvent and FaultEvent).
> > >
> > > Why have the parameters been changed to '*'? Where is the sense in
> > > that? To my opinion this is not really best practice but maybe
> > > there's a really good reason for that? Does anyone know?
> > >
> > > Cheers
> > > David
> > >
> >
> >
> >
>

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links

__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to