I have finished “fixes” on some project that was developed by typical J2EE team and needed to made work before it enters official beta. It has been extremely difficult to navigate and resolve and I would like to provide a brief checklist of symptoms you might want to review to see if your project is heading for trouble:
Symptom #1. The sizable project is built very much on Flex framework without layer of UI controls for common business and UI functionality. Typical of shops that think of MXML as another xHTML.
Problem: Impossible to enforce consistent behavior across multiple screens, cumbersome user input, complicated formatting and validation, tons of “cut and paste” spaghetti code and millions of bugs.
Solution: Extend MXML controls into business controls that would make reusable UI elements with ROBUST and SIMPLE interface. Make sure that your controls are perfect to the end-users of your application. Strive for data-driven application programming.
Symptom #2. Conventional J2EE middle tier that does nothing but repackages data for DB/XML communications.
Problem: It usually does something in reality. It might prevent you from using transactional capabilities in database. It can hide errors from the back-end. It might contain bugs. Cause performance degradation and scalability issues.
Solution: Either go directly to the datasource or base your data entry systems on the model with client-centric updates. Provide direct feedback on the errors, transactional control, eliminate duplication and integration problems.
Symptom #3: Cairngorm framework for large application. I am going to get a lot of flame mail on that one.
Problem: Nevertheless, I was saying it 15 years ago, and I say it again – do not use framework unless you build application identical to the one the framework was built for. Unfortunately, RIA area is much wider than old “shopping cart/content management” Web we know of – there is slim chance that any framework will be more of help then a burden unless you indeed are building shopping cart. Framework is not a silver bullet, but rather a way to postpone design stage.
Solution: Start with class libraries. Build and verify reusable components early. You are in object-oriented, event-driven, real-world facing environment that has to be intelligent and friendly to the end-user. Break your application into libraries and modules as early as you can – it will pay off faster then you think.
Symptom 4#: Excessive use of binding.
Problem: You try to see dependencies, and it just never ends. Cycles, breaks, using binding for initialization, wrong timing – you name it. Debugging becomes time consuming and very challenging. As a result – untested code that seems to work.
Solution: Understand the difference between binding, initialization and types of the events you really want to listen to. Handle events locally in the business domain UI components. Do not force system to do more then it needs. In the event driven environment you really want to keep the noise down -especially for large applications.
Symptom 5#: No error handling, no logging statement and assertions in the code.
Problem: I can be wrong here. It is possible that the code is perfect and nothing is going to break ever. Otherwise, you are doomed. Seriously, bringing support phone into your bedroom is not thing you want to do. Postponing the problems after release date will get you in trouble.
Solution: I will blog a bit more next week and make sure we will release some of the internal tools in the circulation this month. There is no excuse not to use logging API and assertion in Flex.
Sincerely,
Anatole Tartakovsky
�
PaulH said,
February 17, 2007 @ 12:12 pm
seems like reasonable advice. btw how are you logging client side? something custom? or have i misunderstood that the logging classes were only good for debug clients? yes, still a cf guy new to flex
thanks.
Leif Wells said,
February 17, 2007 @ 12:27 pm
“#3 Cairngorm framework for large application” — yeah, I think you should get flamed for that one, but I am not in the mood to get out the lighter fluid… let me just say that I feel that Cairngorm can be used for any type of application.
“#5 No error handling, no logging statement and assertions in the code” — I preach this a lot, but at the same time I get caught by it, too. The times I do deal with error handling and logging the best is when I am developing the front-end for someone else’s back-end (i.e. it’s not being developed by someone at my company). When I am placed in that situation, I try to be very cautious when exchanging data with the back-end — you never know when someone will be changing code on that back-end and then the front-end will break; and then someone at the client’s office will call to say that the front-end is broken. If I can have an error appear (on or off screen) and log it in the server logs, then no one will be surprised when the error occurs.
anatole tartakovsky said,
February 18, 2007 @ 12:59 am
Paul,
I personally use logger embedded directly in Eclipse ( Yakov blogged on UI/functionality a while back http://flexblog.faratasystems.com/?p=148). The Log classes are independent from the version of player (production/debug). We have a nice UI driven target configurator when we need to get picky about the classes or few preconfigured logging targets for cases like we just want to see innerworkings of the client/server communications. We will be releasing that plugin this week.
If you can’t wait you can always go to Adobe Flex exchange and look up my old submission with control/viewer – more of Flash era though as it is not based on Flex Logging.
Thanks,
Anatole
Jamie Badman said,
February 19, 2007 @ 12:59 pm
The only thing I don’t agree with there is the Cairngorm comment – simply because my experience using Cairngorm with large applications has been very positive to date, particularly with V2 – losing the ‘viewHelper’ stuff was a great step forward. What I do feel, however, is that some work is a little more cumbersome using Cairngorm but long term, developing ’similar’ applications (ie those sharing common data – which where I work is most likely to happen) this work will pay off with some nice reusability.
Jamie.
Jamie Badman said,
February 19, 2007 @ 1:00 pm
(when I say ‘cairngorm comment’ I meant the comment in the main article, not the comment about the main article, which mentioned Cairngorm… sorry for any confusion caused! )
anatole tartakovsky said,
February 20, 2007 @ 5:54 pm
Jamie,
There are 2 different things there – reusability of the framework code itself for the application and reusability of your code. Making your code reusable is your own responsibility, and framework should not take credit for it. After all it is just as possible to make not [re]usable code in any framework.
There are very few applications outside of the domain mentioned in the article that should be singletons based, do not change over time in unexpected way and would not be constrained by Cairngorm. As I said in the blog, selecting framework allows to postpone design process till a lot of development is done – and then there is a slim chance for redesign. If you do design without framework in mind, the applicability of framework becomes an implementation decision, not the other way around.
Over the years software industry removed big parts – security, styling, business rules, etc in separate layers. That allowed to remove most of the “infrastructure” pieces automated by frameworks outside of the core application development and reduced value of frameworks. Class libraries are well known for “layering” the “last mile” of application development to provide common functionality and structure. Dropping framework over “last mile” works in some hi-rises – but it does not necessarily reduces the amount of handwiring. On the outside, it can severely limit flexibility of the solution.
Here is what concerns me most. I have seen it quite a few times when the tool vendor’s framework is being pushed to the market. Most of the people getting intoFlex will try any piece of code pushed by Adobe – as sample code or a way to learn how to do things.
Mere fact that Adobe offers framework means that it will be used – often without the cause. It also means it will be considerered without due dilligence applied to anyone else. Frameworks from primary vendor virtually annihilate a chance for 3rd party developers community – I would expect a lot of familiar faces in Lazlo camp within half year from now. That is just one thing tool maker may never do – or face completely different eco system for the product.
Sincerely,
Anatole Tartakovsky
Tom Gonzalez said,
February 21, 2007 @ 11:29 am
I actually agree with the assertion that Cairngorm “out-of-the-box” is not a great fit for large complex applications. Specifically due to the reasons Anatole states, you will most likely benefit if you use a framework specific to the type of application you are building, especially for business applications.
Cairngorm is a great starting point, especially for people unfamilar with design patterns. But once you start to dig deeper into Cairngorm and the patterns being used, you will most likely find that you will want to modify/extend/replace some of the patterns being leveraged to the specific needs of your business applications. In fact some of the patterns being advocated in Cairngrom (front controller) are not really fully leveraged (at least I have not seen Cairngorm apps with mulitple front controllers.)
Personally one of the greatest benefits I see to Cairngorm are the not the specific design patterns, but the fact it represents a common reference point to developers working across a multitude of projects, once you understand Cairngorm it is much easier to understand the specifics of how a particular application is coded that uses the framework, you don’t have to learn a whole new framework The trade-off with that common reference point, is that you cant be everything to everybody and most likely your specific application (if it has a significant amount of complexity) will benefit from a framework designed/adapted to support the use cases embodied in your app.
- Tom