Thanks again for the comments. Lets stop the discussion about frameworks, my opinion about Core J2EE patterns etc because its a religious controversy. I will share my results when I'll be ready.
The question of this topic was not Cairngorm or something else but:
Is Flex mature enough now? What are our chances if we need to build huge RIA application in 7 month using Flex? I'd like to hear about project already completed or about to being completed by teams of at least 20 developers.
Also we cannot rely on the Flex2 since it uses 8.5 player that will not be widespread by the moment we need to launch.
WBR, Mykola
On 11/28/05, Steven Webster <[EMAIL PROTECTED]> wrote:
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
--
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
Web site design development Computer software development Software design and development Macromedia flex Software development best practice
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.
--
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
- 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.
