In part one, I introduced some of the things that I believe convolute the Flex third party framework space – primarily the influence of MVC. The history around this pattern, particularly in the Java world, has allowed frameworks to gain mindshare that do little but help enforce the pattern. This post is about bringing the focus back to features that make life easier on developers by allowing them to build the things that users care about faster and/or easier. That’s really what third party frameworks should aim to do.
So, moving forward by pretending that no one will disagree with that assertion, here is the overview of what would be in my perfect Flex application development framework:
- Separation of Concerns (SoC):
In Flex development, there is a need for something outside of the core framework to help developers adhere to a separation in the application code. In reality it is not the most difficult or interesting part of the problem, but would likely be a part of any complete third-party framework. I personally prefer the Swiz dependency injection approach for this. Also, there are likely a number of interesting things one could add on top of a dependency injection foundation, as we have seen with the SpringFramework in Java.
Looking at the Swiz implementation, one can also conclude that the underlying platform needs to grow so that this can be supported in a more native way and increase the possibility that greater leverage can be gained from introducing dependency injection to Flex applications.
- Client Side Data Management (think client side Hibernate):
RIA introduced (or re-introduced) the notion of client side data / state. In traditional page based applications, the developer never had to consider this possibility, as all state is kept and tracked on the server. With advanced RIA features, state is often changed on the client, but not immediately sent back to the server. This introduces a number of challenges in managing data state between the client and the server. Thus, there is a need for infrastructure to support data synchronization between the client and server.
Both LiveCycle Data Service (LCDS) and Clear Toolkit include features that help the developer with this to a certain extent, but they rely on the specific server implementations. In my perfect imaginary world, this would all be done client-side agnostic of what server is providing the data so that one could use it regardless of what technology is providing the data.
This may even be coming in the next version of Flash Builder:
“Of course, data-centric applications are about more than just binding operations to components. Flash Builder lets you enable client side data management for your services, allowing on-demand fetching of data for easy and efficient scrolling through large collections of data; change tracking, allowing users to undo actions, and automating the common CRUD (create, read, update, & delete) functions that usually need to be hand-coded. The results are applications that deliver users a richer experience than is possible with ordinary HTML front ends.”
In any enterprise application, there are security considerations at multiple levels. There are a number of methods and strategies for dealing with authentication, but not many Flex tools for addressing authorization. In the simplest form, one can break out authorization into the following categories: service/method level, data level, and filtering what each user can view on the screen. Securing services and data pretty much have to be handled on the server, but something is necessary to control what the user sees on the client.
There are not many libraries I know of for implementing this common requirement. My current preference is my Chimp component for doing this declaratively through Flex metadata. Many just deal with this manually in each component, others monkey patch to add filtering logic on UIComponent or within View States. Ideally, features for dealing with this challenge would make it into any complete third-party framework.
- Global Event Bus:
In Mate, basically every event is handled through the Mate event bus. Having a global event bus can invaluable in implementing a number of RIA features. Yet, handling every single event this way seems a bit odd to me. I think Flex events can be broken into four categories:
Component Events: These are events that are only omitted and handled inside the component. Think of a component that has children and they need to communicate between one another.
Local Events: These events are omitted by components that can be handled by within the context that the component is used.
Global & Data Change Events: Events that any arbitrary part of the system may want to be notified of when they happen, such as the user profile has changed.
So, in my mind, the bus is a necessary part of the perfect Flex framework, but shouldn’t be used for handling all events in the system.
Those are my top requirements for the perfect third-party Flex framework. I am sure there are a number of others that it would make sense to add to the list.
In working through this post, I concluded that there is too much focus put into third-party frameworks with Flex. The items I outlined are missing gaps that need to be met with third-party frameworks, or hopefully by the underlying platform someday, but they are not the most challenging things one will encounter when building enterprise Flex applications.
The biggest challenge for Flex applications of any scale is the quality Flash Player virtual machine. The Flash Player has to get faster, better at dealing with memory consumption, and garbage collection. Flex is a good platform for building rich Internet applications, but like any emerging technology it will have to mature to continue to gain adoptions and keep the current developers.