||||(.) (.)

Well,

The most important thing when rewriting the old code is to decide which framework chose Yes framework or maybe only some utility classes ex smartypants ioc is better . I will say go with IOC 100% to separate your view from the logic part. You can loose some time when you’ve got some not organized code, or you are using the oldie framework but it will benefit in the future.

First Separate your business logic.

Badly written project have some business logic mixed up with the view logic. Services with specific calculations. When you will try to rewrite your application try to group your business methods in one part and the view logic in the other part. It’s easy in the Robotlegs Mediator so you can see what methods have it’s view.someFancyComponent reference and what have not. Put the minimum in the view components logic and separate other things to some Helper classes that you can refactor later. If  your project is quite big and getting larger you will see you have some helpers that methods are the same but maybe some little part is different. Try to use it as params. Once you clear your view logic out from business logic  you can separate the business itself to services logic and equations logic. Do equations in separate classes call it some strategy. ex. MyBudgetImportantStrategy if you are using DI you can insert it and decouple with interface and you can use unit tests in the future. The equations logic merely changes when it’s done right.  And you are ready for webworkers dude. You can then put your all equations to the worker. The update will be 1-2days not 1-2weeks, months when you wrote your code wrong and keep doing it.

Second be elastic with gui.

Well the gui part is the most important thing in the flex. It have changes. Well it is changing all the time. Maybe you remember some css issues when migrating from flex 2 to flex 3 and you will remember rewrite to the flex 4 and then you will remember if your boss told you compile it to mobile. The simple part is IOC. When you have IOC framework with your business logic highly separated from the gui. The gui logic is the bottleneck. If you screw this up and you need to refresh the look of your big enterprise application you are in hell now. You need to keep your mediators smart and simple, decouple the state and change layout logic from the interaction logic. The layout logic it the shit when you need to reorganize your components view the all the old layout is often the shit see the flex 3 and flex 4 states, flex 3 and flex 4 css. But the button clicks as it clicks it is the main functionality for it, combobox often is only combobox and list is a list. But it may be in the different state of your layout now. When you put your view components first think what is your functionality for this control. And try to put the functionality components separate from your layout component’s don’t mix them up or they will mix you up when refreshing the look.

Third

Think, read and ask, there are many people out there that have the same problems and there are many authorities in the world of flash/flex that write some good shit about every problem you have. But don’t chose the first solution of your problem the person who wrote it 3 years ago is not the same programmer now, maybe someone did it better so you can use it . Try to read more, yes it’s time consuming but when you rewriting you don’t want to rewrite it again and again. Maybe sometimes it’s better to mix some solutions up to build something better.  Use event’s as much as you can you can. Man if you have some performance problems why then not use signals or do some own simple notifications where you send often. The event’s are for you to keep your life easier not to kill you. Do the commands. The command is the shit cause it only have one functionality. You can separate it and use it in your logic.

Prototype only when your time is very limited but try to separate the 4 logical parts

- layout, - interaction,- services, - equations

cause  flashplayer is crossplatform only from the basis and you interact with phones, tablets other then on desktop or even game console. Your layout and functionality may be different for other screens and equations could be moved to the server when low performance. And on there is still more freedom on the desktop.

Happy codding ;)

Well when doing some extra large project I was always concerned how to force myself to code right. Not share some dependences across modules not reference to the application, how to manage large codebase and what framework I need to use. Well I chose Robotlegs cause it’s simple and will be the best way to success and Joel Hooks wrote nice modular extension to it so we can make everything modular.  It’s amazing that that technology works smoothly without any problems. But let’s get back to the point.

Well if you have something like 1-10 modules you can keep everything in the same project I think. But what if your plan is to have 20-30 modules ? And by the way you have external people working on your project you not really want to share all your code. How to keep things consistent.  I’ll share my concept with you cause it’s simple. LIBRARIES, yes each module should have separate project library so you won’t use one module  codebase in another module codebase what’s modular application essential.  Next you need at least one common module for your framework classes that are shared across all modules. Let’s say it will be the Components, validators, renderers and some other visual related stuff I will name it CORE. I also managed to separate communication module that sends and receives the data from the services. And for this point I wanted to have all my communication classes in another module - let’s say the API. So you can use the API and give the api and the CORE to the external developer and he will do some shit for you. And you give him only SWC with some documentation not the all codebase.

Some conclusions:

- Unless you are moving something to the  CORE library or API library your project build time will be something like 1-2 seconds. That’s something. You are not frustrating while flashbuilder is building your project or freezes sometimes without memory.

- You don’t have to worry that you used some classes across modules and you don’t know what dependences are - you have it all in CORE. Your modules should be equal in size, and the size won’t be 10-40kB it will be all the classes you have in the library so 100-200kB so you will save some time while loading big application and showing it to client.

- If you managed to separate your SERVICE to the external module and that’s with all flash domain policy really hard shit, if you use some remote classes that you send or receive it’s really messy but then you can use it in some third party related project’s.

-You can then give the API and CORE  and see what other people will build with it.