RE: [flexcoders] Re: CairngormEvent Antipattern
Are you using source-code control systems like CVS or Subversion ? These tools solved the problem a long time ago, of having multiple developers editing the same source file at the same time ... let the tools handle the problems of merging the controller when someone checks in their code. If developers are checking-in/committing code that breaks a build, that's a development process problem, not a technology or architecture problem. Developers should not be "fighting for control" of a class ?!? Nor should they be emailing around changes to code. Apologies if this is teaching you how to suck eggs; if not, then google for subversion or cvs and get that in place as soon as possible! Best, Steven Steven WebsterPractice Leader (Rich Internet Applications and LiveCycle)Adobe ConsultingWestpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338 6108 m: +44 (0)7917 428 947[EMAIL PROTECTED] From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of 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 use. Then, each Flex app will have it's ownFrontController that extends CoreController...this way each developerhas their own controller. This assumes of course there's 1 developerworking on a project. The CoreController would house the commonCommands such as Login, Logout, and similar things.If you're in the situation where you have 1 large Flex app that has 1large controller that all the developers are fighting for...I wouldsuggest that users update the Contoller and check in their emptyCommand classes right away. Then begin development. That way if ittakes them 2 days to implement the logic for an event, they won't havea lot of contacts. Another option is to make one developer the 'owner'of the front controller and have other developers e-mail them the lineof code for the command.--- In [EMAIL PROTECTED]ups.com, Andrea Varga [EMAIL PROTECTED] wrote: 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 a CoreController and then indivdual projectsextend that to make their application specific events. Could you please tell me where can I found more about this? I cannot find anything. Thanks. Andi __._,_.___ -- 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 Software development tool Software development Software development services Home design software Software development company YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to:[EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___
Re: [flexcoders] Re: CairngormEvent Antipattern
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 course there's 1 developer Sort of :-) This is out first Flex2 app, but we've identified several things that will be usefull in the next one - auth a username and password against our NDS directory, get a list of user in a department etc. In the client, all those go into the CoreController which we'll reuse across projects (svn copy (or link), rar !). Project specific bits then go in the sub class. -- Tom Chiverton Helping to carefully envisioneer fifth-generation infomediaries This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: CairngormEvent Antipattern
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 their own controller. This assumes of course there's 1 developer working on a project. The CoreController would house the common Commands such as Login, Logout, and similar things. If you're in the situation where you have 1 large Flex app that has 1 large controller that all the developers are fighting for...I would suggest that users update the Contoller and check in their empty Command classes right away. Then begin development. That way if it takes them 2 days to implement the logic for an event, they won't have a lot of contacts. Another option is to make one developer the 'owner' of the front controller and have other developers e-mail them the line of code for the command. Thank you. I just wasn't sure this is the right way to do it. I mean, that cannot be more than one FrontController/project. It seems, this is the only solution. The problem I'm having with this is not regarding the 'owner', with a version control system that's not a problem. But the FrontController gets bigger and bigger, and less managable (although there is nothing much to manage :), just a bunch of addCommands :)), and I don't know weather this could cause problems or not (regarding speed for example). Andi --- In flexcoders@yahoogroups.com, Andrea Varga [EMAIL PROTECTED] wrote: 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 a CoreController and then indivdual projects extend that to make their application specific events. Could you please tell me where can I found more about this? I cannot find anything. Thanks. Andi -- 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 -- Andrea Varga Managing Partner / Project Manager Certified Macromedia Flash MX 2004 Developer -- Spin Development Srl Tel: +44 207 043 1304 Fax: +44 207 681 1376 Skype ID: vargaandrea Mon-Fri : 8 AM - 5 PM GMT+2 Saturday: 8 AM - 4 PM GMT+2 (Support only) -- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: CairngormEvent Antipattern
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 relationships, between CairngormEvents and Commands, it is easier to organize and maintain the events. Not that you have to, of course. However, in a typical use case the get, add, update and delete CairngormEvents would each use a different VO. The get VO would contain Select parameters, while the update VO would contain fields and/or instructions. The example would have to conditionally check the type of the event, to determine the appropriate VO to pass on to the command. Certainly an option, but conditional coding can be avoided by keeping the separate actions in separate classes. This keeps things simple, while enforcing encapsulation and promoting reuse. CairngormEvents can always placed in different events sub folders to increase orginization. As far as extending the FrontController (same applies to the ModelLocator), when classes get too big, break them apart into smaller pieces. The FrontController does nothing more than lookup the Command name to execute. Sub classing the FrontController wouldn't affect performance. These issues are more related to data transfer, command methods (functions) and rendering. -TH --- In flexcoders@yahoogroups.com, Andrea Varga [EMAIL PROTECTED] wrote: 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 their own controller. This assumes of course there's 1 developer working on a project. The CoreController would house the common Commands such as Login, Logout, and similar things. If you're in the situation where you have 1 large Flex app that has 1 large controller that all the developers are fighting for...I would suggest that users update the Contoller and check in their empty Command classes right away. Then begin development. That way if it takes them 2 days to implement the logic for an event, they won't have a lot of contacts. Another option is to make one developer the 'owner' of the front controller and have other developers e-mail them the line of code for the command. Thank you. I just wasn't sure this is the right way to do it. I mean, that cannot be more than one FrontController/project. It seems, this is the only solution. The problem I'm having with this is not regarding the 'owner', with a version control system that's not a problem. But the FrontController gets bigger and bigger, and less managable (although there is nothing much to manage :), just a bunch of addCommands :)), and I don't know weather this could cause problems or not (regarding speed for example). Andi --- In flexcoders@yahoogroups.com, Andrea Varga andi@ wrote: 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 a CoreController and then indivdual projects extend that to make their application specific events. Could you please tell me where can I found more about this? I cannot find anything. Thanks. Andi -- 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 -- Andrea Varga Managing Partner / Project Manager Certified Macromedia Flash MX 2004 Developer -- Spin Development Srl Tel: +44 207 043 1304 Fax: +44 207 681 1376 Skype ID: vargaandrea Mon-Fri : 8 AM - 5 PM GMT+2 Saturday: 8 AM - 4 PM GMT+2 (Support only) -- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: CairngormEvent Antipattern
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 event.) Andi e_baggg wrote: 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 WidgetEvent(WidgetFrontController.ADD_WIDGET, widgetVO)); dispatchEvent(new WidgetEvent(WidgetFrontController.UPDATE_WIDGET, widgetVO)); dispatchEvent(new WidgetEvent(WidgetFrontController.DELETE_WIDGET, widgetVO)); and each Command will apropriately be called just like it was. The key is we're no longer hard-coding the WidgetFrontController.ADD_WIDGET into each CairngormEvent sublcass. --- In flexcoders@yahoogroups.com, Andrea Varga [EMAIL PROTECTED] wrote: e_baggg wrote: Hello group- I hadn't seen a previous post regarding this explicity so I wrote a small blog about it. It helps reduce the #of classes that get created when using Cairngorm (a big issue with me since the client is VERY picky with their swf file sizes). This blog shows the code for usuing a reusable CairngormEvent versus creating separate classes for each dispatchable event. http://ebaggg.blogspot.com/2006/08/cairngormevent-anti-pattern-we-all.html Thoughts? The ideea is good, but how do you handle them further? Will you have 3 different commands associated with the same event? And each Command will start with an if statement, to see if that's the event he supposed to answer to? Doesn't seem right. Andi -- 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 -- Andrea Varga Managing Partner / Project Manager Certified Macromedia Flash MX 2004 Developer -- Spin Development Srl Tel: +44 207 043 1304 Fax: +44 207 681 1376 Skype ID: vargaandrea Mon-Fri : 8 AM - 5 PM GMT+2 Saturday: 8 AM - 4 PM GMT+2 (Support only) -- -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: CairngormEvent Antipattern
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 projects extend that to make their application specific events. -- Tom Chiverton Helping to centrally synthesize cross-media data This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: CairngormEvent Antipattern
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, you call the event like so: CODE --- var addEvent : WidgetEvent = new WidgetEvent(WidgetController.EVENT_ADD_WIDGET, widgetVO); dispatchEvent(addEvent); --- But, in the Controller, the EVENT_ADD_WIDGET constant, in keeping with Cairngorm practice, equates to the following string: addWidget So, my question is this, if the WidgetEvent expects a parameter of commandName, which in this case would be addWidgetCommand (Again, assuming you are using best practice), then how does the application call the correct command? Is it because the FrontController automatically maps Events to Commands? I'm a little confused. -K -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: CairngormEvent Antipattern
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_WIDGET. Cheers, Ralf. On 8/30/06, lostinrecursion [EMAIL PROTECTED] wrote: 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, you call the event like so: CODE --- var addEvent : WidgetEvent = new WidgetEvent(WidgetController.EVENT_ADD_WIDGET, widgetVO); dispatchEvent(addEvent); --- But, in the Controller, the EVENT_ADD_WIDGET constant, in keeping with Cairngorm practice, equates to the following string: addWidget So, my question is this, if the WidgetEvent expects a parameter of commandName, which in this case would be addWidgetCommand (Again, assuming you are using best practice), then how does the application call the correct command? Is it because the FrontController automatically maps Events to Commands? I'm a little confused. -K -- 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 -- Ralf Bokelberg [EMAIL PROTECTED] Flex Flash Consultant based in Cologne/Germany -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[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 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 course there's 1 developer working on a project. The CoreController would house the common Commands such as Login, Logout, and similar things. If you're in the situation where you have 1 large Flex app that has 1 large controller that all the developers are fighting for...I would suggest that users update the Contoller and check in their empty Command classes right away. Then begin development. That way if it takes them 2 days to implement the logic for an event, they won't have a lot of contacts. Another option is to make one developer the 'owner' of the front controller and have other developers e-mail them the line of code for the command. --- In flexcoders@yahoogroups.com, Andrea Varga [EMAIL PROTECTED] wrote: 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 a CoreController and then indivdual projects extend that to make their application specific events. Could you please tell me where can I found more about this? I cannot find anything. Thanks. Andi -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: CairngormEvent Antipattern
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 WidgetEvent(WidgetFrontController.ADD_WIDGET, widgetVO)); dispatchEvent(new WidgetEvent(WidgetFrontController.UPDATE_WIDGET, widgetVO)); dispatchEvent(new WidgetEvent(WidgetFrontController.DELETE_WIDGET, widgetVO)); and each Command will apropriately be called just like it was. The key is we're no longer hard-coding the WidgetFrontController.ADD_WIDGET into each CairngormEvent sublcass. --- In flexcoders@yahoogroups.com, Andrea Varga [EMAIL PROTECTED] wrote: e_baggg wrote: Hello group- I hadn't seen a previous post regarding this explicity so I wrote a small blog about it. It helps reduce the #of classes that get created when using Cairngorm (a big issue with me since the client is VERY picky with their swf file sizes). This blog shows the code for usuing a reusable CairngormEvent versus creating separate classes for each dispatchable event. http://ebaggg.blogspot.com/2006/08/cairngormevent-anti-pattern-we-all.html Thoughts? The ideea is good, but how do you handle them further? Will you have 3 different commands associated with the same event? And each Command will start with an if statement, to see if that's the event he supposed to answer to? Doesn't seem right. Andi -- 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 * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/