Self-Referencing Proxy Components

The AbstractProxyComponent class in the UcompOS SDK must, by strict convention, be the superclass for all Proxy Components. Understanding the mechanics of AbstractProxyComponent and its public properties and methods is a crucial step in building the most powerful Proxy Components that promote richer and more engaging experiences for users of your Rich Portal Application.

In this post, I will touch on one of the public properties of AbstractProxyComponent, self, and explain its purpose and provide a use-case scenario.

As you know, in the context of the UcompOS Continuum, the UcompOS Portal is simply one of X UcompOS entities, each of which have the UcompOS SDK implemented.

The UcompOS Portal sponsors a host of public API methods and the UcompOS SDK has been equipped with a batch of Proxy Components that serve as clients that can be used in your own UcompOS Applications to connect to these public API methods.

At the current time, the self property on AbstractProxyComponent may seem tightly coupled to the UcompOS Portal’s Proxy Components and specifically, to two of those Proxy Components: UcompOSWindowProxy and UcompOSArtifactProxy. However, as the UcompOS RXF continues to expand, the self property on a Proxy Component will take on increasingly significant meaning.

Right now however, the UcompOSWindowProxy and UcompOSArtifactProxy provide a very good model with which to illustrate the purpose of this self property.

As you know, when you create an instance of UcompOSWindowProxy and call its add(); method, you are launching a UcompOS Window on the UcompOS Portal and you are specifying the URL of the content that should be loaded into this window.

Behind the scenes, when the UcompOS SDK loads this content to the UcompOS Window, it passes the content some crucial information that that content will use to become a member of the UcompOS Continuum thereby being able to participate in SDK transmissions with other entities.

Here’s an interesting question:

What if you load some content into a UcompOS Window, and then you want to reference the UcompOS Window that the content is loaded into from the content itself?

The answer to this is you would create a UcompOSWindowProxy instance and then set its self property to true.

As an example of how I have used this capability, I have created a Rich Text Editor for my Educator 2 application I am building on top of the UcompOS RXF. This editor is a Flex 4 implementation.

In Educator 2, by strict convention, all SWF content I load into UcompOS Window and UcompOS Artifact instances is loaded in sandboxed configurations and I rely 100% on SDK transmissions for communication with other entities (the exception is drag and drop which I talked about in this posting).

The challenge then becomes, how do I resize the editor? To resize the editor, the user isn’t going to actually resize the editor itself, rather, the UcompOS Window instance the editor is loaded into. Since my content is sandboxed, I can’t access the parent container the content is loaded into using traditional scripting from within my Editor application.

The solution is to create a reference to a UcompOSWindowProxy and set its self property to true.

Let’s take a look at some code here that is similar to what you’d see in my editor application:

private function init(event:FlexEvent):void
{
 
	// Instantiate the UcompOS SDK
	SDKClient.getInstance(this,new ServicesDictionary());
 
	// Create a UcompOS Window Proxy instance
	var w:UcompOSWindowProxy = new UcompOSWindowProxy();
 
	// Create a self-reference - w in this case becomes a reference to
	// the UcompOS Window instance the content in scope is loaded into
	w.self = true;
 
	// listen for window resize events
	w.addEventListener(UcompOSWindowProxy.RESIZE_END,resizeHandler);
	w.addEventListener(UcompOSWindowProxy.MAXIMIZE,resizeHandler);
	w.addEventListener(UcompOSWindowProxy.RESTORE,resizeHandler);
 
}
 
// the SDKEvent instance dispatched to this handler following
// a window resize operation contains the new width/height of the
// UcompOS Window - the width and height of the content viewing
// portions of the UcompOS Window are housed in the event.data.width
// and event.data.height properties
private function resizeHandler(event:SDKEvent):void
{
 
	var w:UcompOSWindowProxy = event.target as UcompOSWindowProxy;
 
	// suppose my editor component is a variable named myEditor
	myEditor.width = event.data.width;
	myEditor.height = event.data.height;
 
}

These same mechanics can be leveraged in UcompOSArtifactProxy instances.

In fact, in one of my earliest UcompOS Video Tutorials entitled Building a UcompOS Weather Channel Widget, we saw this technique.

In that implementation, I created a self referencing UcompOSArtifactProxy instance so I could attach a Context Menu to the UcompOS Artifact and capture user selections on this Context Menu.

Here is a very simple example of a Flash CS4/CS5 UcompOS Application that leverages this principle:

package
{
 
	import flash.display.Sprite;
	import com.ucompass.ucompos.sdk.SDKClient;
	import com.ucompass.ucompos.sdk.proxycomponents.UcompOSArtifactProxy;
	import com.ucompass.ucompos.sdk.events.SDKEvent;
 
	public class Example extends Sprite
	{
 
		public function Example()
		{
 
			var sdkClient:SDKClient = SDKClient.getInstance(this);
 
			var artifact:UcompOSArtifactProxy = new UcompOSArtifactProxy();
			artifact.self = true;
			artifact.setContextMenu(new XML(""));
			artifact.addEventListener(UcompOSArtifactProxy.MENU_ITEM_SELECT,contextMenu_handler);
 
		}
 
		private function contextMenu_handler(event:SDKEvent):void
		{
			trace("User selected "+event.data.label);
		}
 
	}
 
}