Mykola, I'm about to head out to MAX in Hong Kong, so will pick up this thread on your return. What I would say is that if you find things are not working for your needs, propose to us how you would alter Cairngorm to make things better, before starting with a blank page. We're very much open to your comments and suggestions.
Very briefly: 1) Commands I'd like to hear your thoughts in more detail as to why the command pattern is not as effective as anonymous classes ? What do you mean by "lots of dummy commands" ? As an application scales, the command patterns scales well also. 2) Front Controller Again, I don't quite understand your concern. Command manipulates the model, not the view (if you follow the ModelLocator), so command is unaware of the implementation of the view. What do you mean by "accessing something by name" ? 3) Singleton as anti-pattern I just disagree here; that we choose these things to be singletons is *because* we only want a single instance. If you require multiple instances, refactor the singleton to a factory pattern ? Can you give real use-case here as to why you might want to do this, and where current implementation fails you ? 4) Il8n The architectural framework provides a prescriptive framework for architecture, and doesn't choose to implement services in a prescribed manner. There is belief that internationalisation may become a core part of the Flex framework, and Cairngorm elected not to prescribe an implementation until this becomes apparent. In the meantime, there is a well described implementation by Benoit Hedard that fits within the Cairngorm architecture, but does not rely upon it. 5) No unit-tests Fair point; however, we haven't prescribed mock objects as part of Flex Unit, or asynchronous tests as part of Flex Unit, but that doesn't mean they aren't strategies that can be implemented alongside Flex Unit. Irrespective, the lack of prescribed unit-testing strategy is not to the detriment of using the Cairngorm framework. You can use the Cairngorm framework, and adopt these testing strategies if you see fit. I don't understand this as an argument for or against adopting a Cairngorm-esque architecture. 6) Single Command Instances We have an internal build of Cairngorm that doesn't have single command instances, and creates a new instance per command. It's not backward compatible, which is why we chose not to release it as yet. As for "we only use commands to be architecture megaguys and write lots of lines of code". I assume you're being flippant .... That we choose to use Commands is because we find that it provides a readable and maintanable code-base, that it supports feature-driven development, that it encourages reuse and promotes refactoring of the code-base, and that it enables collective code ownership. Command patterns have worked for us on a large number of multi-team projects, and I know it's working for a great number of other developers. If you can propose something that also achieves the above, I'm open to suggestions. Cairngorm is by no means "the true way, the only way", and I absolutely agree that one could take alternate approaches to implementing a framework microarchitecture. However, I'd welcome that these approaches be presented as alternatives, with their own justifications for the rationale and motivation behind their particular implementations. Incidentally; Cairngorm *is* open-source; your blog entry suggests that it isn't ? So; how would you do things differently ? What are the problems that you feel a framework for RIA has to address, what are the forces, and how do you think you might go about your implementation ? Do you agree with the forces and motivations, and dispute their implementation, or do you believe we are offering solutions to problems that do not exist ? I genuinely look forward to your feedback; however, please excuse me if I don't reply over the next week. I'll be spreading the Cairngorm-word at MAX Greater China :-D Best, Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 > -----Original Message----- > From: flexcoders@yahoogroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Mykola Paliyenko > Sent: 14 November 2005 17:15 > To: flexcoders > Subject: [flexcoders] Cairngorm is bad? > > Dear Flexcoders. > I want to start here discussion about development enterprise > applications using Flex. Our company has choosen Cairngorm as > a framework to do it, but I believe it has some drawbacks My > comments are here: > http://jroller.com/page/mickolka?entry=cairngorm_is_bad > I'm new to Flex but not new to the ActionScript and > JavaScript, also I know lots of Java Web MVC frameworks so I > have a vision about how framework should look like to make > your project succeed. > Thanx for any comments. > > Regards, > Mykola > > > > > ------------------------ Yahoo! Groups Sponsor > --------------------~--> Get Bzzzy! (real tools to help you > find a job). Welcome to the Sweet Life. > http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM > -------------------------------------------------------------- > ------~-> > > -- > 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 > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- 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/
