Archive for March, 2007

Wish I’d Said That …

We monitor a variety of forums, lists, blogs, etc., and sometimes we see a really brilliant answer that causes us to say “I wish we’d said that in the docs!” With that thought in mind, here is the first of a series of “Wish I’d Said That…” postings and it comes from Adobe Engineer Kevin Hoyt in response to a question about MySQL connectivity to Flex. However, Kevin goes way beyond that and offers a great overview of data access in Flex, along with considerations for choosing one over the other.

So, without further ado, ladies and gentlement, Kevin Hoyt!

Question: What is the most direct connection to MySQL with FDS and Flex where queries can be made against the DB?

Kevin’s response:
This is a pretty broad question as there are a number of ways to connect to data from a Flex application. Generally speaking however, Flex applications are services-centric (SOA) and in that respect always require some degree of middleware to access a database. The most common means of connecting to data are:

REST/XML-RPC
In these scenarios the customer might have a middleware resource such as a JSP page or servlet that gets a GET/POST request from a Flex application (HTTPService class). That server resource would then access the database using whatever means are traditional to that middleware – JDBC in the case of Java. The results of data access can then be formatted into XML (where one might more traditionally format the results in an HTML table) and returned as the response to the initial request. Flex/Flash Player have excellent XML handling capabilities and can then manipulate the data for display in the application UI.

The great thing about this approach is that it acts as a lowest common denominator. I’ve mentioned a Java-centric approach here, but this could easily be implemented using any number of technologies. Essentially anything that can get an HTTP request and return XML as the response.

SOAP/Web Services
This is really just a more formalized/standardized version of the XML-RPC approach. Rather than accessing a JSP specifically, a Flex application can access a web service endpoint. Per a specification, that service knows the format in which the data was sent, and how to format a response. Most middleware technologies these days support exposing logic/objects as web services. In this case, virtually any of these services can be consumed by a Flex application (WebService class).

The great thing about web services is that since they follow a standard, the application doesn’t have to know about the infrastructure details. This is especially great for B2B composite applications where there needs to be (or already exists) a high degree of abstraction. There is a trade-off however over XML-RPC in that SOAP is often very verbose and heavy across the wire, which can also mean more client-side memory requirements and processing/parsing time.

Remoting/AMF
Within the context of FDS, we figure that rather than rework your business logic as XML or SOAP (which is ultimately XML itself), why not just access the business logic directly? This saves developers time in having to write potentially tedious code to expose existing logic as XML. In the case of a Java application server, a Flex application can access a Java object directly by remote invocation of a method on a designated object (RemoteObject class). That object on the server can then deal with it’s native data types as arguments, query a database from those arguments, and return it’s native data types as a value (i.e. return a List of Contact objects).

Above and beyond this ease of use, is the speed with which this communication happens across the wire. Data exchanges still happen over HTTP/S but the data itself is serialized into a binary representation. This ultimately means less data needs to go across the wire, that data requires less client memory, and there’s less processing time for the data.

Data Management
There’s comes a point in RIA development (or client/server if that’s your customer’s background) that more complexity is introduced on the client. After all, with Flex, we now have a client that can work on data quite independent of a server after the initial request(s). How are we to be sure that the data that has changed on one client hasn’t been changed somewhere else (on another client)? Writing RPC-oriented code (the three aforementioned examples) this can get really tricky to deal with on a per application basis. The data management features of FDS abstract all this from the developer. You can literally write a client application that handles real-time synchronization across connected clients in just a few lines of code.

This description doesn’t do justice at all to the other great features that FDS can provide developers. Implicit paging through large datasets is another common use-case.

Internally the data management scenario looks very similar to the remoting option save that there’s an additional layer called an “assembler” that acts as the touchpoint between the Flex client application, the FDS installation on the server, and the server resources that are accessing data. At a low level however it is common that developers have their objects leverage JDBC to access various types of database systems to include MySQL.

Messaging
To the point of getting updates from the database to the client – the first question to ask is what is making the update to the database? Would this be another Flex application? If so, then this would fall squarely under common FDS data management features. In short, you’d get this type of cross-client update through push (or polling) automatically as a feature. If there’s another (external) process that’s updating the database, then you’ll want to leverage the capability of FDS to tie into JMS for client notification. At a high level, the process can make a change to the database and then drop a message on the queue stating that something has changed. That message will be propogated (via push most commonly) to all the clients. The clients can then take whatever action they need to update their copy of the data.

Creating Resizable and Draggable Flex Components

I wanted users of a Flex application to be able to move and resize components at runtime so that the user could lay out the components however they wanted. This application lets the user move, resize, and minimize Panel containers much in the way you can in any windowing environment. While this application uses Panel containers, you could generalize it to for any Flex components.

To use it:

- Click down in the header area of a Panel to drag it around the application. Release the mouse when it is where you want it.

- Click down on the lower-right corner of the Panel to resize it. Release the mouse when it is the size you want. You can not set it to a size smaller than 50 pixes high and 150 pixels wide.

- Click the Minimize/Restore icons to hide/show the body area of the Panel.

The following application shows this functionality:

This application uses three files:

* CanvasDD.mxml – Main app that handles the drag/drop and resizing events. Resizing works for any component that dispatches a ‘resizeButtonClicked’ event; there is nothing in the Panel needed to resize it except the logic to determine when to dispatch the ‘resizeButtonClicked’ event.

* myComponents/DragPanel.as – Custom Panel component that adds the minimize/restore functionality, and dispatches a ‘resizeButtonClicked’ event to the main app to handle resizing.

* myComponents/RubberBandComp.as – Custom UIComponet that draws the rubber band on top of a Panel during resizing.

You can download the source code for these examples.

Chart data drill down examples

One thing the chart documentation lacks is examples of drilling down into data. This is critical for making charts that are interesting and fun to interact with. This blog entry includes two examples of drilling down into data.


Example #1

Here’s an example that uses the Event object to get a reference to the clicked ColumnSeries. It then drills down into the single ColumnSeries by replacing the chart’s series Array with the single ColumnSeries in the chart. When you click a column again, the chart returns to its original configuration with all ColumnSeries.


Example #2

The following example is similar to the previous example in that it drills down into the assets of a fictional person’s net worth. In this case, though, it shows the value of the asset classes for the clicked-on month in the drill-down view rather than the change over time of a particular asset class.

This example uses the HitData object’s item property to access the values of the current data provider. By building an Array of objects with the newly-discovered data, the chart is able to drill down into the series without making calls to any external services.


More Info

You can download the documentation
and the source code for these examples.

Of course, these examples are nearly as exciting as what is going on over at Quietly Scheming, but hopefully they will get you started.