The “Widget-based Programming Model” for Flex Enterprise Applications
I came across this article on O’Reilly’s InsideRIA site by Moxie Zheng and was surprised to find some similarities between the architecture the author describes and the architecture that I am seeking to create. The good stuff begins under the subtitle about halfway down, labeled “The Architecture”, where Moxie Zheng discusses his use of an Event Bus the same way as I have implemented it into my own architecture.
One thing I wanted to point out, and my reason for mentioning it here, is that below that he describes what he refers to as “The Widget Programming Model”, something I have not come across before. When it comes to enterprise Flex apps, we’re usually dealing with multiple user levels. In other words, the interface must look different based on the conditions under which the user is accessing the application. These conditions are often set by an external database server that handles user management, in which user types and their respective permissions may be set in a specific table. Then each user is assigned a user type, or in some cases, multiple user types. Therefore, the client side AIR or Flex application must construct itself “on the fly” so to speak, based on the group of configuration settings that it is handed from the server side. I like this widget-based programming model because it takes custom component development to an even more loosely coupled level, making it virtually impossible for the developer to creat interdependencies within an application due to the nature under which that particular widget must be programmed. It’s loose-coupling at it’s finest.
These “widgets” are compiled as separate swf “mini-applications” if you will, encapsulating and isolating code that handles a specific way of viewing data on the server. As I wrap my brain around the possibilities with this design pattern, I can’t help but think that for applications that are powered by specialized services, a “widget registry” could in fact be formed on the network (talking about AIR applications only now). Therefore, if a user was installing the application based on a certain set of credentials, a call to the network registry would return a set of “widgets” that should be installed along with the main application, thus defining how that particular user views the application interface. This concept could easily apply to the branding of an application based on the web site it was downloaded from, as a simple example.
Possibly Related Posts:
- Second Generation Micro-architectures, Part 1: The Swiz Framework
- Open source clientside RIA frameworks for SaaS
- Using the Zend Framework to take some wind out of AIR
- Traditional Project Management vs. Agile Development with Software as a Service projects
- Data-centric Adobe Flash Builder development with the Zend Framework
Posted by Dan Orlando on February 2nd, 2009 :: Filed under Enterprise Flex, Tools & Innovation
Tags :: design patterns, Enterprise Flex, Flex
You can leave a response, or trackback from your own site.
February 2nd, 2009
Hey Dan, you described some unspoken ideas in my insideria article behind the viewer and the widget programming model. I was hoping someone could take the design and go further within a larger enterprise architecture. You just did. Thanks.
Moxie
March 10th, 2009
My pleasure Moxie. That is a great article you have posted there at InsideRIA, and it is a pleasure to make your acquaintance. I’m involved with a company right now that is currently acquiring capital to build a project that implements an architecture like the one described above. I look forward to having the opportunity to actually put this concept that our brains have collectively created (in theory, that is) into a real-world enterprise application. If our economy wasn’t so bad, I’d probably already have a team working on it, but acquiring investor dollars isn’t an easy task these days. Anyway, thanks for commenting.
Dan
August 31st, 2009
Hey Dan,
I’m in the middle of developing something similar to this also. However I came across one issue, which (based on your blog) I’m hoping you might be able to give some insight on.
What I’m looking for is a way for an AIR wrapper to provide caching services for a sub-app that wishes to access a particular service. This should happen in such a way that the sub-app does not need to care if it’s running within AIR or within the Flash player, and the AIR wrapper would not need to implement the concrete classes of each service a potential sub-app might require. Roughly put, the following flow:
1. Sub-app sends request to a service
2. AIR wrapper checks if network connection available
2a. If yes, data is sent to service
2b. If no, the AIR wrapper stores the data locally (to be sent when a connection is detected again)
3. Either way, the sub-app gets a success message, with the added detail of whether or not the data was stored remotely or locally.
Any thoughts on this matter? Would be greatly apprechiated.
October 8th, 2009
Sorry for the late reply on this. Apparently this one snuck by me. Here’s my thought on this: I think you’re looking at it upside down. You don’t need an AIR wrapper, you need a basic AS3 library/swc with the code you need to create a proxy, open a socket connection, get the data, and store it to a local db. The library should have the path to the database and the statements for creating objects from the database on demand. Then just include that swc in the different Flex, Flash, or AIR projects and make calls into it as necessary. we call that your “commons” library. It should have a single call in it that takes care of the entire process of opening the socket connection, receiving the necessary bytecode, doing whatever processing is necessary (object typing, etc.) and stores it to the db. Hopefully that makes sense.