12 steps

1. If you can use Adobe Flex framework, use it! You’d better create a component than anything else. You can reuse components later in other projects and The Reuse is the main divinity in software engineer’s pantheon.
2. What is missing in Flex framework is a thin but important layer between Flex components and server side (Java, PHP .Net etc). This is where our ideal framework can be useful.
3. “Write less do more” is the only thing that important about any framework (it should be true in a long run too). Theoretical principles like MVC, patterns etc are not so much important as this one.
4. Dependency injection/Inversion of Control pattern is the next best thing after sliced bread. If you have numerous objects in your application (and you do usually have them), you have to write code to make calls from one object to another (to couple them). Look up code could take up to 1/3 of your total code if you have many small routines. It also makes your code highly coupled and hence not very reusable. So something that could automate lookups is definitely should be in our ideal framework.
5. The framework should help you to work with asynchronous calls. Asynchronous calls are the way how Flash app communicates with server side. Usually you need to add event listener and remove it after you got response from the server. We need to get rid of it and let framework manage it.
6. Also about asynchronous calls, it’s usually needed to chain some asynchronous calls (to make next call only after previous call is executed with success, for example). Or you just want to execute some function after all asynchronous calls are executed (and don’t really care about the order of calls). In this case what you usually do is to write lots of event listeners just to manage this workflow and it becomes a mess very quickly. So our framework should help us with that too.
7. Debugging. Flex Builder (for example) has quite good debugger so our framework shouldn’t break it or have any unpredictable execution flow (which is usually the case when you overuse events)
8. Code auto completion. This is something that we’d like to be able to use too (to avoid all these typing mistakes)
9. Our view classes or MXMLs should be decoupled but not too much. You should be able to take a look at MXML file and see any data dependencies it needs. However, our view classes shouldn’t care about how to get these data.
10. Testability. It should be easy to test you classes using FlexUnit for example. Writing/executing tests seems to be one the most important thing for bug free software.
11. We should use ActionScript3 language and not just copy Java idioms to ActionScript. It means to use functional objects and event listeners where Java uses anonymous classes and interfaces. The framework also should make good use of dynamic typing.
12. Performance: memory and speed. It should be the last point in this list as you need to take care of everything else before optimization. Premature optimization is the root of all evil!

Let’s see how Ctx Flex framework answers to these requirements.

Ctx is dependency injection framework with many features that are essential for creating enterprise applications. It’s similar to Java Spring framework. Ctx has one class called remarkably enouch Ctx. You register any objects with this class using register() method and after this it becomes a bean. Ctx manages dependencies for beans using autowiring by name or type. For details read Ctx “Getting started” and “Reference” documents.

1. Ctx doesn’t add itself to display list or interfere in any way with Flex components. It won’t help you with creating Flex components as Flex framework itself is good enough for this task.

2. Your visual classes use Ctx framework to communicate with server backend. If you don’t have server backend in your application it usually means that you don’t need to use Ctx framework. This makes Ctx framework more enterprise application oriented framework. Ctx sits between Flex visual application and server backend, effectively filling the gap.

3. To get started with Ctx framework, you should know only one class: Ctx. You don’t have to create anything extra to communicate inside your application (no need for copious custom event classes, for example).

4. Ctx does dependency injection for you (autowiring by name and by type). You can adjust many details how dependencies should be wired using metadata, but metadata is not required as Ctx has reasonable defaults and you can use simple naming conventions to enable/disable autowiring, enable autowiring by type or by name, enable automatic dependency creation etc.

5. In Ctx we have a bunch of functions to work with asynchronous calls. Use handle(someAsyncCall(), onResultHanler, onFaultHanler). Use chain() to chain several asynchronous calls, use branch() to execute several calls simultaneously (without any specific order). These functions operate using AsyncToken object (all RPC services return AsyncToken objects). In addition, Ctx framework has artificial implementation of AsyncToken which is useful when you need to do something asynchronously but without backend. This is how mock objects (for testing remote services without actual backend) and multithreading are implemented in Ctx framework. Also it’s quite common to store the result of asynchronous function call somewhere in data model. For this you can use handleData() function. All these functions are package level functions so you don’t have to prefix them with class name (similar to other package level functions like trace() etc).

6. You can link handle(), brach(), chain() functions in the manner similar to functional programming. They all return operate on AsyncToken objects and they return AsyncToken objects. You can add different handlers in different places to AsyncTokens. You can add parameters to tokens to pass some additional data (AsyncToken is dynamic object).

