The ability to send headers for AMF remoting calls is supported in the lower level flex classes but not exposed in the RemoteObject class. GEMVC now includes (in the trunk of SVN) its own extension of the RemoteObject and Operation classes that allow you to set these headers. All you have to do is set the headers global on your AMF Service or set them on the MVCAMFCommandInfo class when you call your remote service. One caveat though: These headers are not placed in the HTTP headers, they are actually encoded in the AMF packet (why?) so your backend AMF gateway must be able to retrieve them. With Coldfusion 8 I have not been able to access these headers but I have included them anyway in case other configurations can.

For those of you who want to use the Flex Logging framework to send your log messages to a remote service you can now do it by simply referencing the "gemvc" filter like so:

myLogger = Log.getLogger("gemvc"); myLogger.info("this is a log message");

the message will be redirected to any log services you may have set up on the server side (see previous blog post).

The old logging methods on the MVCApplication class are still there, the only difference being is that they now use the Flex Logging Levels as well (mx.logging.LogEventLevel). These levels are converted to the equivalents that the backend service uses which may be different. In your logging service entry in your services.xml you will also need to add a mapping to the pre-defined service log levels like so:

If you are using the MVCAMFService or MVCWebService you can now use a MVCAMFServiceInfo class or MVCWebServiceInfo class when calling a service method to provide additional parameters, such as showBusyCursor, on a method-by-method basis. They mimic the options in the AMFOperation and WebServiceOperation classes. Check out the changes from the trunk. If anyone wants a pre-built swc let me know. I have been waiting to do another release until I added a demo application (I actually have one that is built on an application framework on top of GEMVC but it relies on a SQL-Server db).

If you ever have multiple events that run simultaneously on common data or GUI controls (for example manipulating multiple tree controls all bound to the same model variable) you have wait until one event is finished before executing the other. Previously, the only way to do this was to have your event handlers set a global flag and your event that dispatched the events must check this flag and then use callLater to keep looping until the flag is set. Now, GEMVC includes a MVCWatchableEvent class that all your events can extend. In your event handlers you can now automatically watch an event for it to complete and then perform further actions. You only need change your dispatchEvent call in the calling event handler and place a done() call in the event that you are watching when the event processing is complete. For example, I have an event handler that among other things uses a shared object to restore the state of various trees in the application. Since I have multiple trees that all share the same data provider they have to be done sequentially. So inside handleEvent() of my event I call:

var ev:ExpandHierarchyEvent = new ExpandHierarchyEvent(model.savedState.data.savedInfo);

onMVCEventComplete(context,ev,sequentialFunction,[context]);

Inside my ExpandHierarchyEvent I place a call to done() when my event completes normally.

Make sure both events extend the MVCWatchableEvent class.

Update your code from the trunk to get the new change.

I have added support for the HTTPService and WebService Flex tags as their own gateways in the GEMVC trunk. I have not fully tested them so will document more about them when they have but you can see from the service locators and the gateways what the syntax is and what additional methods are available.

The CommandInfo class has had two additional properites added: objectToEnableOnFault and objectToEnableOnResult. With these you can disable controls that activate events inside their events so a user cannot click the control twice (or technically and entire window or pane) while it is still processing. So inside my handleEvent the first thing I do is say: target.enabled = false (you can also explicity list the control you want to disable with context.mycontrol.enabled = false, but using the control that dispatched the event is cleaner) then before each service call I use code like: var info:MVCServiceInfo = new MVCServiceInfo; info.objectToEnableOnFault = target; That way if an error occurs, gemvc will automatically re-enable the control so you don't have to worry about it. You can also set info.objectToEnableOnResult = target if you want your control automatically re-enabled because your event is complete. Otherwise you add the line at the end of your event before your last service call. Sometimes you may have to set target.enabled = true yourself at the end of your event as well if you have a case where based upon on a condition you call a service or you just exit. I have seen in my applications where if you select GUI controls too fast errors can result. This is most critical with events that update the db but I have also used it on selection events that change the screen (like filters) because these can cause errors as well if you select them too quick. In order for target.enabled to work you need to make sure that the control you want to disable dispatches the event. Currently, in a combo box, for example, you just say click="dispatchEvent(..)" but now you should say comboboxid.dispatchEvent(...) otherwise you will get the enclosing UIComponent (Canvas, Pane, VBox, etc.) as the target (which is some cases may be a good thing as it is in mine).

I have not created an official release (one is coming very soon just trying to get a demo application created) but there are new features in the gemvc trunk that may be of interest.

1) The messaging.xml and services.xml have been combined into one file. Your entries will now look like:

2) Logging has been added.

With Flex there is no way to globally catch errors. You have to manually put try/catch blocks everywhere. GEMVC has been modified to help with this by catching any errors that occur in a service call handler (unless you use callLater()). It will display the standard GEMVC alert box (or the one you overrode MVCApplication with) and will log it back to the server if you have a logging Service. If your logger supports mail you can mail them as well.

All you have to do to take advantage of this feature is:

a) Have a CF logging service that has a log function that accepts a string message and int logLevel.

b) Add this to your services.xml file:

Notice that you can have multiple loggers.

You may want to overload the getInfoLogLevel and getErrorLogLevel methods if the GEMVC defaults do not match your log levels (currently 4 and 1 respectively).

More to come

I am been pretty focused on use the Flex RemoteObject tag and the AMF protocol that I have neglected the WebService tag. If anyone out there is trying to use SOAP or has the time I would greatly appreciate a WebServiceGateway to complement the AMFGateway and MessagingGateway classes. Anyone up for it?

In the documentation it states that you should perform the following to initialize your application:

public function init():void { // set up our MVC controller for this component addEventListener(MVCServicesInitializedEvent.MVC_SERVICES_INITIALIZED,servicesInit); controller = new MyController(this); if (getService() != null) { dispatchEvent(new MyInitEvent()); } } private function servicesInit(ev:Event):void { dispatchEvent(new MyInitEvent()); } Turns out that if you do not use the optional messaging.xml file then the MVCServicesInitializedEvent is not thrown and due to timing your services may be null. I updated the trunk to fix this or you can just create an empty messaging.xml file.

This is the distribution that includes a new tutorial submitted by Gabe Iverson and includes the new features that have already been blogged about. Hierarchical controllers are supported and Flex producer/consumer tags are encapsulated by the service layer. Next up is allow a controller to perform an action from an event instead of the event's handle function (which will still be allowed). This will satisfy the MVC purists. Also, more mxml tag support is planned.

Depending upon timing in your flex app there is a possibility of your creationComplete=init() method executing and dispatching an event that uses the service layer before the service layer has been initialized. To handle this situation you need to use the MVCServicesInitializedEvent that is thrown by the framework like so:

public function init():void { // set up our MVC controller for this component addEventListener( MVCServicesInitializedEvent.MVC_SERVICES_INITIALIZED, servicesInit); controller = new MyAppController(this); if (getService() != null) { dispatchEvent(new MyAppInitEvent()); } } private function servicesInit(ev:Event):void { dispatchEvent(new MyAppInitEvent()); }