The UcompOS RPF Implements the MVC Design Pattern

The Model-View-Controller (MVC) design pattern is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data.

The internals of the UcompOS Portal application (which is a Flex 4 application) were created strictly following the MVC Design Pattern.

In addition, the overall UcompOS Continuum (I refer to the UcompOS Continuum as the UcompOS Portal and all the UcompOS applications and sub-applications it launches that work together collectively to create a Rich Experience) takes on an implementation style that closely resembles MVC.

When a UcompOS application is launched by the UcompOS Portal, the application is invisibly loaded into the UcompOS run-time.  It has no visual presentation.  You can launch a UcompOS application immediately into a UcompOS Window or UcompOS Browser Window by adding the selfLoading=’true’ attribute to the application’s root Application Manifest element (which will launch the content in a UcompOS Window) and the newWindow=’true’ attribute (which will launch the content in a UcompOS Browser Window).  Even in these scenarios though, a “helper” UcompOS Application is loaded into the UcompOS run-time which then is given the task of launching your application’s base content into a UcompOS Window or UcompOS Browser Window instance.  So technically, in these scenarios, your UcompOS base application code is actually a sub-application.

In a best practice implementation, you can think of the base source code of your overall UcompOS Application (that gets loaded invisibly into the UcompOS run-time) as serving as the Model and Controller for your UcompOS Application and the sub-applications that are launched into UcompOS Window, UcompOS Browser Window, or UcompOS Artifact instances as the View from an MVC implementation point of view.

From a terminology point of view, I have been internally referring to the content that is loaded invisibly into the run-time as the Portlet Manager, and the visual code launched into UcompOS Browser Windows, UcompOS Windows, or UcompOS Artifacts as the Portlets.  I have refrained from making this the official terminology however.  This project, necessarily, has a lot of jargon associated with it and I want to be very judicious and careful with the terms used to describe the various aspects and features of the framework.

In the implementations I have been building, I delegate any network responsibilities as far as retrieving data from a remote data source or updating a remote model to the Portlet Manager.  The Portlet Manager also implements listeners to the artifacts, windows, and browser window instances it spawns and launches and manages other Portlets based on user interactivity with said artifacts, windows, and browser window instances.

In a Portlet instance, there will obviously be functionality that involves manipulating or working with data presentations that correspond to  the Model in the overall application.  My standard practice is to dispatch any model changes to the Portlet Manager by using a Proxy Component class housed in the Portlet instance and a public API method exposed in the Portlet Manager’s Services Dictionary.

One thing I haven’t talked about in my postings yet is the Event Dispatchment architecture in the UcompOS RPF.  This topic is worthy of and will receive thorough coverage in the near future.

As a very generic foreshadowing to this, the AbstractProxyComponent class is in the UcompOS SDK and it is the class all Proxy Components must extend.

AbstractProxyComponent itself extends EventDispatcher and therefore, any Proxy Component has the addEventListener(); method available to it.

The event type you can register with a Proxy Component is of type SDKEvent which is also a class built into the UcompOS SDK.

As a very simple example, consider the following example code implemented in a UcompOS Application:

var w:UcompOSWindowProxy = new UcompOSWindowProxy();
w.add("http://www.google.com","Google",800,600,100,100);

This will open a UcompOS Window in the UcompOS Portal of dimensions 800 x 600 at 100,100 relative to the upper-left origin point.

Now, consider the following:

w.addEventListener(UcompOSWindowProxy.CLOSE,closeHandler);
private function closeHandler(event:SDKEvent):void
{
  // the window was closed!
}

I’ll devote my entire next posting to the SDKEvent class which is extremely important in terms of building highly interactive Rich Portal Applications with the UcompOS RPF and I’ll walk through the data flow and event propagation model involved with the simple example above.

About Edward Mansouri
Edward Mansouri is the CEO and Founder of Ucompass.com, Inc., a company focused on building scalable and profitable e-Learning enterprises. His expertise is in building e-Learning software, as well as in building visual frameworks such as the Enrich Content Enrichment System and the newly announced UcompOS Rich Experience Framework. He has been working with Flash since 1998, building Flash applications since 2002, and working with Adobe AIR since its private alpha release in 2006. He authored the site AIRApps.net (later renamed to O2Apps.com) dedicated to providing leadership in building Adobe AIR applications. In 2010, he is building and releasing a new e-Learning platform called Educator 2 which is built entirely upon the UcompOS Rich Experience Framework. Since 1999, over 1,000,000 students have taken courses served with his original e-Learning platform, Educator 1.

Comments are closed.