Interesting read and well thought out. Couple of things:
"..FrontController for command accessing - I see no reason why I have to look up somehting by name rather that access directly. It gives nothing but pain because it does not make Command free of knowing about the View and the Model, the dependency still remains.." --- I've probably used it in a different manner, but essentially i tend to broadcast an event request, rather then accessing it direct. Commands can change, but their verbing doesn't or better yet you can disable a command by capturing it and diverting it to a swap out sequence...ie not sure how you mean the view access the front controller direct? - as for model? again, you get a result with a command, how do you abstract that cleanly? ie where do you store that commands result stack? i think the objective for Model in Cairngorm was to formalize the overall "how it gets stored" vs free for all memory storage. "..Almost everything is static - Singleton is antipattern, since it does not allow inheritance. It means I cannot enhance FrontController, ServiceLocator etc. Also I do not understand why ModelLocator is static. Static model is bad since you cannot have 2 instances of window that has different models. The best practice is to have everything non-static and bind in run time. Otherwise it becomes not OOP and you finally come to the situation when you cannot extend your functionality without complete re factoring..." -- Right tool right job... Static has gains, more so you don't need to write some long winded factory method to access a singleton or something along those lines. As then their is now a reliance on it first being initialized in memory, secondly did it succeed or fail and lastly then access it. Static can be used to implement instance based nodes, its perfectly legitimate to use a static class as a facade to your memory cache or instance specific nodes? isn't OOP more about abstraction of complexity? the semantics of how to me are "whatever blows your hair back" weighted arguments? (ie not sure i'd back your decision on this one fully, partially yes, but not fully). "...Single command instances :) I was surprised but in suggested FrontController all events of the same name are handled by the same command instance. It is completely wrong usage of the command pattern that considering that you are always create new command instance upon execution. Without this you cannot implement such stuff as undo/redo (actually it is the only case when you need command, only for undo/redo). But don't 99% of your functionality does not requires undo/redo. Then why you use commands, and why you use it wrong way? The answer is: To make your code contain more lines and more files, to say you manager that the framework requires lots of work, but is is architectured by megaguys and they cannot be wrong. Remember EJB? I do.." I can't speak for i2 guys on this one, but to me i think the overall level of thinking was more about memory then anything else. Unlike other languages or platforms, we in the FLEX world (ie FLEX 1.5 especially) have a limited usage of memory, the more we take up, the slower things get. So its in our best interest to unload as much as we can as soon as we can, especially with previous versions of Flash Player having issues with automated Garbage Collection. That being said, the new and latest FLEX 2.0 has a lot more powers at hand, so this could be revisited in a new light - that's for people like yourself and others on this list to flood the Cairngorm development team with suggestions..so they can be debated and weighed up against the overall purpose of why the framework exists. Writing a Framework is never going to be the complete universal way of life, the purpose of a framework is to increase delivery and abstract complexity where possible. Cairngorm does that, the semantics of how and why are more about theology. In that if you wanted to implement the above and you *HAVE* to use the Cairngorm way of life, you can, there are avenues to do this, it just requires your mode of thinking to be a bit more agile in execution. That being said, feel free to write one based on cairngorm or other, as the more out there the more we can cherry pick and hopefully come together on a more battle tested and power-focused framework.? Interesting read though and i (flexcoder member badge #221312) would love to see more talk like this here, as it's great to see the technology challenged (whether thats frameworks or as2). On 11/15/05, Mykola Paliyenko <[EMAIL PROTECTED]> wrote: > 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 > > > > > > -- > 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 > > > > > > > -- Regards, Scott Barnes http://www.mossyblog.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/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/