7. Ctx doesn’t use events, only dependency injection. So whenever you see some error, call stack tells you exactly what happened, where and execution flow. (However, you can use Ctx as event bus to broadcast events to multiple beans if needed).

8. Ctx could be used in typeless mode (because Ctx is dynamic object),or you can subclass Ctx and add hardcoded names to all your beans (so FlexBuilder will be able to provide auto completion).

9. You just reference your data model properties in your data model beans (bean is a class that is registered with Ctx class). Something like <mx:List dataProvider=”c.myModelBean.customers” /> You still see what are data dependencies for your view object but it doesn’t have any code to get these data. You can create pair view-model bean and just specify properties inside model beans. These properties could be populated later by some bean which knows how to get data. We use data binding here. “c” is an instance of Ctx which is bindable. Of course, properties in your data model bean should be bindable too. View doesn’t have to wait till framework initialized, it gets notified when data is available via binding mechanism.

10. Your beans are simple AS3 classes. You can test them using FlexUnit for example. If your beans have asynchronous calls, it’s not a problem as FlexUnit has support for asynchronous calls as well.

11. Ctx object is dynamic object. It means you can add properties to it as you will do with any object of type Object. Adding a property has semantic of registering a bean, getting a property is the same as getting wired instance of some bean. Helper functions like handle(), chain() and brach() use closures (functional objects) so you type very little comparing to what you would have to type if using interfaces.

12. Ctx has support for data caching (using CachedService) to optimize memory and network usage, support for quasi-multithreading (to execute extensive processing in AS3).

I’ve never intended Ctx to be used by broad masses of people. But I find many people struggling with the same problems as I did, so I decided to share this framework and I hope it will be useful (at least I can guarantee that it won’t be harmful )

Source code and examples are available here http://code.google.com/p/ctx/

One of the requirements was ability to handle lots of items. Also the wall is extremly configurable thru XML file (each element could have own animations and effects settings, etc)

Here is my summary of +/- -ses:

“+”

1. Nice design

2. Intuitive workflow (for example, how you add columns and rows)

3. Quite robust (I’ve tried to stress-test it a little bit and it still was ok after all tortures )

Except the fact that it’s “Preview” version and it’s missing many features that should be there (like cell-level formatting or charts), there are some significant architectural drawbacks:

“-”

1. This is not spreadsheet application – it’s a data entering/presentation application. The difference is that we use spreadsheets not for creating our shopping to-do lists and family budgets but for so called spreadsheet calculations. In other words, we use formulas a lot. Spreadsheet computational model is very productive for financial and scientific models, for example. One could say that MS Excel is “Data => Knowledge” tool, while Adobe Tables is more for visualization. So Adobe follows that “Data importance” fallacy. After all, very few people can understand raw data and interpret it.

2. Do we need another to-do list application, contact list etc? Blist.com tried to achieve something like that and apparently they failed and moved to “data storage” concept. I guess that Adobe Tables was not created by people who use spreadsheets for many years to make money

3. Integration with MS Excel is crucial: it should be some kind of export/import. The application should be able to display Excel files.

4.  It’s for end users only, I see no way how not-Adobe developers could make use of it – it’s not a component.

5. (Implementation detail) Data presentation for client<->server is very sparse (some kind of HTML). It’s not important for small files however but could be a show stopper for big ones.

Frankly speaking Adobe doesn’t tell that it’s a spreadsheet application, just lookalike. But I got people asking me and comparing Adobe Tables to Idubee Flex spreadsheet application so I felt kinda pressed to write this

There will be variations of the component to fit individual needs and pockets.

• Spreadsheet base component (displays data in read only mode, selection&copy supported)
• Spreadsheet editor subcomponent (for those who needs to edit spreadsheets online)
• Formula evaluation engines (ActionScript, JavaScript or server-side based)
• Other modules (formulas extensions, file import/export plugins, macros etc)

Also license options (limited or unlimited use, binaries or source) and support&enhancements services.

Please, let us know if you’re interested in testing betas, evaluating releases and, eventually,  purchasing licenses or if you see some  investment opportunities for idubee. (please use contact form here or just leave a comment here)

Image Shack Uploader is an Adobe AIR application for Image Shack service. Source is available on Google code.

and AIRTranslate that uses Google Translate services.