Mykola, > Totally agree but EJB was also first technology for > enterprise development in Java and it worth us to be blind > for a 5 years. EJB was the same overcomplicated that > Cairngorm is and as far as I understand Cairngorm uses the > same patterns and fully inspired by J2EE.
EJB and Cairngorm have nothing in common; both are frameworks, one as you know is a (excuse the simplification) framework for object persistence, the other is a framework microarchitecture for RIA. That the EJB spec is overcomplicated does not mean that Cairngorm is, just because both can be called "frameworks" or both have reference to J2EE. Cairngorm does borrow heavily from the body of work that was performed with Core J2EE Patterns; however, it is not applying J2EE to Flex, it is recognising that many of the patterns that the Core J2EE pattern catalogue included, are patterns that can be applicable to RIA development with Flex (MXML and ActionScript). Note I say *can* be applied to RIA, not *must* be applied to RIA. There are many ways to skin a cat. Apologies to cat lovers. Insert annoying animal of your choice. > do not repeat previous mistakes. You do not need to get > things that complex like thy are now with Commands > FrontControllers and other stuff. I think that's quite a bold statement. Perhaps you do not need them, and I absolutely agree that many many projects do not need Commands, Front Controllers or "other stuff". However, I have worked on and with several projects that *have* benefited from these patterns and the architecture that the collaboration of these patterns introduced. Was this solution the *only* way we could have addressed the problems we faced ? Of course not ... There are as many different ways of doing these things as there are talented architects and developers that are now working with the technology. If you have your own framework that works for you, and if it addresses the problems that you face in your design, then you're correct not to use Cairngorm. Many other developers have done the same as you, and their implementations are not the worse for it. However, let's also accept that a great number of developers *have* benefited greatly from frameworks such as Cairngorm or ARP, have felt that these frameworks have introduced simplicity where complexity previously existed. These people do not think Cairngorm (or whatever other framework) is bad. Nor will they assert that the framework you are using instead is bad. Let's not continue this thread on the assertion that there will be one ultimately better than all the rest way of building all RIA upon Flex. > Now I have a kind of > framework that is much easier than Cairngorm and I'll try to > share it with the community when it will pass internal > sainity testing in our team (now guys are happy but lets wait > more serious testing). I look forward to seeing it, and hope that it can be presented not as "better than Cairngorm" or "simpler than Cairngorm" but simply "different to Cairngorm". In understanding what you tried to achieve with your approach, rather than what you don't like about other approaches, I think we'll all learn a lot more, no ? > >> - No kickstart examples like Appfuse in Java > >Hopefully time wil bring them. Flex2 will drive a radically > larger community. > It is a huge problem cause when you need team development you > need unittesting, framework, build strategy etc. And I'm sure > that every team create it from scratch now. The idea is to > publish some approach and evolve it to support and show best > practices on it. Just to be clear, I know of teams of 30+ developers who are developing Flex applications based upon Cairngorm, who are actively embracing unit-testing, continuous integration, refactoring, and all manner of other agile practices. Certainly, the same team that brought you Cairngorm initially, has a great deal of experience in delivering projects using Agile methods, particuarly XP, with both Java, ActionScript 1.0, ActionScript 2.0 and most recently Flex 2 and ActionScript 3.0. The technology, and the choice of architectures upon the technology, have never impinged (any more than AWT, Swing, J2ME, JSP and JavaScript, etc have) upon our ability to deliver using agile methodologies. I guess the challenge here, is that many of these teams are immersed in product development, and can't always invest the time necessary to put these best-practices such as how to do asynchronous testing, out to the community as whitepapers/blog entries, etc, quickly as people would like. However; I'd challenge the *need* to do asynchronous testing, if you're refactoring correctly. You can "design for test", and think carefully in Cairngorm about how you implement your Command classes, to make them more testable. I know of teams who do asynchronous testing with mock object strategies, however I have never found the overhead of those approaches to justify the test-complexity. I don't believe in testing remote object calls for instance; if I can test everything up to the point a remote-object cal is made on the client, *and* I can Junit test the implementation of the service on the server, then I gain little utility from testing the RemoteObject tag itself. Similarly, by refactoring "business objects" out of Command classes - be they shopping carts, loan calculators, or whatever - one can improve the testability of applications built upon Cairngorm, without having to bother about asynchronous testing. In summary; I'm loathe to let comments like "Cairngorm doesn't allow agile development" go past, as it's simply not true - there are a number of agile development teams that I'm aware with, that are building applications on Cairngorm, as well as other bespoke architectures. Cairngorm doesn't introduce any complexity over and above the Flex framework, that reduces the ability to unit-test, perform test-driven development and run a continuous integration server. > Just like appfuse does in Java community. I > guess we have to create our own appfuse Spring + Hibernate + > Flex, maybe also Spring + Hibernate + Laszlo to have fully > open source alternative. Again, Cairngorm won't get in the way of you achieving this, nor will Flex. I know also of Flex projects that are built upon Hibernate (we've built some), as well as Flex projects hitting a server-side tier built upon the Spring framework. > I managed to write unitests for our approach but it was very > hard and if your approach evolves test need to be greatly > changed not like it is with the sync calls. I can't wait to see how you get on with Flex 2 Data Services....you'll be pleased I'm sure. Mykola, the challenges you're facing are challenges a number of J2EE developers have successfully faced in the past few years; I think you'll find that there are people out there who - in-between delivering their own projects - will have useful information for you to share. Perhaps framing some questions around how people have achieved some of the challenges you face, rather than saying they're overly complex or can't be achieved, will yield some success for you ? I look forward to seeing what framework you extract from your current project work. I'm sure it'll complement the current of body of knowledge greatly, and we'll all benefit. In the meantime, the iteration::two team that are now Macromedia Consulting in EMEA, will strive to deliver whitepapers, articles and further blog entries on some of these issues such as unit-testing and test-driven development of Flex applications, of continuous integration, and all manner of other lessons learned as we've worked with Flex partners and customers. Bear with us ... These things take time to pull together. Best wishes, Steven -- Steven Webster Practice Director (Rich Internet Applications) Macromedia Consulting EMEA Office: + 44 (0) 131 338 6108 Mobile: +44 (0) 7917 428 947 ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/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/