Tag Cloud

Alas, LCDS 3 doesn’t support the notion of transaction (in the sense of a Database Transaction). I assume that somewhere deep within the system transactions are used to ensure correctness of data in the db, but none of this is exposed to the user. Fortunately, it is possible to bundle up a bunch of updates on the client and push them all at once to the server. Fake transactions, as I like to call them, are quite useful. But they can also be dangerous because they are not really transactions (hence the fake part), and don’t always work as you would hope.

Fake It

Faking a tranaction is done using the autoCommit property on a generated service. According to the docs, setting autoCommit to false blocks Data Management from pushing any changes to the server until commit() is called manually.

“…set a DataService component autoCommit property to false to allow only manual calls to the commit() method. It is important to set autoCommit to false when you are going to make more than one change…so that the DataService component can batch those changes and send them in one batch to the destination.”

So to make life easy, I made a simple static function that does the autoCommit gymnastics:

In this case, the fake transaction is used to ensure the team is renamed and the player is added. Both operations occur together, so it should not be possible to have the new player on the old team, or have the renamed team without the new player.

Warning! Danger!

Experience has shown me that fake transactions don’t always work as one would expect if they were real transactions. Sometimes, particularly when you are manipulating entities already under Data Management, it seems like operations are not really batched but instead executed one at a time. Thankfully, it appears that LCDS is order preserving, and by that I mean it doesn’t magically re-order things. LCDS always executes operations in the order they come in. I can only recommend you test your application vigorously to ensure what you expect to happen actually happens (FlexUnit4 is pretty awesome for testing async backends).

Files

I just wrote about how to handle special characters in Flex 4 when written as HTML entities in MXML. Now I’ve moved my data with the special characters out of MXML and down into a MySQL database. Data access is provided by a vanilla LCDS 3 backend. I now have a very different problem than what I had before: How do I get UTF-8 data out of the database with LCDS and onto the display?

MySQL and UTF-8

In theory, LCDS is perfectly happy with special characters and foreign languages (here’s a link to supported characters sets in LiveCycle ES2). So this time around, our problem has nothing to do with Flex 4 or LCDS, instead it’s all about the database. For our example, we’ll skip the pure model driven development route and just start with a simple database with a single players table.

I put some extra special characters into the INSERT statements just for fun.

Digging Deeper: When connecting to MySQL from the commandline you can use the --default-character-set=utf8 option to force your terminal to show UTF-8 characters correctly.

LCDS and UTF-8

Now that the database is correctly setup to handle UTF-8, the rest of the LCDS setup is straight forward (see my getting started part 1 and part 2 posts). Create a new LCDS webapp via copy-and-paste from the template app, then fire up Flash Builder 4 and get to work. In the Modeler plugin, configure a new RDS connection and just drag-and-drop the players table into the model.

Here’s a screenshot of our LCDS model:

And here’s a screenshot of the running app (remember this is backed by LCDS, so no running demo):

Again, no magic here, I use a simple getAll() query to retrieve the entire players table then feed it into a List via the CallResponder‘s lastResult property.

Conclusion

So the moral of our story is: if you correctly configure your database to support UTF-8 and you correctly get UTF-8 data into your tables, then everything just works. LCDS will transparently get data out of the db and Flex will transparently get it onto the screen.

Files

Once upon a time, in what now seems to be a prior life, I became a published author when my thesis hit the university press. That time has come again. After much effort, the second longest thing I have ever written has been published by InsideRIA. I wrote a two-part article titled Getting Real with LCDS 3 (Part 1 & Part 2) that covers the basics of model driven development with LCDS 3. Yeah me.

More Fun with LCDS

Since I’m such a new-stuff-loving guy I can’t help but return to the backend after a few months on the frontend with various Axiis visualizations (here & here) and a GTween animation (here). So, it’s back to LCDS. Of course, since I last wrote about LCDS, Adobe has shipped LCDS 3, but thankfully they still provide a free developer trial. This time around, I’ll look at LCDS and MySQL Views.

Create Database and Tables

First, let’s set the scene by constructing a new database and some tables. Here’s the database:

Lastly, we insert some sample data into the database via a script. The final result is our familiar teams-and-players database, but this time with an additional games table.

MySQL Views

A database view is one way to push logic and computations down from the application layer into the database. A judicious use of views can really help keep the application layer nice and clean. But much like database de-normalization, adding views to the database often feels like premature optimization, so be careful. LCDS and the Modeler plugin treat database views just like tables, so everything just works (sort of).

MySQL is a full-featured database that provides a simple CREATE VIEW syntax. For our purposes, a view can be thought of as nothing more than another table that is constructed from other tables via a SELECT statement. Because of this, database views are sometimes called virtual tables. The SELECT statement used to construct the view is often very complicated, involving multiple tables, joins, functions, expressions, and more.

For our example, we will construct two views. First, the team_summary view packages up information from the teams and players tables:

The application is very simple. When a user clicks on a team, the teamChangeHandler() is called. The handler queries the LCDS backend and sets the CallResponder‘s token property. When the asynchronous backend eventually returns some data, the data is forwarded to the appropriate result handler. In the result handler, the incoming PASO has it’s properties are formatted and then assigned to the matching form element for display.

Just drag tables from the RDS Dataview to add them to the modelenlarge

Browse the generated services and code

Once the model is updated, the builder automatically generates standard CRUD services. Switch back to the Flash Builder perspective, and you can view them in the Data/Services tabenlarge

The generated code is available in the Package Explorer. Files you don’t want to touch are prefixed with an underscore. The other files, like Player.as and PlayerService.as are available for you to customize.enlarge

Conclusion

With the beta release of LiveCycle Data Services 3, Adobe has changed the game by bringing model driven development to the forefront. The geniuses from the entity formerly known as Macromedia have put together a compelling product if you are in the business of enterprise RIAs like us. Here are a few choice words from Adobe about the beta release.

Now on to the fun part: playing with our new toy. Vroom, vroom! In Part 1, I’ll walk through getting started with LCDS sitting on top of MySQL. Part 2 covers using the Modeler plugin in Flash Builder 4 to bring the dream of model driven development to reality.

NOTE: This article was written for LCDS 3 Beta 1, but I assume it’s mostly relevant for Beta 3 (released at AdobeMAX) and all future versions of LCDS 3.

NOTE 2: The Mac installer for Beta 3 (released at AdobeMAX) does not included the integrated Tomcat which is a huge pain in the ass for all Mac developers. I recommend you grab the integrated Tomcat out of the Windows installer.

Setup MySQL

Install & start MySQL (this is an exercise for the reader, I remember it being a little painful on my Mac)

Digging Deeper: Setting up a database is required, but setting up tables or inserting data is not. You can use the model driven development features of LCDS (and the Modeler plugin) to create all of your tables and data.

Setup LCDS

Run installer & choose to install with bundled Tomcat (on Mac this installs to /Applications/lcds and the bundled Tomcat to /Applications/lcds/tomcat)

Create a new LCDS app, by copying the template app (in lcds/tomcat/webapps/lcds) to a new folder:

cd /Applications/lcds/tomcat/webapps

cp -R lcds myapp

Enable RDS (Remove Dev Services) – This enables some dev only stuff like updating the database tables on the server directly from Flash Builder. For obvious security reasons, RDS would never be running in a production environment.