RE: [flexcoders] Re: CairngormEvent Antipattern

2006-09-03 Thread Steven Webster
e_bagggSent: 31 August 2006 03:39To: flexcoders@yahoogroups.comSubject: [flexcoders] Re: CairngormEvent Antipattern Andi-Tom was referring to having a hierarchy of FrontControllers.He happens to have a class called "CoreController" which all of hisFlex apps would

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-09-01 Thread Tom Chiverton
On Thursday 31 August 2006 03:38, e_baggg wrote: > He happens to have a class called "CoreController" which all of his > Flex apps would use. Then, each Flex app will have it's own > FrontController that extends CoreController...this way each developer > has their own controller. This assumes of co

[flexcoders] Re: CairngormEvent Antipattern

2006-08-31 Thread Tim Hoff
The example has good intentions. Anytime you can reduce the amount of code in an application it's good, right? Not always. One of the main strengths of the Cairngorm framework is simplicity. What the example refers to as a big downside, exists for a reason; simplicity. By having one-to-one

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-08-31 Thread Andrea Varga
e_baggg wrote: >Andi- > Tom was referring to having a hierarchy of FrontControllers. > >He happens to have a class called "CoreController" which all of his >Flex apps would use. Then, each Flex app will have it's own >FrontController that extends CoreController...this way each developer >has thei

[flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread e_baggg
Andi- Tom was referring to having a hierarchy of FrontControllers. He happens to have a class called "CoreController" which all of his Flex apps would use. Then, each Flex app will have it's own FrontController that extends CoreController...this way each developer has their own controller. This

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread Andrea Varga
Tom Chiverton wrote: >On Wednesday 30 August 2006 13:14, Andrea Varga wrote: > > >>(For example, on a large project, when there are many developers >>working, all of them has to edit the FrontController to add an event.) >> >> > >This isn't a problem with a decent RCS. > >As it is, we've got

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread Ralf Bokelberg
The frontcontroller doesn't map events to commands but strings like WidgetController.EVENT_ADD_WIDGET to commands. So any event with a type set to WidgetController.EVENT_ADD_WIDGET, which reaches the frontcontroller, triggers the command, which is bound to the string WidgetController.EVENT_ADD_WIDG

[flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread lostinrecursion
This approach seems like it could be extremely useful for me as I am starting to build a lot of larger projects, but I have a quick comment. Forgive me if I am off base here, but is there a mistake in the code example? I am new to Cairngorm so bear with me for a moment. According to your example,

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread Tom Chiverton
On Wednesday 30 August 2006 13:14, Andrea Varga wrote: > (For example, on a large project, when there are many developers > working, all of them has to edit the FrontController to add an event.) This isn't a problem with a decent RCS. As it is, we've got a CoreController and then indivdual projec

Re: [flexcoders] Re: CairngormEvent Antipattern

2006-08-30 Thread Andrea Varga
Got it. Thanks for the explanation. There were many discussions about the FronController just growing and growing. Do you happen to have a solution for refactoring? (For example, on a large project, when there are many developers working, all of them has to edit the FrontController to add an eve

[flexcoders] Re: CairngormEvent Antipattern

2006-08-25 Thread e_baggg
Andi- Nothing changes with the FrontController and Commands. You would still have 3 separate commands (1 each for add, update, delete). Remember, the generic CairngormEvent classes calls: "super(commandName)" so the dispatchEvent() for each call would like this: dispatchEvent(new WidgetE