Hi Paolo, > Could you explain the reason this new way of passing the > command string in the addCommand in the ShopController: > > addCommand( ShopController.EVENT_GET_PRODUCTS, new GetProductsCommand > () ); > .... > public static var EVENT_GET_PRODUCTS = "getProducts"; > > compare to the old cairngorm 0.95 style: > > addCommand( "getProducts", new GetProductsCommand() );
Sure, this is just us showing what we consider to be a good practice; again, it's not something new to Cairngorm, but a practice we'd like to elucidate through the samples we give you. A common refactoring (in the Martin Fowler's book on Refactoring term, not on the word that people throw around to mean code editing) that is performed is the "Replace Magic Number with a Symbolic Constant" refactoring: http://www.refactoring.com/catalog/replaceMagicNumberWithSymbolicConstant.ht ml By defining static constants on our Controller, we can quickly look to our controller to identify the names of the events that we are able to broadcast, and that our controller will respond to. Everywhere else in our code, we reduce the risk of broadcasting the "getaccounts" event instead of the correctly capitalised "getAccounts" event for instance, by instead broadcasting ShopController.EVENT_GET_ACCOUNTS. In this way, if we spell incorrectly, eg ShopController.EVENT_GET_ACOUNTS, then this is caught at compile-time rathr than at run-time. We're big believers in letting the compiler do as much error checking as possible, and reducing the source of run-time error. So this isn't a "Cairngorm best-practice" it's simply a best-practice that iteration::two adhere to, and that we're promoting in our samples. Hope that helps, Best, Steven -- Steven Webster Technical Director iteration::two This e-mail and any associated attachments transmitted with it may contain confidential information and must not be copied, or disclosed, or used by anyone other than the intended recipient(s). If you are not the intended recipient(s) please destroy this e-mail, and any copies of it, immediately. Please also note that while software systems have been used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened. 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/
