Professional Documents
Culture Documents
ADOBE
®
WITH
FREE DVD
$695
VALUE
Written by
Yakov Fain
Dr.Victor Rasputnis
AnatoleTartakovsky
Guest chapter by Ben Stucki
www.theriabook.com
The World’s Leading i-Technology Publisher Forewords by Bruce Eckel & Matt Chotini
RIA WITH ADOBE FLEX AND JAVA
ii RIA WITH ADOBE FLEX AND JAVA
RICH INTERNET APPLICATIONS
ADOBE
®
WITH
First Edition
SYS-CON Media
Woodcliff Lake, NJ 07677
This book may not be reproduced in whole or in part in any form or by any means,
electronic or mechanical including photocopy or any information storage or
retrieval system, without written permission. For further information
about SYS-CON Books and magazines write:
SYS-CON Media, 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677.
Adobe and Adobe products are either registered trademark or trademarks of Adobe
Systems Incorporated in the United States and/or other countries.
Throughout this book, tradenames and trademarks of some companies and products
have been used, and no such uses are intended to convey endorsement of or other
affiliations with the book.
SYS-CON, the editors, and the authors of this book specifically disclaim all other
warranties, express or implied, including but not limited to implied warranties of
merchantability and fitness for a particular purpose with respect to the sample code,
applications or programs, the program listings in the book, and/or the techniques
described in the book, and in no event shall SYS-CON, the editors and/or the authors
be liable for any loss of profit or any other commercial damage, including but not
limited to special, incidental, consequential, or other damages.
ISBN 0-9777622-2-X
098765432
Dr. Victor Rasputnis is a Managing Principal of Farata Systems. He’s responsible for providing ar-
chitectural design, implementation management, and mentoring to companies migrating to XML
Internet technologies. He holds a PhD in computer science from the Moscow Institute of Robotics.
You can reach him at vrasputnis@faratasystems.com.
Anatole Tartakovsky is a Managing Principal of Farata Systems. He’s responsible for the creation of
frameworks and reusable components. Anatole has authored a number of books and articles on
AJAX, XML, the Internet, and client/server technologies. He holds an MS in mathematics. You can
reach him at atartakovsky@faratasystems.com.
Ben Stucki is a software engineer at Atellis, a Washington, D.C., based firm that specializes in de-
veloping rich Internet applications and products. As part of the core development team at Atellis,
Ben mixes his knowledge of back-end application development and interactive user interfaces to
engineer next-generation Flex applications and components. Ben is also an active member of the
Flash and Flex communities and manages a number of open source projects.
CONTENTS
ACKNOWLEDGMENTS xix
FOREWORDS xxi
CHAPTER 1 1
Architecture of Rich Internet Applications 1
RIA Platforms: The Major Choices 4
Adobe Flex 2 4
Java 6
WPF 7
AJAX 7
AJAX Shortcomings 8
Other RIA Solutions 10
OpenLaszlo 10
GWT 10
Nexaweb 11
Canoo 11
Backbase 11
Apollo, Desktop 2.0, and the Bright Future 12
Some Pragmatic Flex/Java Considerations 13
The Learning Curve: Reuse of Skills and Code 13
Application Security 13
Flex GUI Performance 14
Shorter Development Cycle 14
Room for Improvement 14
Connection Management 14
Flex and Agile Development 15
Summary 16
CHAPTER 2 19
Getting Familiar with Flex 19
Free Flex 2 Ingredients 20
Downloading the Flex 2 Framework 21
Hello World in MXML 22
Specifying Compiler Options 24
Building and Deploying Applications with Ant 25
Building HelloWorld with Ant 25
Frame Rate 27
Namespaces in MXML 29
From Hello World to a Calculator 30
Adding Some ActionScript 33
The First Date with Events 34
Why ActionScript 3.0? 36
Comparing ActionScript 3.0 and Java 5 37
Flex Framework API Documentation 42
Separating Design and Development 43
Working with Display Objects in ActionScript 45
The Application Loading Process 45
Summary 47
Endnotes 47
CHAPTER 3 49
Flex Builder Development Environment 49
Installing and Configuring Flex Builder 50
Yet Another Hello World 50
Working with the Source Panel 55
Running HelloWorld 56
Building the Project 57
Flex Builder-Generated Files 57
Running Applications in Flex Builder 58
Simple Event Processing 59
CHAPTER 4 79
Learning Flex Through Applications 79
ActionScript Dynamic Classes 80
Methods, Functions, and Closures 83
Function Parameters 84
Getters and Setters 85
Functions as Objects 86
Closures 86
Asynchronous Programming 91
Data Binding 92
Binding in MXML 93
Binding Expressions 94
What’s Under the Hood? 95
Binding in ActionScript 97
Binding Inside a String and Application Parameters 97
Is Data Binding a Silver Bullet? 99
Program in Style or an Elevator Pitch 100
From COBOL to Flex 101
From Java to Flex 101
From Smalltalk to Flex 103
Object-Oriented ActionScript 104
Program Design with Interfaces and Polymorphism 106
Polymorphism Without Interfaces 110
Namespaces in ActionScript 112
Using Flex with JavaServer Pages 115
Retrieving Data from JSP 115
Sending Data from Flex to JSP 118
E4X, Data Binding, and Regular Expressions 122
CHAPTER 5 155
A Complete Application with RPC Communications and JMS 155
Multi-Tier Application Development with Flex 156
Designing a Stock Portfolio Application 156
Adding a Data Grid 159
Adding the Charting Component 167
Chart/DataGrid Toggling 171
Dealing with Financial News 178
Configuring the Server-Side Destination and Proxy 181
Processing the News Feed 181
Introducing Item Renderers 183
Programming Master-Detail Relationships 185
Adding the JMS Feed to the Stock Portfolio 189
Introduction to the Java Naming and Directory Interface 189
Introduction to the Java Messaging Service 190
Two Modes of Message Delivery 190
JMS Classes and Terms 191
Types of Messages 191
How to Publish a Message 191
How to Subscribe for a Topic 192
Integrating Flex and Java Messaging Services 193
Configuring Flex Messaging Destination 193
Configuring ActiveMQ JMS 195
Writing the TickerFeed Java Program 196
Modifying the Flex Client to Consume Messages 199
Summary 202
CHAPTER 6 205
End-to-End Rapid Application Development with Flex
Data Management Services 205
Flex Data Management Services: Flex Remoting on Steroids 206
Flex Data Services and Automation: Problem Statement and Solution 206
A “Manual” FDS Application 207
Building the Client Application 208
Creating Assembler and DTO Classes 212
Implementing the Fill-Method of the DataServices Data Access Object 215
Implementing the Sync-Method of FDS Data Access Object 217
Implementing Update, Delete and Insert Methods 218
Introducing Metadata 221
Introducing Templates 222
Metadata for Input Parameters 224
Templates for Implementing the Fill Method 224
Completing the Fill Method 226
Setting JDBC Statement Parameters 229
Reading the Result Set Record 229
Templates for Implementing Sync-Method 232
Completing the Sync Method 235
The Template for the doCreate() Method 238
Who Owns the DAOFlex Templates? 242
Rapid Application Development with DAOFlex 242
DAOFlex Directory Structure and Configuration Files 243
DAOFlex Project Setup 245
Running the DAOFlex Code Generator 246
Testing and Using DAOFlex Output 248
Summary 248
Endnote 249
CHAPTER 7 251
How to Write Your Own Data Management Services 251
Setting the Scene 252
Introducing Destination-Aware Collections 253
Making a Destination-Aware Collection 255
Sensing Collection Changes 259
Anatomy of Managed ActionScript Objects 262
The Two Faces of ChangedObject 266
Tracking Collection Changes 267
Making Collection Updateable 278
CHAPTER 8 311
Enhancing and Extending Flex Controls 311
ComboBox Challenges 312
Making the Value Property Writeable 314
Adding a dataField Property 318
ComboBox with a Multi-Column List 321
Populating a ComboBox with Server-Side Data 325
Encapsulating a Remote Object Inside the ComboBox 332
Adding Auto- complete Support to TextInput 339
Integrating DataBase Search and ComboBox with Autocomplete 343
Separating Business Resources from Generic Component Code 353
Building a Business-Specific ComboBox 354
Building and Using the Resource Classes 356
Summary 361
Endnotes 362
CHAPTER 9 365
Trees with Dynamic Data Population 365
Basics of Tree Control 366
The Role of dataDescriptor 369
Moving to the Real Asynchronous World 370
No More Fake Remoting! 374
Design Patterns in Our Life 374
Data Transfer Object 375
Data Access Object 376
Asynchronous Completion Token 377
Assembler Design Pattern 377
Façade Design Pattern 378
CHAPTER 10 399
Working with Large Applications 399
Deployment Scenarios 400
Application Domains 101 401
Runtime Shared Libraries 101 401
SWFs and SWCs: What’s Under the Hood 403
Making the FlexLibrary.swc 404
Making a FlexApplication Application 405
Static versus Dynamic Linking: Development Perspective 408
So, You Say Dynamic Linking? 409
Self-Initializing Libraries – Applications 412
Recap of the Technique 416
RSL versus Custom Loading of the Dynamic Code 421
The Custom Loading Example 422
Embedded Applications and the SWFLoader Object 428
Modules and ModuleLoaders 433
When Size Matters 438
Summary 438
Endnotes 439
CHAPTER 11 441
Advanced DataGrid 441
Making DataGrid Destination-Aware 442
Formatting with labelFunction 444
Formatting with Extended DataGridColumn 446
Introducing a Component Manifest File 447
More on Customizing the DataGridColumn 449
Improving FormattingManager 450
CheckBox as a Drop-In Renderer 457
DataGridColumn as ItemRenderer’s Knowledge Base 458
Nitpicking CheckBox 461
RadioButtonGroupBox as Drop-In Renderer 467
Computed Column Color 476
CHAPTER 12 519
Logging and Debugging Flex and Java Applications 519
Logging 520
Configuring Web Application (Server) Logging 520
Client-Side Logging 522
Using the Logging API 523
Server Log Target 524
Server Log Target Using Plain HTTP 526
The Client-Side Target 528
Creating a Tracing Console for LocalConnection 530
The RIA Aspect of Flex Logging 532
Debugging 534
Remote Debugging 534
Using Eclipse WTP for Debugging Java EE Servers 537
Configuring Tomcat 538
Deploying a Web Application Locally 541
Summary 541
CHAPTER 13 543
Building a SlideShow Application 543
Application Overview 544
Developing the SlideShow Component 545
Loading SlideShow Data 547
Animating the SlideShow 550
Adding Interactive Thumbnail Navigation 552
Developing the SlideShow Player Application 559
Developing the SlideShow Creator 560
Integrating with Flickr Web Services 561
Editing SlideShow Data 563
Developing the SlideShow Preview 566
Summary 570
CHAPTER 14 573
Developing Custom Charts 573
How to Develop a Chart from Scratch 575
Working with Larger Data Sets 580
Adding a Vertical Line 582
Non-Typical Use of Skinning 583
Adding Scrolling and Zooming 592
Summary 601
CHAPTER 15 603
Integration with External Applications 603
Overview of Flash External Interfacing Methods 604
Using External API 605
Two-Way Flex – OWC Spreadsheet Integration 613
Flex Application for OWC Spreadsheet Integration 615
HTML Template Embedding Our ActiveX Components 621
Making Flex and Spreadsheet Talk 626
Handling Flex Metadata Notification 630
Synchronizing Spreadsheet OWC with Flex Data Changes 633
Synchronizing Flex with Spreadsheet Data Changes 636
One-Way Flex-Excel Integration via the System Clipboard 643
Flex Embedded in Microsoft Excel 649
XML Format of External API 655
LiveLink: Standalone Flex - Excel 658
LocalConnection 101 658
Flex Excel Agent Application 662
Flex Standalone Application 668
Excel Worksheet – The Flex Agent Host 674
Getting in the Nitpicking Mood 690
Summary 693
Endnotes 695
INDEX 697
Acknowledgments
Writing a technical book requires dedication, discipline and wish power. But most important, it
requires support from family members, and we’d like to thank our families for understanding and
especially our children, who got used to the fact that their fathers were glued to their computers,
even in the evenings.
We’d like to thank all members of the vibrant and very active online Flex community for their drive,
energy, and eagerness to contribute to the success of the tool of their choice.
We’d like to thank the top-notch Flex professional Valery Silaev for his valuable input to the chapter
on integration with external applications, which is one of the most complex chapters in this book.
We’d like to thank a charting guru Vadim Sokolovsky from GreenPoint for his help in writing the
chapter about developing custom charting components.
We’d like to thank our contributing author Ben Stucki for creating a very good slideshow compo-
nent and writing a chapter for our book.
And mainly, we thank you, our readers, for considering this book.
FOREWORD
It’s risky to try to define Web 2.0 (which may or may not be a trademark of O’Reilly Media Inc.),
but the description I’ve heard that makes the most sense is that Web 1.0 always required a visit to
a server to make any changes to what the user sees, whereas Web 2.0 downloads some code to the
client so that, for some transactions, data can be sent to the client instead of a whole page. The
result is a richer and faster user experience. I like this definition because it gives me something
concrete to evaluate.
This is a logical next step now that the primitive, page-at-a-time Web has proven its success. At
the same time, it’s ridiculous that we should have to do this all over again. After all, before the Web
there was a lot of brouhaha about client/server, where the server runs code that makes sense on
the server, and the client runs code that makes sense on the client. The idea was a lot simpler than
all the marketing noise would have you believe, but it was still a good idea.
If the definition above is valid, then one could argue that the genesis of Web 2.0 is AJAX (Asynchro-
nous JavaScript And XML). Of course, JavaScript has been around since, effectively, the beginning
of the Web, but the browser wars made JavaScript inconsistent and thus painful to use. A key part
of AJAX is that someone has gone to the trouble of figuring out cross-platform JavaScript issues so
that you can ignore differences between browsers.
There are two problems with this approach. The first is that JavaScript is limited in what it can do.
AJAX is an excellent hack that gets the last bit of mileage out of JavaScript, but it’s a hack nonethe-
less, and the end is in sight. The second problem is that you’re relying on AJAX libraries to handle
cross-browser issues, and if you want to write your own code, you have to become an expert on
these issues, and at that point AJAX’s leverage goes out the door. It’s too much trouble and a waste
of time to have to know all the gratuitous differences between different versions of what is sup-
posed to be the same programming language.
You could argue that the solution is Java, because Java is designed to be the same on all platforms.
In theory this is true. In theory, Java should be the ubiquitous client-side platform. In theory, Lear
Jets and bumblebees shouldn’t be able to fly, and lots of other things should be true as well, but for
various reasons Java applets, after 10 years, don’t dominate client-side automation, and it seems
unlikely that they will anytime soon.
In practice, Java dominates on the server, so this book takes the practical attitude that most people
will want to continue writing the server side using Java. But for a rich client, this book assumes
that you’ve seen that other technologies will either run out of gas or involve an installation process
that consumers resist (regardless of how “simple” that installation process claims to be). Because
the Flash player is installed on some 98% of all machines and is transparently cross-platform, and
because people are comfortable with the idea of Flash and don’t resist installing or upgrading it,
this book assumes that you want to create your rich client interfaces in Flash.
The only drawback to this approach is that, historically, Flash applications have been built with
tools that make more sense to artists and Web designers than they do to programmers. This is
where Flex comes in. Flex is a programming system that produces compiled Flash applications.
The programming language in Flex, called ActionScript, is based on ECMAScript, the ECMA-stan-
dard version of JavaScript, so any JavaScript knowledge you might have isn’t lost. You can learn a
single programming language and ignore cross-platform issues.
Flex comes with a library of UI widgets, with a potential marketplace for third-party widgets. As
you’ll see if you look at the Flex demos and tours on www.adobe.com, these widgets can be very
functional as well as appealing, so it’s possible to assemble a very attractive and professional rich
client without much effort.
One of the main reasons that you might not have tried an earlier version of Flex is that the original
pricing model meant that you couldn’t experiment with the tool without paying a hefty fee upfront.
A big change has occurred since then, because with Flex 2 and beyond, you can use any plain text
editor along with the free Adobe compiler and Flex Framework components to create your rich In-
ternet applications. This includes the ability to host static Flash applications on your server. Adobe
makes its money on the more powerful dynamic application server (which dynamically creates
and delivers Flex applications) and the Eclipse-based Flex Builder environment, which simplifies
the creation of Flex applications.
I’d like to think that I had something to do with the migration to the free command-line compiler
for Flex, since I spent an hour or so on the phone trying to convince a Flash VP (before Adobe
bought Macromedia) that to become popular, programmers needed to be able to experiment with
the platform freely. However, the result is more than I hoped for.
I think that Flex for rich Internet client applications can become a major player. Its easy cross-
platform support removes many programmer headaches, the component model offers powerful
library reuse, and the result produces a very comfortable and appealing interface for the client to
use. Because this book teaches you how to use Flex along with the dominant server-side develop-
ment tool (Java), it’s an ideal introduction if you want to learn how to leverage these technologies.
Bruce Eckel
Author, Thinking in Java 4th Edition
www.MindView.net
FOREWORD
At the beginning of the decade Macromedia coined the term rich Internet application (RIA) to
describe the future of applications. An RIA is a Web experience that’s engaging, interactive, light-
weight, and flexible. RIAs offer the flexibility and ease of use of an intelligent desktop application
and add the broad reach of traditional Web applications. Adobe Flex 2 has established itself as the
premiere platform for delivering these experiences.
The Flash Player is an ideal runtime for a rich Internet application. Installed on 98% of Web-enabled
desktops, the Player has a reach far beyond any individual Web browser or other client technology.
For years, developers took advantage of this by using the Macromedia Flash tool to build com-
pelling, data-driven applications. But the Flash programming model wasn’t for everyone. When
building what would become Flex 1.0, we geared the programming model towards developers who
had more of a programming background, especially Java Web application developers. We designed
a tag-based language called MXML and influenced the evolution of ActionScript 2.0 to appeal to
developers used to object-oriented programming. Flex 1.0 and Flex 1.5 were very successful for
Macromedia, reaching hundreds of customers in 18 months, impressive for a v1 product with an
enterprise price tag.
But we realized that to reach our goal of a million Flex developers we needed to make some drastic
changes in the platform. Our first change was to rewrite the virtual machine in the Flash Player
from scratch and improve the language at the same time. The AVM2 inside Flash Player 9 is orders
of magnitude faster than the previous virtual machine and uses less memory. The ActionScript 3.0
language is now on a par with other enterprise development languages like Java and C#. We then
re-architected the Flex Framework to take advantage of the improvements our underlying founda-
tion exposed.
Next, as Adobe, we decided to make the Flex SDK completely free. Developers can now create,
debug, and deploy Flex 2 applications at no cost. The Flex SDK provides tools for compiling MXML
and ActionScript into deployable applications, building reusable libraries, a command-line debug-
ger, and a documentation generator. We made this move to remove all the pricing barriers to be-
coming a Flex developer. We hope that this jump-starts the growth of the Flex community, and we
know it’s already paying off as we watch the increase in traffic on our forums, blog postings, and
mailing list participation.
Of course any development experience is improved if you have a robust development environment,
and we built the Flex Builder IDE for that purpose. We decided to leverage the Eclipse platform for
Flex Builder because it’s familiar to many of the developers we envision using Flex, and also gave us
a great starting point to building an enterprise-quality IDE. Flex Builder provides project manage-
ment, code hinting, compilation, visual debugging, and perhaps, most important, a Design View
for rapid development of your user interface. While using Flex Builder is certainly not required to
build your Flex applications, we think your experience will be more enjoyable if you do.
All of the enhancements mentioned so far address the development of the Flex application, but
don’t mention one of the true innovations in the Flex 2 release, Flex Data Services. Flex Data Ser-
vices is designed so you can easily integrate a Flex application into a new or existing J2EE system.
The remoting service lets your Flex application make calls to POJOs or EJBs. The messaging service
lets your Flex application connect to JMS message queues and topics and lets those systems push
messages to all Flex clients. The Data Management Service manages data synchronization between
data on the server and your Flex applications. When you make a change to data in one Flex ap-
plication, it’s immediately reflected in other applications and persisted to your server. The system
is scalable, highly configurable, and integrates well into any transaction management you might
have, making this system a must for data-intensive applications.
This was certainly the largest project I’ve ever worked on. We had engineers on both coasts of the
U.S. as well as Bangalore, India, working together on this immense system. At any hour during a
24-hour day someone on our team was actively developing. Of course it’s not just the engineers, or
even just Adobe employees who contributed to the development of Flex 2. From the moment we
released our public alpha we’ve been getting great feedback from the larger community.
The principals of Farata Systems have been key contributors to Flex’s success via their participa-
tion in our beta programs, posts to community forums, public presentations, and blog postings.
And now, Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky are capping those contributions
with Rich Internet Applications with Adobe Flex and Java: Secrets of the Masters. This may not be the
only resource for learning how to experiment with Flex, but it will be an important one for building
real-world Flex applications.
The Flex product team spent almost two years taking what we learned from Flex 1 to build a tech-
nology that would revolutionize the way developers create applications that engage with their us-
ers and with information. Now that technology is here in the form of Flex 2 and this book is here to
help you take advantage of all that power. There’s a lot to learn, but Yakov, Victor, and Anatole have
done an excellent job introducing you to everything you need to know to build a robust applica-
tion. We at Adobe can’t wait to see what you create.
Matt Chotin
Product Manager
Adobe Systems, Inc.
October 2006
Historically there have been major shifts in the software industry. We moved from mainframes with
dumb terminals to client/server. Users gained in convenience and productivity, and mainframe
systems were patronizingly labeled as legacy. With the availability of the World Wide Web industry,
visionaries turned the tables; vendors and corporate IT had been eager to get rid of the complexity
of client/server version management and technologists were sold on multi-tier computing. This
time client/server was called legacy. And to rub it in, good old desktop applications were labeled
“fat.” Excited with server multi-threading, messaging, persistence, and similar toys, we pretend
not to think that, at the end of the day, we’d have to trade user experience and productivity for the
transparency of application deployment. And to make us feel better, we proudly called the new
breed of applications “thin client.”
Meet the new challenge: we’re entering an era of rich Internet applications (RIA), which restores the
power of desktop applications…inside downloadable Web page. RIAs run in a virtual machine (i.e.,
Adobe Flash Player or Java VM) and have the potential of becoming a full-featured desktop applica-
tion soon. As opposed to just simply displaying Web pages delivered from some server machine,
RIA really run on the client. Many of the data manipulation tasks (sorting, grouping, and filtering)
are done locally like in the old client/server days. Déjà vu indeed! Industry analysts predict that in
three or four years most newly developed projects will include RIA technologies.
A rich Internet application combines the benefits of using the Web as a low-cost deployment model
with a rich user experience that’s at least as good as today’s desktop applications. And, since RIAs
don’t require that the entire page be refreshed to update their data, the response time is much
faster and the network load much lower. Think of a globally available client/server application.
Let’s illustrate the difference between “legacy” Web and RIA with a shopping cart example. Non-
RIA Web applications are page-based. Since HTTP is a stateless protocol, when the user moves
from one page to another, a Web browser doesn’t “remember” the user’s actions on the previous
page. As a common treatment of this “amnesia,” a user state is stored on the server side in the form
of the HTTP session.
At the checkout the server retrieves selected items from the session object and sends page #5 to the
user for shipping info. The data entered travels back to the server for storage, and the client gets
back page #6 for billing information. After that page #7 will confirm the order and only then goes
to the order completion page.
This simplest of online purchases consisted of seven roundtrips to the server. In a striking dif-
ference to desktop applications, a few-seconds-per-page refresh is considered fast(!) for a typical
Web application, and the commonly acceptable delay is up to eight seconds. Is the user motivated
enough to complete the purchase? Think again, because your system gave him a chance to re-
consider seven times in a row. Now assume that the network and/or server are slow. Result? Your
potential buyer went elsewhere.
Rich Internet applications eliminate the roundtrips and substantially improve system performance
by doing a lot more of the processing on the client than a thin client Web application. Besides, RIAs
are stateful: they accumulate the information right on the client! To put it simply, RIA isn’t a set of
pages controlled by the server; they are actual applications running on the client’s computer and
communicating with servers primarily to process and exchange data.
Both consumer-facing and enterprise applications benefit from being RIAs. It’s a well-known fact
that e-commerce Web sites such as online ticket reservation systems and online retailers are losing
revenue because users abandon shopping carts on non-responsive Web sites during the checkout
process. Such Web sites result in lots of calls to the call center, a major operational expense in and
of itself. The performance of any system operated by employees is critical to company productiv-
ity and RIAs provide a performance boost over HTML applications, while reducing operating and
infrastructure costs. Finally, introducing well-designed RIAs lets companies build better “mouse-
traps.”
Macromedia introduced the expression rich Internet applications back in 2002 in contrast to the
bleak condition of the “legacy” Web, known today as Web 1.0. And yet the first RIA applications
were born as early as 1995 when Java was created. Java’s initial popularity manifested itself in a
wave of small downloadable programs called Java applets. Applets, created with Java AWT (and
later Swing) libraries, were run by the browsers’ Java Virtual Machine (JVM). Ironically, the very
technology that made Java popular wasn’t exploited and today Java shines mostly on the server side
and in mobile devices.
In 2004 Tim O’Reilly coined the catchy term Web 2.0. Which sites qualify for Web 2.0 status has
never been clearly defined. If someone sees a cool-looking Web site, it’s invariably called Web 2.0.
Labeling better-looking Web products “2.0” is pretty popular these days. Often it refers to social
engineering sites that let people collaborate and build the site’s content themselves. Wikipedia
has a lengthy article on Web 2.0 that may give you some idea what this term means. See http://
en.wikipedia.org/wiki/Web_2.0.
There’s now Web 3.0 too, which refers to the Semantic Web…but let’s stop playing this name game
and return to the main acronym of this book: RIA.
Using Flex you can create an ActionScript application for the ubiquitous Flash Player, a high-per-
formance multimedia virtual machine that runs bytecode files in the SWF format (pronounced
swif ). The player’s JIT compiler converts the SWF bytecode to native machine code for fast perfor-
mance. The later facility is specific to Flex 2, available since 2006. Although early versions of Flex
were out in 2004, they didn’t support just-in-time compilation.
A Java programmer can create Java applets. As mentioned, this solution has been available since 1995.
Windows Presentation Foundation (WPF) was released as part of .NET 3.0 in November of 2006
and can be used to create both Internet and desktop applications.
Finally, there’s AJAX, aka DHTML, circa 1998. This solution was recently boosted with XMLHttpRe-
quest API support for all major browsers. AJAX served as a wake-up call for the user and developer
communities. It is often the first step on the migration path from the legacy Web to the world of RIA
despite being seriously handicapped by having to support browser incompatibilities and a poor
programming model.
Adobe Flex 2
Flex 2 applications run cross-platform in a ubiquitous Flash Player 9 that’s a lightweight virtual
machine. The platform includes:
• An XML-based language called MXML that supports the declarative programming of GUI
components targeting designers
• The standard object-oriented programming language, ActionScript 3.0, based on the latest
ECMAScript specification
• Server-side integration via Flex Data Services (FDS) giving client applications transparent ac-
cess to the world of J2EE
The Flex 2 platform is easily extendable and integrates well with server-side Java, ColdFusion, PHP,
Ruby, ASP, and the like. The upcoming release of Adobe Apollo will allow the creation of a desktop
application based on Flash Player, Flex, PDF, and HTML.
The SWF file format is open, and there are third-party open source products that offer tools for
creating RIAs delivered by Flash Player like OpenLaszlo from Laszlo Systems.
As opposed to the last version, Flex 2 offers a way to create RIAs without incurring hefty licensing
fees. This is what comes at no cost:
The process of creating a basic Flex 2 application consists of the following steps:
If you use the Flex Builder IDE, you can apply drag-and-drop techniques. Alternatively, you can
write the MXML as text.
2. Write the code in ActionScript per your functional specification, for example:
3. Compile the code. Flex compiler automatically converts MXML into ActionScript and creates
bytecode output in the form of an SWF file to be run in Flash Player 9 or above. You’ll enjoy a
fully automatic compilation process if you use the Flex Builder IDE.
4 Deploy the SWF file and the wrapping HTML page in the Web server of your choice. The de-
ployment process and creating the wrapped can be completely transparent if you use the Flex
Builder IDE.
There is a Flex Online Compiler Web site where you can try writing Flex code online without install-
ing anything on your computer. There are even code snippets ready to be modified and run. See
http://try.flex.org/.
More advanced Flex applications can include interaction with the server-side systems through Flex
Data Services, which provides remote access to server-side Java objects and Java EE components,
extensive messaging support (including JMS integration), synchronization with persisted data,
and integration with other persistent technologies.
Java
Even though the Java programming language became popular largely because of applets and the
famous dancing Duke (http://java.com/en/download/help/testvm.xml ), applets haven’t become
Java’s main use pattern. The main reason: the large footprint of the required JVM (currently 16MB).
And there are other drawbacks. For instance, although Java Swing was meant for a platform-inde-
pendent look-and-feel, absent any good-looking off-the-shelf GUI widgets it was hard selling it to
the public. In this regard the Flash and Flex creators did a much better job with their eye-candy
components. Or take audio and video integration. Today people are used to having streaming au-
dio and video components embedded in Web pages. But the multimedia Java API remains rudi-
mentary, to say the least.
There are some efforts to minimize the size of the JVM used by Web browsers and the Java Browser
Edition project now needs “only” about 3MB to run a primitive Hello World applet. But this can’t
compete with Flash Player 9, which managed to accommodate two virtual machines in a 1.2MB
download that can run any RIA, however complex.
Another issue with Java applets is that they don’t offer a seamless download of the proper version of
the JVM along with the applet. Flash Player’s express install does precisely that.
Having said that, we must acknowledge that Java Swing is a very mature and robust technology
for creating GUI applications delivered either over the Web or installed on the desktop. You can do
literally anything with Java Swing – if you can afford it. No, you don’t pay licensing fees, but because
of the longer development cycle and the need to engage expert programmers, industrial-size Swing
projects are usually quite expensive to build and maintain.
WPF
Microsoft’s Windows Foundation Platform, or WPF, become available with the release of Vista
(http://msdn2.microsoft.com/en-us/netframework/aa663326.aspx ). It uses an XML-based de-
clarative programming language called XAML to create GUIs and C# as a general-purpose pro-
gramming language. WPF is suitable for creating both RIA and desktop applications. XBAP stands
for XAML Browser Application and it’s a WPF way of creating RIAs that run in Internet Explorer.
Microsoft is planning to release a version called WPF/E that will run on some non-Windows plat-
forms. While living in a sandbox, XBAP will have access to all .NET 3.0 functionality but WPF/E
won’t. WPF/E uses XAML and JavaScript (no C#). Common Language Runtime (CLR) is the client’s
WPF engine.
To create WPF applications, developers can use Microsoft’s Visual Studio 2005 IDE with installed
.NET 3.0 extensions. The next version of this IDE, called Orcas, will include a visual GUI designer.
WPF developers use the same code base for writing XBAP and desktop applications: they just en-
close the code sections that aren’t allowed in XBAP into the ifdef blocks.
Microsoft XAML code resembles Adobe’s MXML. Even though today’s Flex 2 is a lot more mature
than WPF, Microsoft has an established developer base, while Adobe traditionally catered to de-
signers. Its main goal today is to convince enterprise developers (particularly the Java camp) that
Flex can be a tool of choice for creating business RIAs.
AJAX
While the term AJAX was coined by Jesse James Garret in February of 2005 and is partly rooted in the
asynchronous XmlHttpRequest implemented by Mozilla, lots of developers have used Microsoft’s
version of XMLHttpRequest and alternative techniques like IFrame since 1999. These techniques
facilitate synchronous and asynchronous communications between the script in a page and serv-
er-side code. The main problem with AJAX is that despite its popularity, it has no technical founda-
tion. While the other solutions we mention here are based on rock-solid virtual machines, there’s
no standard VM for AJAX. Each browser implements AJAX building blocks differently. There’s a
chance that a deployed AJAX application will require code changes with each new browser release.
Wait, let’s rephrase that: there’s a chance that deployed AJAX apps may run as is on a new browser
release. Do you want to take chances with your business?
That said, Internet giants like Google, Yahoo, and Amazon are building AJAX apps on top of their
own abstraction layers such as Google Web Toolkit (GWT). Because of the immature level of the
technology, these abstract layers need constant vendor attention as soon as changes appear.
AJAX Shortcomings
An ability to create flicker-free Web apps without buying more software is AJAX’s big appeal. You
may have heard the chant, “AJAX is free.” Here’s the simple translation: no commercial AJAX tool
is worth paying for. There are hundreds of libraries, toolkits, and control sets that give you the im-
pression that AJAX applications are cheap to develop and strategically safe since there’s no vendor
lock-in. Actually, there is vendor locking because you won’t manually write JavaScript code and will
have to pick an AJAX library of some vendor. Now think about it: starting from the ground up you
need a communication layer, messaging and remoting mechanisms, an HTTP sniffer, a library of
UI components with shared objects and event models, a visual IDE that understands these compo-
nents in design time, and a debugger that accommodates all this stuff. On top of that, there’s inter-
nationalization support, accessibility for the disabled, and support for automated testing tools.
You really think you’re safe with mix-and-match from different vendors? If the answer is yes, you
must be working for a software company in the RIA business. Coming to reality; a long develop-
ment cycle; lack of free, quality GUI components; and the shortcomings listed below make AJAX
less appealing and, actually, the most expensive way of creating RIAs.
• JavaScript development tools are limited due to the dynamic nature of the language, and
debugging any DHTML/JavaScript mix is a pain. Yes, Google’s GWT can spare you from writ-
ing JavaScript manually, but at the end of the day, it’s still JavaScript that has to be deployed in
production. When the system isn’t working and time is limited, what are you going to use to
debug it – the real page of Java mock-up?
• Tons of JavaScript source code has to go over the wire to the client to be interpreted by the
browser. We’re talking about business applications, not some proof-of-concept demo.
• Web browsers will happily display your application even if a piece of JavaScript didn’t arrive at
the client. You won’t know if a problem exists until you execute the particular use case.
• A simple right-click followed by the “View Source code” menu option would reveal your busi-
ness application code. Better yet, all this code resides as plain text in the browser cache on
disk. Because of this, you have to drop all the code comments and use obfuscators to protect
your code from being stolen.
• HTML rendering is slow: think of a data grid that contains 5,000 records. Where’s your mutual
fund report?
• The code is more vulnerable to hacker attack, a fact that was proved recently by a worm that
stole a bunch of mail addresses from Yahoo address books.
• AJAX doesn’t support server push. The server-side application can’t publish the data directly
to the client. AJAX applications have to poll the data from the server at specified time intervals
without knowing if the data is there or not.
Dion Hinchcliffe, the editor-in-chief of AJAXWorld Magazine, listed some of the important things
every AJAX developer should know (see http://web2.wsj2.com/seven_things_every_software_proj-
ect_needs_to_know_about_AJAX.htm ):
Hinchcliffe says, “The addition of RIA platforms such as Flex, OpenLaszlo, and WPF/E to a RIA
strategy is virtually required to properly exploit the range of capabilities you’ll want capable online
applications to have. This is particularly true around rich media support such as audio and video
– which AJAX is virtually incapable of – but even such mundane things as good printing support.
These are all things that the more sophisticated Flash-based RIA platforms really shine at and are
easier to program in to boot. AJAX will increasingly get a serious run for its money from these plat-
forms, particularly as they provide back-end server support for things like server-side push, formal
Web Services, enterprise environments, and more.”
Interestingly enough, the future of AJAX in the enterprise application space may not be as bleak as
it appears, and we’ll tell you why a little bit later in this chapter.
Finally, the browser’s golden days are almost over. All leading software vendors are looking beyond
the browser for the next Web application platform.
To summarize, if you’re developing a new enterprise RIA from scratch, AJAX may not be the way to
go. Choose a solid application development environment that offers a virtual machine at runtime
like Flex/Flash, Java, or WPF. Any of these environments is more productive than AJAX. If you al-
ready have AJAX applications, you can nicely integrate new Flex RIAs in existing AJAX applications
using tools like FABridge from Adobe for communicating between AJAX and Flex.
During AJAX’s first year of life, every article or book on the subject mentioned Google Maps and
Gmail, and various type-ahead samples: you enter the first zip code digit in a text field, and it sug-
gests your possible choices based on your input without a page refresh. Today, you can read about a
number of AJAX applications, including ones that work with photo images loaded from the popular
flickr.com Web site. If you run into one of these samples, compare it with the slideshow application
in Chapter 13. This is probably the easiest way to see the difference between the rich and just a little
richer Internet applications.
Last, we’d like to make it clear that popular comparisons of Flex versus AJAX are simply wrong,
since Flex is a framework and a complete development platform, while AJAX is a set of techniques.
To compare apples to apples, you should compare products like Flex against GWT (Google) and
the like.
OpenLaszlo
OpenLaszlo (http://www.openlaszlo.org ) from Laszlo Systems is an open source product that lets
you create applications that can be deployed as DHTML or Flash Player files (check out the project
called Legals at http://www.openlaszlo.org/legals). The ability to generate DHTML code made it a
good candidate for developing applications for mobile devices, and Sun Microsystems has recently
partnered with Laszlo Systems to bring this technology to the Java mobile space. This is direct com-
petition for Adobe Flash Lite.
Flash Player is becoming a de-facto standard in the delivery of multimedia applications, and Open-
Laszlo is already used by thousands of RIA developers. Like Flex and WPF, you define the GUI wid-
gets in a declarative XML-based language called LZX. The processing logic is coded in JavaScript.
One of OpenLaszlo’s selling points, besides being an open source solution, is that you can create
applications for versions of Flash Player as old as 6.0, which you can’t do with Flex 2. But the high
speed of penetration and adoption of the latest version of Flash Player diminishes the value of this
benefit.
GWT
GWT stands for Google Web Toolkit (http://code.google.com/webtoolkit/). It lets you write pro-
grams in Java, which are automatically converted to JavaScript so they can be delivered as AJAX
Web applications. This isn’t the first attempt to offer a tool that converts Java to JavaScript. Take the
open source project Java2Script (http://j2s.sourceforge.net/), an Eclipse plug-in that implements
an Eclipse SWT library in JavaScript. But GWT’s success is another illustration of how important it
is to have support from a commercial software vendor, such as Google, for any AJAX initiative. GWT
is not an open source product, but it is free.
An interesting GWT feature is that it compiles Java into various versions of JavaScript to accom-
modate the specific needs of different Web browsers. GWT comes with a library of extensible com-
ponents. When this chapter was written, the number of these components was limited, but that
will probably change soon, because it’s Google. Its UI components are Java classes (i.e., MenuBar,
HiperLink, Tree, and FileUpload), which can be combined into containers (i.e., HTMLTable, Sim-
plePanel, and ComplexPanel).
GWT’s hosted Web browser lets Java developers create and test their applications without convert-
ing them to JavaScript until the application is ready for real-world deployment. So, if a Java devel-
oper for whatever reason has to work on AJAX applications, he should definitely consider using the
GWT framework.
Nexaweb
Nexaweb (http://www.nexaweb.com ) offers a Java-based thin client that doesn’t require any ad-
ditional installation on the user’s desktop. The application’s state is controlled by a small Java ap-
plet running on the client. This applet communicates with the Nexaweb Java EE application as
needed. To avoid issues related to the version of the Java Runtime Environment installed with the
Web browser, Nexaweb uses JRE 1.1 for its applet. It’s supported by every major browser. This ap-
plet partially updates the Web page when the state of the application changes. The user interface is
defined using a declarative XML-based language, and the application logic is programmed in Java.
It comes with an Eclipse-based visual editor.
Canoo
Canoo (http://www.canoo.com/) offers a so-called UltraLightClient, which is a Java library of serv-
er-side proxy classes similar to the Swing API, providing, for example, ULCTable instead of JTable.
Basically each of these classes has two peers – one for the server and the other for the client’s JRE.
The library takes care of the split between client and server, including synchronization and com-
munication of these halves using a proprietary protocol. A small presentation engine runs on the
client, while the application runs on the server. The client’s presentation layer can be deployed as
a Java applet or application using Java Web Start technology. The server-side application can be
deployed as a Java servlet or a stateful session bean.
Backbase
Backbase (http://www.backbase.com ) includes a very light engine written entirely in JavaScript.
It loads seamlessly at the beginning of the client session and brings in the client-side presentation
framework, which includes tools to maintain state on the client, client/server synchronization, and
incremental data load. The presentation framework supports drag-and-drop, data binding, styling,
skinning, and multimedia. Backbase also steps away from typical page-based Web applications
and lets you create a so-called Single-Page Interface. It comes with a library of more than 50 off-
the-shelf GUI components written using DHTML, JavaScript, CSS, and XML.
Desktop 1.0 arrived more that 20 years ago as an intelligent and jazzy replacement for dumb main-
frame terminals. For the first few years, one of its main functions was terminal emulation. A few
killer apps (Lotus 1-2-3 and WordStar) changed the way people envisioned using computers. They
realized that they could have their own private data store saved on a home computer! After a while
a set of client/server technologies emerged. The main selling point of client/server was the ease in
getting server data to the end user in an online mode as opposed to the batch mode, which deliv-
ered the data requested the next day or later. Mainframe terminals with their green-on-black-text-
only user interface were sentenced to oblivion.
Visual Basic, Visual C++, and PowerBuilder were the tools of choice during the rapid growth of the
client/server system. As the world’s appetite for computer applications grew, deploying and ver-
sioning became more and more costly.
Then the Web with its Web 1.0 thin client started reminding us of the dumb terminal again, but this
time the background was white. A semi-intelligent Web browser provided online access to a pletho-
ra of J2EE, LAMP, or .NET servers located around the world. The applications were all one big shop-
ping card and users were reduced to the OK and Cancel buttons, but that was an affordable way for
everyone to sell their services on the Web. Later on, businesses began creating more sophisticated
Web applications and even converted the complete client/server system into DHTML/XmlHttpRe-
quest, albeit not labeled AJAX yet. (Seriously what took Jesse James Garrett so long?) And now we’re
approaching the “client/Web” revolution – this time making all the data in the world available and
personal at the same time with the eye-candy look-and-feel of rich Internet applications.
The world should now come up with new killer apps and revisit old ones but in a Web/Desktop 2.0
context. In the case of word processor or spreadsheet collaboration, privacy can be more impor-
tant than the ability to do a spell check.
Making application development simpler will get us halfway there. Small teams of developers will
be able to create Office-like components in Flex and Apollo. We see another trend here: putting the
end user in charge of the GUI experience. For example, many browser shortcomings were “fixed”
by adding toolbars and components. Creating a RIA platform and applications capable of cross-
integration is going to be vital.
Porting Google Maps into a desktop Apollo application was demo’d at the MAX 2006 conference.
Expect to see a number of “webified” desktop applications by mid-2007. The authors of this book
are working hard on Flex/Apollo applications and, hopefully, you’ll see the result at www.faratasys-
tems.com when Apollo is officially released.
The birth of Apollo has an interesting twist: both Flex and HTML/JavaScript applications can be
ported to Apollo, which means that AJAX applications will find their new home in Apollo too. Not
only they will be ported, they’ll be upgraded and turned into desktop systems. Basically, Apollo will
offer AJAX a lifeline.
Application Security
Another important consideration is the security of Flex/Java applications. Flex server-side security
management is quite extensive, and it lets you use either container offerings or custom security
providers via declarative XML binding. There are a couple of challenges since Flex supports mul-
tiple protocols, so Java EE security that relies only on HTTP sessions has to be extended, but it’s a
simple and well-documented process. On the client side, it builds on Flash Player security that’s
known for its lack of serious security flaws. You have a built-in security manager that has all the
standard protection for cross-domain and zone access. Corporations can further restrict the code
they get from third parties by wrapping the code loaders in additional security managers.
The real selling point becomes obvious on the second or third day of the proof-of-concept phase.
A decent Flex developer should be able to prototype (short of server processing) most of the UI for
a specific trading system by the end of the first week. If you’re lucky and system integration went
okay, you can add the collaboration features and multimedia – with the total client code base for
the whole project coming within 1,000-1,500 lines. This is definitely not possible with Swing. Of
course, some people will say modern Java IDEs generate lots of boilerplate code automatically, but
this is still the code that someone has to read, understand, and fix if need be.
Connection Management
Flex provides an extensive infrastructure for managing connections between the Web browser and
the server. It lets you specify all the protocol details for the Real Time Messaging Protocol (RTMP),
HTTP, HTTPS, as well as plain socket connections. You can then specify the order in which the pro-
tocols should be tried due to availability/firewall issues. Flex also automatically bundles multiple
requests going over the same transport, striving for maximum performance out-of-the-box. Since
any Web browser, by default, maintains only two connections with the server, Flex gives you much
better use of these two connections if you limit yourself to HTTP. You also get alternative real-time
push or pull connections on additional protocols, a direct socket API, and tons of low-level hooks
that let you build any protocol you want.
We worked on AJAX-like frameworks during 1999-2005 and can say that Flex is a lot more robust
in code and data delivery fields than any cross-browser AJAX solution known today. Robustness is
an even bigger showstopper for large AJAX applications than performance. Flex/Flash really gives
back the control over communications that is very important for enterprise applications.
Developers didn’t really know how the DataWindow worked, but they trusted this component.
PowerBuilder used an event-driven programming model, which was clean and simple. Object A
triggers event XYZ on object B, and this event can carry a payload – the data that object B needs to
operate. Using modern jargon it’s called Inversion of Control or Dependency Injection design pat-
tern. What’s important is that object B doesn’t know about object A. On the same note, if object B
needs to return the result of some internal function back, it would broadcast this result “to whom it
may concern” by triggering one of its own events (we’ll explain this in the section on custom events
in Chapter 4). This is loose coupling in action.
The mentality of many Java programmers was different. They’d assign lower priority to the user’s
windows and spend most of their time designing a multi-tier system that didn’t depend on any spe-
cific look-and-feel and could be universal. Meetings with Joe would be rare because they couldn’t
create a decent prototype fast. Fancy IDEs with GUI designers like Matisse weren’t in the picture
yet and, more importantly, Java programmers were thinking big: UML, design patterns, applica-
tion servers, and clustering. They enjoyed the programming process for itself. They didn’t like the
mindset of old-fashioned PowerBuilder or Visual Basic programmers who were thinking windows
and screens.
With Flex you started to care about the business users again. You can change the prototype twice a
day, and Joe can do the same with his business requirements. No pile of project documentation is
needed. The napkin is back and it works. Flex architects can give the server-side Java team the final
okay only after Joe is 100% happy.
Besides, with Flex we can have the best of both worlds: the source code of the Flex framework is
available, we can learn how it works inside, and override some functionality with what suits our
needs better.
Working with Flex promotes agile development, where the people we build the software for are
the driving force. Agile development methodology suggests minimizing each development cycle
to mitigate the risk of delivering something to the users that they don’t want. Agile development
encourages frequent face-to-face meetings with the end users as opposed to preparing and send-
ing documents back and forth.
The main page of the Manifesto for Agile Software Development (http://www.agilemanifesto.org/)
prioritizes:
In this book we tried to use agile development methodologies. When you follow the examples, do a
“reverse analysis” of the code you’ve written in the past to see if it could be done simpler using the
techniques we describe.
Summary
In this chapter we’ve presented you with a quick overview of major RIA-enabling technologies and
various approaches to making Web applications richer. It’s by no means a complete list: new com-
mercial and open source RIA frameworks and components arise every day. However, given the
overall business and technical value, there’s not a single RIA vendor that the authors of this book
would put anywhere near Adobe’s position with Flex. Adobe Flex 2 is an excellent tool for creating
commercial-strength rich Internet applications. It integrates with various back ends and elegantly
accommodates the complexities of an enterprise technology setup. If you’re thinking strategically,
if you’d like to keep your business competitive, you need to innovate.
Even though this book is not a Flex tutorial, we need to spend some time introducing this RIA
tool. While Flex comes with an Integrated Development Environment (IDE) called Flex Builder (see
Chapter 3), in this chapter we’ll gently introduce you to Flex programming by writing a couple of
simple Flex programs using only the tools and components that are available for free. We’ve also
included a brief comparison of the Java and ActionScript languages and some good-to-know top-
ics: frame rates, the application initialization process, and display lists.
Working with text editors and command-line compilers is not the most productive way of develop-
ing with Flex, but command-line compilers definitely have their use. In a typical real-world sce-
nario, developers working on a decent-size project would use both – Flex Builder IDE to create
and test their applications, and then build tools like Ant or Maven to invoke Flex command-line
compilers to create and deploy the application. This is especially important because Flex applica-
tions are often used in a mixed environment where an application build consists of multiple steps
of compiling and deploying modules written in more than one language, for example, Flex for the
GUI part and Java for the server-side components.
MXML: An XML-based markup language that lets you define GUI components using declarative
programming. You add tags to your program that represent visible and invisible Flex objects. For
example, the MXML tag <mx:Label text=”Enter password:” x=”20” y=”40” /> will display the text
“Enter password:” in 20 pixels to the right from the top left corner of the Flash Player’s window and
40 pixels down.
ActionScript 3.0: An object-oriented language with a syntax similar to Java’s. ActionScript classes
and MXML tags are interchangeable. Most ActionScript classes can be represented by MXML tags
and vice versa. Even if you create your application only in MXML, it’ll be converted to ActionScript
and then compiled into bytecode for execution in Flash Player.
Flex framework: A library of extensible components located in multiple packages. You can create
your own classes and new MXML tags as needed. Just write a piece of MXML code, save it in a file
called MyCode.mxml and you’ve got a new tag: <MyCode>. Or create the new class MyCode.as and
use it either with other ActionScript classes or as an MXML tag.
mxmlc: A program that launches MXML and the ActionScript compiler located in a Java archive
called mxmlc.jar. This command-line compiler generates Flex applications as .swf (pronounced
swif ) files.
compc1: A program that generates Flex component libraries as .swc (pronounced swick) files. An
swc file contains an swf, catalog.xml, and asset files if needed. We’ll discuss the use of component
libraries in Chapter 10.
fdb: A command-line Flex debugging utility that you can start from a command line. It requires the
debugger version of Flash Player that comes with the Flex framework.
asdoc: A documentation tool that runs through files containing Flex source code and creates on-
line documentation similar to the one that comes with the standard Flex API.
Flex Data Services 2 Express: Deployed as a standard Java EE application, it provides high-per-
formance connectivity with existing server-side data and business logic. Based on messaging ar-
chitecture, Flex Data Services integrates with existing common middleware and provides services
that automatically synchronize data between client and server, supports real-time data push and
publish/subscribe messaging, and facilitates the creation of collaborative applications.
Flash Player 9: A runtime environment for your Flex 2 applications (.swf and .swc files). A debug
version of Flash Player can output a trace message to a console or into a file.
Flex Builder IDE comes with command-line compilers and the Flex framework. But since this
chapter is about working with free Flex components, we’ll assume for a moment that you’re not
planning to use Flex Builder and will just get the Flex SDK from the section called the Free Flex 2
SDK and Language Pack.
After the download is complete, unzip the archive file into a separate directory. For example, in
Windows create a folder c:\FreeFlex and add c:\FreeFlex\bin to the system variable PATH on your
computer. Open the command window and type mxmlc –version. If you did everything right, your
screen may look like Figure 2.1:
Since the mxmlc compiler is written in Java, it uses the Java Runtime Environment (JRE) during
the compilation process. Flex Framework comes with its own JRE (when this was written version
1.4.2). You can also download a more current version of JRE at http://www.java.com/en/down-
load/manual.jsp. Having the latest JRE on your PC may increase the speed of the compilation
process.
After installing the Flex Framework, you’ll find the configuration file jvm.config and, if you have a
Windows machine, you can edit this file to use the latest JRE2. If you’re not using Windows, you can
modify the compiler’s shell script to point it to the right JRE.
If you don’t have Flash Player 9 installed, get it from the same Web page. The debug version of Flash
Player 9 is located under your Flex install in the directory Player.
We are now ready to write our first Flex program. Guess what its name will be.
After seeing these two magic words “Hello World” on the system console or a graphical window,
you’ll get this warm feeling of knowing that your software is installed and configured properly,
compilers work, the runtime environment operates, and you’re ready to learn the tool, which in
our case is Flex.
Type this code into your favorite plain text editor and save it in a separate directory. In a command
window, switch to this directory and compile this application by entering mxmlc HelloWorld.mxml.
It should create the new file HelloWorld.swf.
By default, .swf files are associated with Flash Player – just double-click on HelloWorld.swf in Win-
dows Explorer and it’ll run our HelloWorld program:
The MXML file has translated HelloWorld into ActionScript and compiled it into the .swf file. Dur-
ing the first pass, the name of your MXML file becomes the name of the main generated Action-
Script class, for example, with the virtual wave of a magic wand the MXML tag <mx:Application>
turns into the ActionScript code:
All other MXML tags will undergo a similar procedure. For example, the markup code
leads to the generation of an instance of the ActionScript class Label and calls its setter function to
assign the text “Hello World” to an attribute called text.
Typically, you deploy a swf file on your Web server as a part of an HTML page3. If you’re using a
command-line Flex compiler, you’ll have to create such an HTML file manually, as opposed to Flex
Builder, which automatically creates these wrappers for you. But even the process of manually
creating HTML wrappers is greatly simplified by using the so-called HTML templates that come
with Flex located in the folder resources. Currently, there are six HTML templates of various flavors
that can detect the client’s version of Flash Player, offer an express install of the player, and support
history management. The process of creating HTML wrappers is described in the product manual,
“Building and Deploying Flex 2 Applications.”
Now the Flex compiler will not only produce the .swf file, but will also create a subdirecory called
generated and you will be able to browse the source code of more than two-dozen ActionScript
HelloWorld-supporting files.
The speed of the command-line compilation may be improved if you use the option -
incremental=true (in Flex Builder this option is on by default).
You can read more about Flex compiler options in the section “Using the Flex Compilers” in the
product manual “Building and Deploying Flex 2 Applications.”
You can also specify compiler options in a special configuration file named flex-config.xml or in
a custom configuration file whose name should be specified in the load-config compiler’s option.
Just keep in mind that the compilation options from flex-config.xml file affects all your projects.
Another way of specifying some Flex compiler options from an ActionScript class, namely width,
height, frameRate, and backgroundColor, is through a special meta tag SWF that you put above the
class declaration line. For example:
[SWF(frameRate=”50”, backgroundColor=”#FFFFFF”)]
public class SomeApp {
}
If compilation fails, you’ll see a short error description, but if you’re still not sure what this er-
ror means, consult http://livedocs.adobe.com/labs/as3preview/langref/compilerErrors.html for
a more detailed description of the compilation errors. This Web page also has a link to a page de-
scribing runtime errors.
If you haven’t had a chance to use any of the build tools before, this section is for you. This is a mini-
primer on how to use Ant, the popular Java-based build tool from Apache.
Even deploying such a simple application as HelloWorld consists of several steps. For example:
Now imagine that your HelloWorld application is part of a larger application that includes Java
modules that also have to be compiled and deployed in some server location. The deployment
of even a small project usually involves at least a dozen dependent tasks that have to execute in a
particular order. Creating and maintaining a build script is well worth the effort.
<target name=”init”>
<delete dir=”${dest.dir}” />
<mkdir dir=”${dest.dir}” />
<attrib file=”${dest.dir}” readonly=”false”/>
</target>
</exec>
</target>
</project>
The init target consists of two tasks: delete and create the directory called bin.
Besides targets and tasks, our build.xml contains two property tags. One of them defines a property
called dest.dir that has a value bin that is the name of the output directory for our compiled Hel-
loWorld.swf:
This means that wherever Ant encounters dest.dir surrounded with ${ and }, it’ll substitute it with
the value of this property. In our case this is bin.
The project in Listing 2.2 also defines a property called flex.mxmlc that tells Ant where the mxmlc
compiler is located. The target compile uses Ant’s task exec, which will run the mxmlc compiler,
passing it the arguments specified in the <arg> tags.
Let’s download Ant4 from http://ant.apache.org/. Installation is simple: just unzip the archive and
add the path to its bin directory (i.e. C:\apache-ant-1.6.5\bin) to the environment variable path of
your operating system.
Now we can open a command window, get into the directory where HelloWorld.mxml and build.
xml are located, and enter the command ant that will start executing the default target of our proj-
ect, which is compile. But since compile target is marked as a dependent on init, Ant will execute
the init target first.
Figure 2.3 shows how the Windows XP command window may look after running this project:
Ant has an extensive set of predefined tasks like copy, zip, jar, War, FTP, Mail, Condition, and many
more described at http://ant.apache.org/manual/.
For example, to make our build file work in both Windows and Unix environments, we can specify
the location of the mxmlc compiler as follows:
You can pass values of the properties from the Ant command line using the –Dpropery=value op-
tion. For example, if we use the code snippet above, the property sdkdir can be passed from a com-
mand line:
ant –Dsdkdir=/opt/usr/freeflex
You can write more sophisticated Ant scripts. For example, you can automate the creation of an
HTML wrapper for swf files with a replace regex task applied to one of the HTML templates provid-
ed. You can write build scripts that will merge Flex-generated artifacts with Java Web applications.
Automating builds with Ant can get you pretty far.
There are lots of online articles and books on Ant, but don’t miss Ant in Anger by Steve Loughran
in which he discusses some Ant core practices, naming conventions, and team development pro-
cesses. (See http://ant.apache.org/ant_in_anger.html.)
Frame Rate
Flash Player renders its GUI objects (display list) at a specified frame rate. As opposed to Flash
movies that consist of multiple frames displayed over a timeline, Flex applications don’t have mul-
tiple frames, but the frame rate plays an important role in Flex programs. The display list (your GUI
components) is rendered at the specified frame rate and applications with higher frame rates can
have a better performing GUI, but it doesn’t come free.
The Flex compiler builds an swf file with a default frame rate of 24 frames a second, unless another
value is specified during compilation. For example:
This command will build an swf file with the frame rate of 50 frames a second. The display list
rendering and ActionScript execution take turns, hence the frame rate can affect your application
performance.
Setting the frame rate to 50 doesn’t mean that each frame will be displayed in exactly 20 millisec-
onds (1,000 divided by 50), since there is some OS/browser overhead. Besides, some browsers may
impose restrictions on plugins to lower CPU utilization on the user’s machine.
To see how the compile time setting of the default-frame-rate option affects program execution,
consider the following program that on each enterFrame event makes a simple calculation of the
actual frame rate.
We ran this program in the Internet Explorer and Firefox browsers on a Windows XP laptop with
a single 1.8GHz CPU. Tables 2.1 and 2.2 show the difference between requested and actual frame
rates and how hard the CPU works based on the frame rate settings.
Default-frame-rate 10 24 50 100
Actual frame rate 9-10 18-26 35-52 50-110
CPU utilization 15-17% 15-20% 18-20% 26-28%
Default-frame-rate 10 24 50 100
Actual frame rate 9-10 16-22 41-50 70-100
CPU utilization 16-20% 18-20% 22-25% 30-33%
While results vary slightly, they are self-explanatory – lower frame rates translate into lower CPU
utilization. You should experiment with frame rates in your application to find the right balance
between GUI performance and CPU use. Remember that your users may be running several pro-
grams at the same time, and you don’t want to bring their CPUs to their knees just because you’ve
enjoyed super-smooth graphics rendering. If you’re not creating a movie, keep the frame rate as
low as you can.
Namespaces in MXML
In XML, namespaces are used to avoid potential naming conflicts with other components with the
same names. So far we’ve only seen the xmlns property in our MXML sample programs:
The namespace mx:xmlns refers to the URI http://www.adobe.com/2006/mxml that lists valid
MXML tags. Open the file flex-config.xml and you’ll find an XML element there that links this URI
to the file mxml-manifest.mxl that lists all the MXML components. Here’s an extract from this man-
ifest file:
If you want to use one of the standard MXML components, specify the prefix mx for each of them.
For example, to use an MXML Label, you write the following:
Later in this book, we’ll show you how to create custom components and keep them in a separate
namespace to avoid naming conflicts. We’ll introduce another namespace with the URI com.the-
riabook.controls.*. For example, in Chapter 9 we’ll be developing a custom Tree component and
Listing 9.10 includes the following MXML code:
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:lib=”com.theriabook.controls.*” >
…
<lib:Tree id=”tree” width=”50%” height=”100%”…>
</lib:Tree>
</mx:Application>
This sample defines two namespaces: mx and lib. The <lib:Tree> notation means that we’re plan-
ning to use a Tree component from the namespace called lib. As you can guess, we’re going to pro-
gram this Tree component in the ActionScript’s package com.theriabook.controls and will have to
provide either the code of our Tree component or the SWC library that includes this Tree.
The namespace URI tells Flex where to look for the file implementing this component. You can
either create a com/theriabook/controls subdirectory in the application’s directory or – prefer-
ably – keep it in a separate location included in the classpath of your application (read about the
flex-config.xml file and the source-path tag in the Flex documentation). Since we’ve defined two
namespaces here, we can use components available in any of them.
You can also specify a so-called local namespace using notations like xmlns=”*” or xmlns:mylo-
cal=”*” that tells Flex to look for components that are located in the same directory as the MXML
file or, in case of Flex Data Services, in the /WEB-INF/flex/user-classes directory.
After saving the code above in the file Calculator1.mxml, we’ll compile it with mxmlc and run it in
Flash Player:
The calculator’s panels are ready and after adding a text tag to the top panel and several button tags
to the bottom one, the code will looks like this:
Compile and run this code and you’ll see the following screen:
It’s not the prettiest calculator you’ve ever seen, but it’s not bad for two minutes of coding. The
structure of the program in Listing 2.5 is simple, readable, and elegant.
The panels can include either standard Flex containers or custom components that you or other
developers created. Table 2.3 provides the widgets that come with the Flex 2 framework.
You can create custom components by combining these widgets. For example, you can create a
custom login component with two Label controls for ID and password, two TextInputs, two But-
tons, and a Link for the “Forgot Password?” function. Such custom components can be reused by
multiple applications. Starting in Chapter 6 we’ll show you how to create custom controls.
ActionScript was first introduced in August of 2000 as a programming language for Flash Player 5.
ActionScript 2 came into the picture in September of 2003 with Flash Player 7. ActionScript 3 (June
2006) is a full rewrite of this language that can be used for creating applications (even without using
MXML) for Flash Player 9. ActionScript 3 is based on the third edition of ECMAScript, which is an
international standardized programming language for scripting.
Flex Framework is written in ActionScript 3. Readers familiar with previous versions of this lan-
guage may want to check out “ActionScript 3: Learning Tips” at http://www.adobe.com/devnet/ac-
tionscript/articles/actionscript_tips.html.
We’ll be using ActionScript 3 in every chapter of this book, but for detailed coverage of this lan-
guage please consult the product manual “Programming ActionScript 3.0” available for down-
load at www.flex.org.
In Flex, you link MXML components with the ActionScript processing logic using one of the fol-
lowing methods:
<mx:Script source=”calculateTax.as”>
A typical Flex project consists of .mxml files with declared components since the files containing
ActionScript code, .swc files with compiled components, .css files with presentation style info, and
other assets like image files, if needed. All of these components can be compiled into one .swf file,
or a number of swc libraries, and run by Flash Player 9. Only one MXML file should have the <mx:
Application> tag; the rest of the MXML files usually start with other tags.
The displayDigit() is a function written in ActionScript that can contain some processing logic and
displays the digit. Chapter 4 will offer more details on using standard and custom events.
Event-driven programming is about identifying important events that may happen to your appli-
cation and writing event handlers to process these events. If a particular event never happened, the
code from the corresponding event handler (aka listener) isn’t called.
Not all events are triggered by the user’s actions. Some system events may be triggered by your ap-
plication code or other processes such as the arrival of the database query result set or the return of
the Web Services call. Your applications can define its own events and trigger them from MXML or
ActionScript code. Writing event listeners that contain code-handling events is automated in Flex,
but you have a means of writing such listeners on your ActionScript code.
Java compilers work faster because their job is a lot easier – a Java programmer creates all these
instances and listeners manually so the javac compiler spends most of its time merely translating
the Java source code into bytecode.
The third version of the calculator adds several samples of processing the button-click event. In
Listing 2.6 the b1 button uses inline ActionScript to concatenate digit 1 to the text field result:
click=”result.text+=’1’”
A click on button 2 calls an ActionScript displayDigit() function defined in the section <mx:Script>.
A click on button 3 concatenates the label of the button to the result field.
In the fourth button, we just fool around to illustrate using more than one ActionScript inline state-
ments – first replace the label of the button to 9 and then display it. Even though it’s not recom-
mended, you can use multi-line inline ActionScript code by surrounding it with curly braces.
A click on the fifth button shows how to display a message box, and Figure 2.6 depicts a snapshot
of Calculator 3’s program after pressing the first five buttons.
The simple answer is that an object-oriented language like ActionScript 3 combined with MXML
makes GUI programming easier. Java Enterprise Edition (Java EE) with its multi-threading fea-
tures, plus reliable and scalable application servers, is a great choice for server-side applications.
Java Swing, the library for GUI development is powerful but complicated. Dealing with event-dis-
patch thread and synchronization issues, lack of data binding, and the need to program multiple
event listeners manually makes programming in Java Swing a lot less productive.
ActionScript uses a single-threaded model (at least from the developer’s perspective) and avoids
many of the Java Swing issues by making all client/server communications asynchronous. A client
program sends a request to the server specifying the name of the callback handler, and the user can
immediately continue working with the screen, which never “freezes.” When the result comes back,
this handler will process it.
One of the ways to categorize programming languages is by how strict they are with variable types:
some languages use static and others dynamic data typing. In statically typed languages (Java, C++,
C#) you must declare a variable of a particular type, the compiler will ensure that your program
uses this variable properly, and you should not expect any data type-related surprises at runtime.
In dynamic languages (Perl, Python, ECMAScript, JavaScript) you don’t have to declare the vari-
ables upfront.
ActionScript offers you a balance between static and dynamic languages by allowing you to pro-
gram in both Java and JavaScript styles. But the freedom of not declaring variables comes with a
price tag: any runtime environment can more efficiently allocate required resources if the types of
program elements are known in advance. ActionScript 3 gives you the choice of writing highly ef-
ficient, statically typed code, highly dynamic and loosely typed code, or a combination of the two.
ActionScript 3 is a compiled object-oriented language and its performance has been substantially
improved compared to previous versions of the language. Its code is compiled into bytecode and
runs in the ActionScript Virtual Machine (AVM) in Flash Player 9. Strictly speaking, Flash Player
9 includes two AVMs: AVM1 executes the code written in the older version of the language, while
AVM2 runs the code produced by ActionScript 3. Having two VMs in Flash Player has increased the
size of Flash Player to about 1.2MB, but it ensures that existing applications won’t break and users
won’t need to keep the older version of Flash Player.
In AVM2, most of the code goes through a Just-in-Time compiler that converts the bytecode into
machine code and substantially improves performance.
Another notable feature of AS3 (and MXML) is their support of ECMAScript for XML (E4X), which
makes working with XML a breeze. You’ll see many examples of E4X usage in this book starting with
Chapter 4.
var orderId:String=”123”;
var orderIdN:Number=orderId as Number;
trace(orderIdN);//prints 123
Primitives byte, int, long, float, all primitives in ActionScript are objects.
double,short, boolean, char Boolean, int, uint, Number, String
or
abc::myCalc(){}
Private classes private class myClass{…} There are no private classes in AS3.
Private constructors Supported. Typical use: Not available. The implementation of private
singleton classes constructors is postponed since they aren’t part
of the ECMAScript standard yet.
To create a Singleton use the public static
method getInstance(). In the public constructor
check if the instance already exists, throw an
error.
Class and file names A file can have multiple A file can have multiple class declarations, but
class declarations, but only only one of them can be put inside the package
one of them can be public, declaration, and the file must have the same
and the file must have the name as this class.
same name as this class.
What can be put in a Classes and interfaces Classes, interfaces, variables, functions,
package namespaces, and executable statements
Dynamic classes (define n/a dynamic class Person {
an object that can be al- var name:String;
tered at runtime by adding }
or changing properties and //Dynamically add a variable // and a function
methods). Person p= new Person();
p.name=”Joe”;
p.age=25;
p.printMe = function () {
trace (p.name, p.age);
}
p.printMe(); // Joe 25
Function closures n/a. Closures support is a myButton.addEventListener(“click,” my-
proposed addition to Java 7 Method);
A closure is an object that represents a
snapshot of a function with its lexical context
(variable’s values, objects in the scope). A func-
tion closure can be passed as an argument and
executed without being a part of any object
Abstract classes Supported There is no mechanism to mark class methods
with the abstract keyword that would en-
force implementation of these methods in the
descendents
Function overriding Supported Supported. You must use the override qualifier
Method/constructor over- Supported Not supported. You can use a workaround with
loading …rest parameter:
To create similarly looking documentation for your own classes and components, get the ASDoc
tool at: http://labs.adobe.com/wiki/index.php/ASDoc:Using_ASDoc. For more advanced docu-
menting functionality, check the Flex2Doc utility at myflex.org.
In a perfect world, professional designers would create such prototypes using MXML; professional
software developers would just write programs in ActionScript. In reality though your MXML files
will have some amount of ActionScript. Try to keep it to a minimum but don’t kill yourself trying to
achieve the perfect separation of responsibilities.
Besides MXML, Web designers will find themselves at home with Cascading Style Sheets (CSS),
which in Flex play the same role and have the same syntax as CSS in HTML. Your firm-specific
fonts, coloring, and other styles should be done with CSS.
There is a slight difference in CSS use: in HTML pages, you can change the CSS file, press the Re-
fresh button in your browser, and the appearance of the Web page will change accordingly. In Flex,
if you assign CSS statically either by providing the name of a .css file or by using an <mx:Style>
object, they are embedded into SWF, so if you decide to change the look of your GUI components,
you have to modify the CSS file and recompile the application.
You can also create and assign styles to Flex components dynamically from within your Action-
Script code by creating an instance of the StyleSheet object, assigning values to its properties, and
then calling the setStyle method on the required UI component.
Flex Style Explorer is a handy tool that automates the process of writing CSS (see http://examples.
adobe.com/flex2/consulting/styleexplorer/Flex2StyleExplorer.html). Select the kind of compo-
nent or container that you want to make “stylish,” pick applicable parameters on the left, see how
it looks in the middle, and copy the CSS from the right into your <mx:style> tag:
Each Flex application has at least one default container that is represented by a class Application
that corresponds to the mxml tag <mx:Application>.
If you’re going to program in ActionScript, you should be aware of the fact that you can’t instantiate
DisplayObject, but you can create instances of its subclasses (Shape, SimpleButton, and others)
and add them to the display list. Flash Player renders changes to DisplayObject to the stage for each
video frame (also called keyframe).
You can add several display objects to a display list of one of the subclasses of DisplayObjectCon-
tainer. For example, the class Sprite is a direct descendant of DisplayObjectContainer, and flash.
display.MovieClip is a subclass of Sprite.
While MovieClip is a suitable class for Flash programs that display a sequence of frames over a
timeline, for business applications it’s the Sprite class, a lighter container that doesn’t include the
timeline support. In ActionScript, Sprite represents a display object in a display list node. As an
example, you can create an ActionScript class that extends Sprite, and add one or more display ob-
jects to your class with a series of the method called addChild(). Flash Player finds classes through
the root of the display list. Only after calling addChild() will a component be added to the display
list and the SystemManager assigned to it.
When Flash Player loads and starts your Flex application, the SystemManager controls the applica-
tion window; creates and parents the Application instance, pop-ups, and cursors; and manages the
classes in the ApplicationDomain. The SystemManager is the first class instantiated by Flash Player
for your application. It stores the size and position of the main application window and keeps track
of its children, such as floating pop-ups and modal windows. Using SystemManager you can access
embedded fonts, styles, and the document object.
SystemManager also controls application domains, which are used to partition classes by the se-
curity domains (see the description of the ApplicationDomain class in the Flex Language Refer-
ence).
If you’ll be developing custom visual components (descendents of the UIComponent class), keep in
mind that initially such components aren’t connected to any display list and SystemManager=null.
Only after the first call of the addChild() will a SystemManager be assigned. You shouldn’t access
SystemManager from the constructor of your component, because it can still be null at the mo-
ment.
In general, when the Application object is created, the following steps are being performed:
In most cases, you’ll be using the MXML tag <mx:Application> to create the application object, but
if you need to create it in ActionScript, don’t create components in its constructor – use createChil-
dren() for this (for performance reasons).
Flex SWF files have only two frames. The SystemManager, Preloader, DownloadProgressBar, and
a handful of other helper classes live in the first frame. The rest of the Flex Framework, your ap-
plication code, and embedded assets like fonts and images reside in the second frame. When Flash
Player initially starts downloading your SWF, as soon as enough bytes come for the first frame, it in-
stantiates a SystemManager that creates a Preloader, which in turn creates a DownloadProgressBar
and these two objects are watching the rest of the byte streaming-in process.
When all bytes for the first frame are in, SystemManager sends the enterFrame to the second frame
and then dispatches other events. Eventually, the application object dispatches the application-
Complete event.
You may by wondering why you need to know what’s happening before the application loads. This
knowledge may come in handy especially if your application is large and users experience unpleas-
ant delays during the initial load. You can use this time productively, for example, to let the user log
on to this application. This will also give the user a perception that your application loads faster.
Farata Systems has created an open source logon component that can be used in Preloader (see
http://flexblog.faratasystems.com/?p=88).
You can also create a splash screen that fades away with an image of your choice by substitut-
ing the standard Flex Preloader and the DownloadProgressBar objects with the custom ones. Ted
Patrick from Adobe has provided sample applications that display a splash screen using an image
from PNG, SWF, or GIF files (see http://www.onflex.org/ted/2006/07/flex-2-preloaders-swf-png-
gif-examples.php ). While your splash screen is displayed, you can download some other system
resources and/or libraries and then the splash screen fades away.
Here’s another idea. During the loading process, your ActionScript code may interact with the “outside
world” aka Web browser. The class ExternalInterface has a method addCallback() that lets you register
an ActionScript method as callable from the container. After a successful invocation of addCallBack(),
the registered function in Flash Player can be called by the JavaScript or ActiveX code in the container.
You’ll find more on the ExternalInterface in Chapter 15.
One more suggestion: your application may need to load another application(s) from an SWF. If
you have to do it in ActionScript, you can use the SWFLoader class from the applicationComplete
event (see more on SWFLoader in Chapter 10).
Summary
In this chapter, we first created simple applications and peeked under Flex’s hood. The most im-
portant feature of Flex 2 is that it’s an open and extendable framework. If you are accustomed to
being in complete control with Java, Flex doesn’t tie your hands either. In the next chapter we’ll get
familiar with the Eclipse-based IDE called Flex Builder.
Endnotes
1. Besides mxmlc and compc Flex has one more compiler called the Web tier compiler. This compiler comes
with Flex Data Services and lets you create swf files during the runtime on the server side. This compiler
runs in a Java EE servlet container.
2 . Flex compiler itself is just a wrapper that internally calls the Java archive called mxmlc.jar (or compc.
jar). This compilation process can be initiated from a Java program if needed. See http://livedocs.
macromedia.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_
Parts&file=00001489.html.
3. If you’re using a Web-tier compiler, your user can specify a URL of the remote MXML file, which will be
compiled into the swf file and delivered without an HTML wrapper.
4 . You can skip this step if you have Eclipse installed – Ant is located in its plug-ins directory.
After Flex Builder is installed, start Eclipse, select the menus Window | Open Perspective | Other,
and open the Flex Development perspective. The Flex Debugging perspective will be automatically
added to the Eclipse IDE. The Flex Builder comes with great help content, which in the plug-in ver-
sion is located under the menu Help | Help Contents | Adobe Flex 2 Help or Help>Flex Start Page.
Always start by creating a new project. Select the File>Flex Project menu item to open the New
Project wizard. The first decision you’ll have to make is to choose the way your application (in fact,
all the applications in this project) is going to access remote data:
We’ll discuss Flex Builder’s project types later in this chapter in the section “Project Types and Data
Access.” Since we’re not going to use any server-side technology in this chapter, the Basic type
is our choice so just press the Next button. Now you’ll have to pick the name and location of the
project:
Once you’re done, click Next and, in the following screen, specify the name of the main application
file and output folder:
Enter HelloWorld.mxml as the name of the main application file. The compiled application will be
saved in the bin directory unless you specify another output folder. Click Finish to complete the
project creation.
After the project is created, you’ll see a screen similar to Figure 3.4 with the pre-generated file Hel-
loWorld.mxml.
The application may also include other MXML and ActionScript files with application logic as well
as images and other resources commonly referred to as “assets.”
Have you noticed the two tabs above the code editor? By default, FlexBuilder displays the source
code view, but since we have to design our HelloWorld screen, we’ll start working in the design
mode (as you become more experienced, you’ll be using the design mode mostly for quickly proto-
typing your screen), so click on the Design tab and let the fun begin.
In the middle of the screen in Figure 3.5 you’ll see how your future window will look. All folders
with predefined Flex components are located on the left: layouts, navigators, standard and custom
controls. Select the Label control, then drag-and-drop it onto the screen.
In the middle of the screen you can see canvas of the Application container. Available Flex frame-
work components (as well as custom ones that you develop for your project) are presented in the
tree view in the Components panel in the lower left. Select the Label control parented by Controls,
then drag-and-drop it onto the screen. Change the label’s text to “Hello, World!” Now, switch to the
Category View in the Flex Properties panel, located in the lower right corner of the screen. In the
Styles category set the fontSize to 22 and fontWeight to bold.
If you didn’t select a specific control prior to changing the font attributes, it would affect all the
controls of this window.
Now take a peek at the source tab. Flex Builder has generated a line similar to this one:
</mx:Application>
In fact, you could have just typed the letter “f” and the list of attributes would be conveniently lim-
ited to the ones starting with “f.”
Similarly, were you to type “<mx:Bu”, you’d be prompted with all the MXML components that start
with “Bu”:
As you can see, the Source Panel is as effective in creating and modifying MXML elements as the
Design Panel.
Running HelloWorld
Press the right mouse on the HelloWorld.mxml in the Navigator Panel on the upper left portion of
the screen. Select RunAs…>Flex Application and you should see a screen like this:
Right-click inside this window. You’ll see the pop-up menu without the View Page Source option.
No wonder, your application has been compiled and launched inside the virtual machine called
Flash Player, that’s why you can’t see its source code. Actually, at the end of this chapter we’ll show
you how you can enable this View Source option and make your project’s source code available to
the general public.
But you can also open the bin directory, double-click on the Flash movie SWF file, and your Flash
player will run your program without the browser. Now the Flash Player will run your application
independently of the Web browser:
Your project can be built either automatically (every time you save code changes) or manually
based on the Build Automatically setting in the menu Project. Typically, builds are done incremen-
tally based on the data you’ve modified since the last build. But if you’d like to rebuild the entire
project from scratch, just use the menu item Project | Clean.
If you specified that your project depends on other ones (see the Project References screen in the
Properties menu), Flex Builder will figure out the order of the project builds, or you can specify the
order using the menus Windows | Preferences | General | Workspace | Build Order.
For more sophisticated projects, builds may consist of multiple steps including invocating addi-
tional programs, copying files, etc. Flex Builder supports using the Apache Ant tool, and we’ll use
Ant in Chapter 10.
HelloWorld.swf : The byte code (113Kb) ready to run in the Flash Player
HelloWorld.html: An HTML wrapper (5Kb) to run in the Web browser
HelloWorld-debug.swf: The byte code with debug information (180Kb) to run in the debug ver-
sion of Flash Player (this version of the player is installed automatically with Flex Builder).
HelloWorld-debug.html: An HTML wrapper (5Kb) to run the debug version of HelloWorld.swf in
your Web browser
In the output directory you’ll also find some files that are shared by all the applications from your
project:
AC_OETags.js: A bunch of JavaScript functions used by the HTML wrapper, i.e., the user’s Flash
Player’s version detection
playerProductInstall.swf: A small (1Kb) used by the HTML wrapper to upgrade the user’s Flash
Player plugin to version 9, if needed
history.* : The Flex’s implementation of the history functionality (7Kb total), similar to the history
in Web browsers
To deploy your application under a Web server, you’ll need to copy there all of the above files except
the debug ones and provide your user with the URL of the file HelloWorld.html.
While building a wrapper is an automated process, chances are you’ll have to tweak it to set certain
options in the browser/application integration like history management or setting the DHTML
objects for Flex/JavaScript interaction. You will need to review the files in the html-template used
to generate the HTML wrapper and customize them to fit your needs.
Your resulting SWF file may use some of the external resources, for example, image files, which may
either be embedded in your SWF files with an [EMBED] tag, or remain external. In the latter case
you can replace the image files without needing to recompile your SWF. Just make sure that the op-
tion Copy non-embedded files to output directory is selected in the project properties screen below.
You can also turn off the generation of the HTML wrapper.
You can also run non-default MXML files from your project as long as they have the Application
tag. Just right-click on the file and select the menu option Run as a Flex Application. You can always
check which MXML files can run by selecting the Project Properties menu and the option Flex
Applications. You’ll see a pop-up screen that will list all current runnable files and will let you add
(remove) more MXML files to this list.
We’re going to create a new application called HelloBasil that will contain three components: a text
field, a button, and a label. The user will enter a name in the text field (i.e., Basil), press the button,
and the label component will display today’s date and a greeting (i.e., “May 1, 2006: Hello, Basil”).
This application will have to process the button-click events with the help of ActionScript.
Drag and now drop the TextInput component from the Components view on the left onto the de-
sign area. Enter input_1 as the ID of this component.
Next, add a Button component and set its ID to btn_1 and its label to “Greet Me”, then put the Text
component under the button. Remove the default text and set its ID to output_1.
Run the program. If you press the “Greet me” button, it won’t do much since there’s no code yet for
processing the button click event:
Select the click attribute and press Enter. Alternatively, you could have just typed click=””. We’re
going to fill in the blank value of the click attribute with the script, corresponding to the action
this button will perform: we want to set the text property of output_1_ to the concatenated “Hello”
and the text of input_1. Flex Builder will keep helping you by suggesting available properties of the
screen components as you type. The new version of our button’s code will look like this:
Run the program, type in the name, click the button, and if your name is Basil, your screen will look
like this:
As alternative to coding the script directly inside the click attribute, we could have moved this
script to an application-level function and called it:
</mx:Application>
Flex MXML supports embedding ActionScript as the literal value of the <mx:Script> tag. Generally
speaking, it’s safer to safeguard your code in the CDATA section since it may contain symbols such
as “<”, which will break the well-formness of MXML.
Layouts
Flex GUI components live in so-called containers that let you arrange these components, provide a
consistent view of your application regardless of the current size of the window, and navigate from
one view to another.
Let’s look at the layouts using our sample HelloBasil.mxml. Switch to the Design View in Flex Build-
er and change the layout from vertical to horizontal in the Flex Properties view. Your components
will be immediately rearranged horizontally and, if you run the application, it’ll look as follows
(compare with Figure 3.14):
Even if you start resizing the browser’s window, the relative positioning of the components in the
container will remain the same. In Java Swing, a BoxLayout class provides a similar functionality.
Change the layout to absolute, rerun the application, and resize the browser’s window. You’ll see
that HelloBasil has lost its flexibility: now all the container’s components are glued to their posi-
tions regardless of the size of the visible portion of the browser. You should use the absolute layout
only if you’re sure that your GUI application doesn’t have to be resizable. The Flash Player renders
the components for the containers with absolute layouts slightly faster than with horizontal or
vertical layouts.
To relieve a bit the stiffness of the absolute layout, Flex lets you specify so-called constraints. In a con-
tainer with an absolute layout, you can specify top, bottom, and center anchors (the distances from
the components to the edges or the center). Instead of using x and y coordinates, you can use the right,
left, top, and bottom attributes. This so-called constraint-based layout will resize the screen compo-
nents if the user starts resizing the window. In Flex Builder’s design mode, select one or more of the
components and you’ll be able to specify the anchors. For example, the setting shown in Figure 3.16
forces selected component(s) to be “pinned” at a distance of 150 pixels from the right edge of the con-
tainer and 60 pixels from the bottom even if the browser’s window is being resized.
Basically we can say that Flex’s constraint-based layout is a simplified version of Java SpringLay-
out.
In the real world the GUI is more complex than in HelloBasil and you’ll have to combine contain-
ers with different layouts in the same application. For example, you can put horizontal (HBox) and
vertical (VBox) containers in your application. Containers can be nested and arranged in other
containers called Panels that also support layouts. Besides these flexible containers you can add
another one called Canvas, which keeps its components in absolute positions relative to the top
left corner of the Canvas.
In addition to the layout containers, Flex supports navigation containers (i.e., ViewStack, Button-
Bar, and others) that let you switch from one container to another. This topic is out of the scope of
this chapter, but we’ll use all of these containers in Chapter 5 in a more realistic application.
To achieve this, we could have written the checkbox’s click script to manipulate the visibility of the
panel. Alternatively, we can define a view state, named advanced, and prescribe that in this state the
width and height of the panel will be 50% and 75%, while in the default state they will be set to 0.
Flex Builder allows visually creating multiple states and maintaining state properties via the States
View, usually displayed at the top right corner of the Flex Builder workbench. If you don’t see this
view, bring it up by using the menus Windows | Show View | States. Figure 3.18 is an illustration of
a modified Hello Basil with the “advanced” state. Please note that using the States View you can
navigate from state-to-state and instantly see the changes to the application.
<mx:transitions>
<mx:Transition fromState=”*” toState=”advanced”>
<mx:Resize target=”{advanced_panel}” duration=”400”/>
</mx:Transition>
</mx:transitions>
<mx:states>
<mx:State name=”advanced”>
<mx:SetProperty target=”{advanced_panel}” name=”width” value=”50%”/>
</mx:State>
</mx:states>
<mx:Panel id=”advanced_panel” title=”Advanced Info” width=”0” height=”0”/>
</mx:Application>
To make the switch between two states smoother, we’ve used a special Flex element called Transi-
tion. In this particular example we’ve used a transition with a special effect, Resize, requesting Flex
to make a transition from the base to the advanced state gradually during a time interval of 400
milliseconds.
• vmargs
• Xms 128M
• Xmx512M
In the sample above, Xms requests a minimum of 128MB of heap memory that can grow to 512MB
(Xmx).
If you start Eclipse in Flex Builder from a command line, you can achieve the same effect by enter-
ing these parameters manually in a command line, which in the Windows OS may look like:
These parameters may improve the responsiveness of Flex Builder and the build time of your proj-
ects if you’re using the same VM for builds. The larger minimum heap delays the moment when the
Java garbage collector kicks in for the first time. Other parameters to fine tune the garbage collec-
tion of Flex Builder are –XX:MinHeapFreeRatio and –XX:MaxHeapFreeRatio, which will control the
minimum and maximum amount of heap space after garbage collection.
Please note that these parameters only affect the performance of the Flex Builder ID; your com-
piled programs will run at the same speed as before. When this chapter was written, Flex 2 did not
provide tools for fine tuning garbage collection, which is done internally by the Flash Player.
Remember that by reserving too much memory for Flex Builder, you’re decreasing the amount of
memory left in your system for other applications.
To monitor your Eclipse memory consumption, download the plugin from KyrSoft (http://www.
kyrsoft.com/opentools/memmon.html) and unzip it in your Eclipse installation directory. The ex-
cellent plugin not only allows you to monitor memory, but also request garbage collection when
memory reaches specified thresholds (see Eclipse menu Window | Preferences | Java | Memory
Monitor).
Some people recommend closing an unused project; some suggest replacing the JRE that comes
with Flex Builder (see the JRE folder under your Flex Builder installation directory) to a newer one.
While Flex Builder is a huge leap forward compared to an older Flex development environment, at
the time of this writing Flex Builder is slower than Java Eclipse IDE, which will hopefully change in
future releases of Flex.
Let’s illustrate how to use the Flex Builder debugger with our HelloBasil application. Let’s modify
the greetMe() function to display today’s date. We’ll declare and initialize the ActionScript variable
of type Date and concatenate the current date to the greeting.
To toggle a breakpoint just double-click on the gray area to the left of the line where you want a
program to stop, and Flex Builder will mark this line with a blue bullet. We’ll put a breakpoint at the
last line of the greetMe() method. To run the program in the debug mode, select the application in
the Navigator view and select “Debug As…” in the context menu.
As soon as you press the “Greet me” button, your program will reach the breakpoint and Flex Build-
er will pause to give you a chance to analyze the values in the variables you’re interested in. To step
through the execution of your program, you can use the little yellow arrows at the top of the debug
view.
The Variables view lets you check and change the values of your program variables. If a variable
represents a composite object, you can easily see its content by pressing the little plus sign on
the right. For example, the variable this represents the object you’re in – your main application
instance. In the Console window we can see the results of our trace statements. Please note the
assert() method – this technique is often used to reduce the amount of trace output if the entries
comply with the listed assertions.
Flex Builder allows you to perform conditional debugging instead of setting up the breakpoints.
Just call the method enterDebugger():
You still need to run your application in the debug mode, but if myVar is not greater than 25, Flex
Builder will execute your program without stopping in the debugger.
code on a standalone client machine without using any servers. All the samples in this chapter
where compiled locally on the client machine and they didn’t rely on any data located on external
servers, so our project is basic. However, your application can directly talk to a remote Web Service
despite the fact that your project is basic.
On the other hand, in Chapters 5 and 6 we’ll be using Flex remote objects and data services, and
we’ll select an optional Flex Data Services that assumes you already have it installed and deployed
under the Java EE servlet container of your choice. For these types of projects, you’ll be asked to
specify the URL of your Flex Data Services install (we’ll do this in Chapter 5), and after compiling,
your project will be embedded into your SWF file.
If you select Flex Data Services as your project type, you’ll have to specify if you’re planning to com-
pile your project locally using Flex Builder or on the server when the page is viewed.
Generated ActionScript
As we’ve mentioned before, the Flex compiler converts MXML into ActionScript source code and
then compiles it into an swf or swc file. If you’d like to see this ActionScript code, add an additional
compiler argument – keep-generated-actionscript in the screen shown below and recompile your
project. Flex Builder will create a sub-directory called generated, where you can find the source
code of all the generated ActionScript files.
After closing the dialog, you’ll also see the new “generated” folder in Flex Builder’s project tree
containing about 50 ActionScript files. Those files are used to initialize a framework, provide CSS
support, and divide our application into resources, classes that have to be initialized on the appli-
cations load, etc. We highly recommend that you spend some time reviewing the generated code
after learning a new feature/control to get familiar with the dependencies and intercommunica-
tions with the Flex framework.
• If you see a little asterisk in the tab with the file name, this means that this file has some un-
saved code changes.
• Highlight the name of the class or a function and press the button F3 on your keyboard. This
will take you to the source code of this class.
• If some of the lines are marked with red error circles, move the mouse over the circle and Flex
Builder will display the text describing this error.
• Alt + / will complete the name of the variable or a class after you typed in a couple of its first
letters.
• Press Ctrl-F11 to run the last launched program again. Hit the F11 key alone to run the pro-
gram in debug mode.
• Place the cursor after a curly brace and Eclipse will mark the matching brace.
• Highlight a line or a block of code and press Alt-ArrowUp or Alt-ArrowDown. The selected
code will move up or down.
• Ctrl-H will open a popup to search on multiple files, and Ctrl-F will let you find text in the
open file.
• Highlight the MXML tag or ActionScript class and press Shift-F2. This will open the screen
with the language reference help on the selected element.
• Highlight a block of code and press Ctrl-Shift-C to comment out the selected block of code.
• Keep the Control key down while moving the mouse over MXML tags. Flex Builder will show a
tool tip with the name of the corresponding ActionScript class. If the tag turns into a hyperlink
and the source code is available, click on the link to open the source code of the class.
• As you change your code in the editor, Flex Builder puts a vertical purple bar on the left of
each modified line. This is quite handy if you’d like to have a quick look at the new code before
pressing the button Save.
• If you want to test your application in different browsers installed on your computer, select
the menu Windows | Preferences | General | Web Browser and select the browser to be used by
Flex Builder for launching your application.
• If you see an error message that reads “…Check the Error Log file”, this log file is located in
your workspace, in directory called .metadata.
This menu item will quickly build a set of files in the sub-folder srcview in the output folder with
the source code of your project ready to be published on the Web as in Figure 3.23.
Besides preparing the source files for publication, Flex Builder will also add to the Application the
attribute viewSourceURL pointing at the location of the source code:
Next time you run this application, right-clicking the mouse will open up a menu with one extra
item: View Source. Something you got accustomed to in the HTML/JSP-based application, but a lot
better organized.
But CVS isn’t your only choice. Subversion is another popular open source version control system
that’s easier to administer, allows versioning support for directories, and has some other advan-
tages. Subversion is available for free at http://subversion.tigris.org/. You can also download and
install one of the plug-ins for Eclipse (i.e., Subversive or Subclipse), which puts your repository
just one click away from your Flex Builder projects. A free online version of the Subversion book is
available at http://svnbook.red-bean.com/ and here we’ll just provide the information relevant for
configuring the Flex Builder client to be used with Subversion repositories.
We assume that you already have the Subversion server installed, the source code repository for
your project configured, and the proper permissions to access this repository.
Start by downloading and installing the Subversion client, which will let you to do all the version
control operations from the command line. While most of the time you may be using some Subver-
sion plug-in from Flex Builder, this client software will become handy if you decide to automate
your application’s build process. For example, you may write an Ant build script that will start by
running Subversion commands cleanly, checking out all the files from the repository.
After installing your client make sure that the system variable APR_ICONV_PATH is defined and
points at the iconv directory in your Subversion client directory. If your Subversion server is located
on the Unix box accessed using ssh, also define a variable SVN_SSH that points to the location of
your ssh client. For example:
SVN_SSH=C:\\my_ssh_client\\ssh2.exe
The next step is to install the Subversion plug-in (we use Subclipse here) so you can use the Sub-
version repository right from your Flex Builder projects. Select the menu Help | Software Updates
| Find and Install, and in the pop-up screen pick the option Search for new features to install. In
the next screen enter Subclipse in the name field and the following URL in http://subclipse.tigris.
org/update_1.0.x.
Check the Subclipse box in the next screen and finish the install.
After a successful install, you’ll find a new perspective called SVN Repository Exploring as in Figure
3.25. Now the Eclipse Help menu will have a new section on using Subclipse.
Finally, you need to specify the location of the Subversion repository of your project: the system
administrator who installed and configured the repository will give you the parameters of the Sub-
version server. After getting this information, right-click in the Navigator view, select New | SVN
Repository, and enter its URL. The Eclipse help menu has a section on it.
If you’re connected to your repository, right-click on your project and select the Team item from
the menu. It should open a pop-up window with the typical version control options: Checkout,
Update, Commit, Diff, etc.
If you‘d like to add an existing project to the repository, use the menu Team | Share Project. To get
the project from repository into Flex Builder, open your SVN Repository Exploring perspective,
right-click on a project, and select the option Check Out as Project. The rest of the commands are
pretty intuitive (don’t forget about committing your changes) and are well described in the Subver-
sion documentation.
If for any reason you’re not happy with the Subclipse plug-in, try the Subversive client, which is
available at http://www.polarion.org/.
Summary
In this chapter we’ve introduced you to a developer-friendly Flex Builder tool. Even though our
sample applications were very basic, you’ve had a chance to see and enjoy the ease of developing in
Flex Builder. You can find a detailed description of all Flex Builder features in the manual using Flex
Builder 2, which is available for download at www.flex.org. In the following chapters we’ll gradually
increase the complexity of the examples, so fasten your seat belts, please.
In this chapter we’ll roll up our sleeves and build several mini-applications to illustrate the use of
various elements and techniques of both ActionScript 3.0 (AS3) and MXML that you’ll be using in
real-world projects. But this is not a tutorial and we’ll be introducing these elements on an as-need-
ed basis. Our goal is to give you the big picture, but you should study the product documentation
for detailed coverage of each of these elements.
• A description of some of the AS3 features that may seem unusual to Java programmers
• A review of object-oriented programming techniques in AS3
• A short description of ECMAScript for XML, which offers simplified processing of the XML
sources
• An overview of the Flex event model
• An application that uses namespaces in AS3
• A program that uses Flex data binding and regular expressions
• An application illustrating the communication between Flex and JavaServer Pages
• A sample application showing different ways of achieving the same results by people with dif-
ferent programming backgrounds
• An application illustrating the use of collections, filters, and timers
We can create an instance of Person, add the property age, and override the default method to-
String():
trace(p); // Doe,Joe-25
Note that dynamically added or redefined functions can’t access private members of the dynamic
class: had we declared Person’s lastName as private, trace(p) would result in “undefined,Joe-25.”
Adding or redefining a method isn’t any different from that of any different property type. After all,
a function is just a property with a type Function.
The attached function retains the scope of the original instance of JavaProgrammer: it prints “Mr.
Interface is ready for RIA work!” –not “Doe is ready for RIA work.”
Most importantly, however, is that the definition of Person starts with the keyword dynamic. What
makes AS3, as a scripting language, stand out from its peers is the optional strong typing and, first
of all, the just-in-time (JIT) compilation of strongly typed code blocks into native machine code.
Having bet on performance, AS3 changed the rules of engagement: now instead of assuming that
the class allows dynamic properties or methods, it defaults to the opposite. Regular classes, as they
are known in Java, are called sealed in AS3. To take advantage of dynamic properties and methods
you have to prefix the class definition with the magic word dynamic.
What happens if you don’t? For starters, the default mode of the Flex Builder compiler is strict and
unless you turn it into a so-called standard (strict=”false”), you won’t be able to compile the above
snippet. Then, having turned off the compile-time type checking of AS3, you’d get hit by runtime
type checking.
In full compliance with AS2 and JavaScript, it’s also possible to add/modify the property or method
on the entire dynamic class via its prototype object:
Person.prototype.age = 46;
Person.prototype.fullName = function():String {
return this.lastName + “,” + this.firstName ;
}
trace(p.fullName()); // Doe,Joe46
Notice how the value of age has been effectively modified on the instance p that’s already been
created.
The delete operator destroys the property of the dynamic object and makes it eligible for garbage
collection:
delete p.age;
trace(p); // Doe,Joe-undefined
Some of the Flex classes are intentionally defined as dynamic, those being Object, Array, MovieClip,
NetConnection, and AsyncToken. When this chapter was written, the subclasses of the dynamic
classes were not dynamic by default. Because of this, you may run into a runtime error: imagine a
sealed class S that extends a dynamic class D. If you create an object as
an attempt to add a property to dynObj will produce a runtime error because the variable dynObj
points to a sealed object. So,
dynObj.favoriteBand=”Beatles”;
would cause
You should be aware of the tradeoff: natively compiled code performs faster in the order of magnitude;
it’s also significantly more efficient in terms of memory consumption. On the other hand, dynamic
classes bring lots of flexibility to programming. For instance, they help you get away from marshaling
incompatibilities during remote calls. Compare this with Java RMI. For the successful serialization of
a class between two JVMs, the definition of the class has to be present on each end1. Importantly it
has to be exactly the same definition. But with dynamic classes it’s not a must. And, as far as object-
oriented terms go, you could say that dynamic classes offer “O-O on steroids” (use at your own risk).
You can define a function using either function statements or function expressions. A function
statement declaration of the function calcTax() that returns a number may look like:
Alternatively you may use a function expression. One typical use case for a function expression,
aka an anonymous function, is assigning it to some property of an object. That’s exactly what we’ve
done in the prior section when we defined the fullName method:
Person.prototype.fullName = function():String {
return this.lastName + “,” + this.firstName ;
}
var myTax:Number=calcFunc(88000);
There’s no fundamental difference between the latter use cases and a regular function statement,
because a function declaration is equivalent to defining a variable of the type Function and assign-
ing it a function expression. There’s a nuisance, however, when an anonymous function is attached
to a property of an dynamic object: when the property gets deleted (fullName), the lifespan of the
function is over2.
Another popular use case for anonymous functions is the event handler function:
remoteObject.addEventListener(
“fault”,
function(event:FaultEvent):void {
// .. .. ..
}
)
Note that the syntax above can cause memory leaks since it requires the VM to make a reference to
this object and place it inside a global anonymous function that makes garbage collection unavail-
able on “this.” Proper application techniques say to use a bound method and a weak reference/re-
moveEventListener method to simplify memory de-allocation.
Function Parameters
In AS3, primitive parameters are passed by values, and non-primitives are passed by reference. You
can include default values for the function parameters. For example:
Within the function body AS3 supports special objects called arguments. These are arrays that in-
clude actual arguments passed to the function. The length of these arrays may be different from
the number arguments the function declares. The additional property arguments.callee contains a
reference to the function itself.
Also, the AS3-specific way of supporting a variable number of function arguments is the so-called
… (rest) parameter. Ellipses followed by the name represent an array that accommodates any num-
ber of arguments that you pass in excess of the declared parameters, which always precede the rest
parameter:
Java programmers may find the … (rest) similar to a varargs notation. You can mix the … (rest) with
other function parameters so long as it’s the last parameter of the function.
Here’s an idea for using the … (rest) parameter to overcome the absence of overloaded functions
and constructors in AS3: use a switch case operator to branch on the number of actual arguments:
Class MyClass {
public function MyCLass(...args) {
switch (args.length) {
case 0: constructor1(); return;
case 1: constructor2(args[0]); return;
case 2: constructor3(args[0], args[1]); return;
...
}}
To ensure proper processing in cases where the number of arguments is the same but the types are
different, you’d have to complement this with type checks:
if(args[0] is String) {
// process as String
} else if (args[0] is Number){
// process as Number
}
The code snippet below instantiates the class Tax and assigns and prints the income using the get-
ter and setter of the class Tax:
Functions as Objects
Java programmers may find this concept a bit unusual, but AS3 functions are objects of the type
Function, and they can have their own properties and internal methods and can be passed to other
functions as arguments. A Function type can’t be extended since it’s defined as “final” so you can’t
manipulate it in an OO way. Functions are used in either a bound or closure mode. Bound functions
are identical to Java ones in that they are defined within the class and their lexical environment is
the instance of the enclosing class.
To use the addNumber method you have to provide a reference to an instance of the MyClass ob-
ject. It’s a direct call to the instance and the context of the instance is available to the function.
You can find other examples of using a function object in some of the ActionScript methods. For
example, when you add a listener to process an event, you register in ObjectProxy.addEventLis-
tener (“myEvent,” myEventHandler) and call a name of the event to process and a function that will
handle this event. Note that the name of the myEventHandler function is not followed by parenthe-
ses here because we’re not calling the function myEventHandler, but are passing a reference to its
code, which will be called if and only if the myEvent event in the ObjectProxy object occurs.
The fact that you can pass just the name of the function as a parameter makes it impossible for the
compiler to check that this passed function is called with proper parameters, which may poten-
tially lead to runtime errors. Thorough testing of Flex applications is even more important than in
Java.
Closures
Closures play a cornerstone role in dynamic languages. They’re essential for implementing fea-
tures like OO or building frameworks. At the same time, the formal definition of closures doesn’t
really help in understanding them. Let’s go through a few examples. First, we’ll show what closures
look like and then we’ll give you their use patterns.
It all starts with the use of an anonymous function that has access to variables in the outer lexical
scope:
<?xml version=”1.0”?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
layout=”vertical” creationComplete=”doInit(event)”>
<mx:Script>
import mx.controls.Alert;
private var greeting:String=”Hello”;
private function doInit(evt:Event) : void {
btn.addEventListener(“click”, function(evt:Event):void {
Alert.show( greeting + “, “ + txt.text);
});
}
</mx:Script>
<mx:Button id=”btn” label=”closure” />
<mx:TextInput id=”txt”/>
</mx:Application>
Compile and run this code – it shows a message box with the value of txt.text that was not defined
in the closure.
1 Closures are functions that are defined in a class or function context and passed to another
object for execution at a later time.
2. A closure’s “attachment” happens at runtime (and can be executed multiple times during an
application run). It’s just the stack-frame allocation where all context variables (“greeting,” in
our case) are being saved for later use. In most cases it’s about surrounding variables of the
hosting function and current runtime class instance.
3. Finally, closure’s execution can happen at any time, and can also have parameters when it’s
called. A standard convention is to have an Event object passed in with information from the
calling object.
It seems you can use closures to “snapshot” any number of parameters. Unfortunately, that’s true
for some dynamic languages, but not for ECMAScript ones like ActionScript and JavaScript. Let’s
illustrate the difference with a few examples. First, let’s make sure that the ActionScript closures are
compile-time artifacts rather than true dynamically interpreted counterparts. Just swap the order
of the closure and greetings definition statements.
<?xml version=”1.0”?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
layout=”vertical” creationComplete=”doInit(event)”>
<mx:Script>
import mx.controls.Alert;
private var myClosure :Function = function(evt:Event) {
Alert.show( greeting + “, “ + txt.text);
}
private function doInit(evt:Event) : void {
btn.addEventListener(“click”, myClosure);
}
private var greeting:String=”Hello”;
</mx:Script>
<mx:Button id=”btn” label=”closure”/>
<mx:TextInput id=”txt”/>
</mx:Application>
It still works even though “greeting” should have been undefined at the time of the closure defini-
tion – proving that just the reference is being used. Also, unlike Java, the scope of an object is the
stack-frame content of the enclosing function or class. Here is an example that wouldn’t compile in
Java, but is perfectly legal in AS3:
Flash is a stack machine. A closure is a stack variable in the enclosing function, and this stack-
frame approach greatly simplifies the implementation of closures and code optimizers based on
the stack, even though it requires some adjustments in coding style. Another issue is that we don’t
have object values here – everything is done by reference. Let’s modify the greeting’s value right
before the call:
As you can see, the greeting was replaced on an alert screen with the new value – it wouldn’t happen
if the “closure” used a greeting reference by value at the time of definition.
Closures are first-class citizens of ActionScript. Every method in your class is a closure. That’s how
it knows the instance variables of the class. Essentially every class is a big closure. You can write a
function with closures inside that would be very much a class for all practical purposes.
Closures are unavoidable when you use asynchronous operations or need to process an event on
the other object. Almost any non-trivial action in Flex – communication with the server, say, or get-
ting input from a user – is asynchronous. Using closure automatically gives you the reference to the
class instance in which you have your function to the external object processing the event. That’s
sufficient for processing the asynchronous method’s results in most cases. Automatic pointing of
this context to the instance defining the function greatly simplifies the coding since it’s natural to
the developer.
Before Flex 2, in Flex 1.5 developers were responsible for supplying context to the closure. The abil-
ity to replace the closure context gives greater flexibility to the code and makes it truly dynamic.
The next code sample shows a closure on an arbitrary object to provide a custom context object:
args[“push”].apply(args, params);
return func.apply(target, args);
};
var _f:Object = f;
_f.target = context;
_f.func = func;
_f.params = pms;
return f;
}
}
<mx:Script>
<![CDATA[
import mx.controls.Alert;
private var myClosure:Function ;
private function onCreationComplete (evt:Event):void {
myClosure = Closure.create({greeting:”Good evening”},function(name:String):void
{
Alert.show( this.greeting + “, “ + name);
},”world”);
var greeting:String;
greeting =”Hello”;
}
]]>
</mx:Script>
<mx:Button id=”btn” label=”closure” click=”myClosure()” />
</mx:Application>
Now the alert shows “Good evening, world” because the method has been applied using a differ-
ent context. Often this methodology is called “delegation” and is used by business frameworks to
centralize the processing of certain events.
The example above illustrates the relationship between context, functions, and closures. Using this
technique lets you implement dynamic inheritance, polymorphism, and other OO concepts.
Java 6 doesn’t support closures, but they may be introduced in Java 7. Closure functions weren’t
included in the original Java specification because back then the plan was to allow object creation
only in the heap memory if a new operator was called. But Java 5 introduced auto-boxing, the first
violation of this principle because objects were created dynamically behind the scenes. If you find
the concept of closures appealing, we’d recommend taking a look at products like BeanShell for
Java and other Java interpreters that let you define whole classes or just methods as closures.
The closest constructs to closures in Java are anonymous inner classes (see section 15.9.5 of the
Java Language Specification).
Let’s consider an example of an event listener in Java Swing where you define an anonymous class
at the moment a listener is added. The following Java code snippet adds an event listener to a but-
ton:
}
} // end of anonymous class declaration
);
This code means that the addActionListener() method in Java requires an instance of the listener
class as an argument. But since this listener will only be used by this button, why bother even nam-
ing the class? The code above (starting with new and ending with a curly brace) defines and creates
an instance of an anonymous class and overrides the method actionPerformed() that processes a
clicked event. Looks a bit convoluted, doesn’t it?
In AS3, you just define a function and pass it to the listener as an argument for an execution. For
example:
myButton.addEventListener(“click”, placeOrder);
Here placeOrder is a function closure that defines the business logic; it’s passed to the method ad-
dEventListener() and is executed as soon as the button is clicked.
To pass a closure to another method and execute it, Flex creates a dynamic object behind the scenes
and wraps the closure up. In the example below, we define the following function closure:
gotoWebPage(theURL: String) {
// open a specified Web page in a new Web browser’s window
getURL(theURL, “_blank”);
}
Let’s pass the reference to this to a timer function. The next line will execute the function gotoWeb-
Page() in five seconds while passing it the target URL as an argument:
Interestingly enough, the utility function setTimeout() is itself a closure. Adobe’s language refer-
ence suggests using the Timer object instead for efficiency reasons: when you create an instance
of an object yourself (as opposed to the dynamic objects that are used with closures), the garbage
collector’s work becomes a bit easier. So setTimeout() and some other timing utility functions exist
in AS3 only for backward compatibility/simplicity reasons.
Asynchronous Programming
Traditional Java programmers have to get used to the fact that when a client makes an RPC call to a
server, it actually just requests the execution of this method, allowing the user to continue working
with the application. It doesn’t block until the result comes back. After some time, which could be
as long as several seconds, the result or error message can come back to the client, and it needs to
remember which component has sent this request and process it accordingly. You’ll see an example
of such an application in Chapter 5. Meanwhile, we’ll walk you through a high-level overview of the
communication process.
ActionScript doesn’t have an explicit multithreading API. It can be emulated by running multiple
instances of the player within the hosting page, but it’s not a trivial task. On the bright side, Flex
makes standard tasks that require multithreading much simpler. Instead of explicit multithread-
ing, the classes that need to be executed asynchronously use pre-built Flash player components
that handle all the tracking and optimization.
A financial news service from Yahoo accessed via an HTTPService is a good example of asynchro-
nous communication:
The last two lines mean the following: request the news about Adobe (ADBE), and expect the result
to come back as an instance of the AsyncToken object.
Flash Player takes care of tracking multiple requests and the invocation of the responders’ methods
upon completion. A responder specifies that upon return, Flash Player calls processBusinessNews
when successful and processBusinessNewsErrors if it fails. The processBusinessNews function is
also known as an event handler and must be present in the code.
Data Binding
The Flex Developers Guide states that “Data binding is the process of tying the data in one object to
another object. It provides a convenient way to pass data around in an application.”
We’d like to offer you another definition: data binding is the ability of one object to watch the chang-
es of a specified property(ies) on another object, expression, or a function that returns a value.
To watch such changes in Java, you’d need to write and register listeners in one object, while an-
other object has to fire appropriate events when the property in question changes. Even though
AS3 has similar language constructs, there’s a much easier way to do this in Flex.
Flex offers you several ways of binding data between the objects using a very simple syntax and
the job of creating listeners will be done for you automatically without having to write such code
manually. You can review the listeners and other generated code by using the compiler option –
keep-generated-actionscript=true.
Binding in MXML
Just to give you a quick peek into data binding in its simplest form, look at the sample application
in Listing 4.6 that consists of a TextInput field and a label. The text of the label is bound to the text
of the input field by a simple use of curly braces:
text=”{myTextField.text}”
This line “tells” myLabel: “Watch the text property of the object called myTextField and as soon as
it gets modified, update yourself.”
You won’t find any listener declaration or firing events in the code below. The very fact that we’ve
put the text property in curly braces will force the Flex compiler to generate all the required AS3
listeners, event dispatchers, and binding automatically.
This application may seem pretty useless, but we’ll give you plenty of real-world examples that
demonstrate the power of data bindings in every chapter in this book. These are just some of the
nearest examples:
But to understand these and other examples, we have to cover some data binding basics.
In each pair of bound objects there’s a source, destination, and triggering event. In our example
myTextField is the source, myLabel is the destination, and the “change” of the text in the myText-
field is the triggering event. You can bind more than two objects by creating a so-called bindable
property chain: object A is a source for destination B, which in turn is a source for destination C
and so on.
To specify binding in MXML, you can use either the curly braces as we did before, or a dedicated
<mx:Binding> Tag. The previous example can be rewritten as follows:
Your program can have multiple <mx:Binding> tags using the same destinations and/or sources.
Binding Expressions
To complicate our example a little bit, we’ll add one more destination:
<mx:Label id=”myTwoPlusTwoLabel”
text=”{2+2+ Number(myTextField.text)}” x=”69” y=”109” width=”150” />
Now we have one source and two destinations (two labels). But more importantly, we’ve included
an expression inside the curly braces. If you run this program, it’ll show 4 as the value of the second
label. Start typing digits in the text field and both labels will immediately reflect the changes and
the value in the second label will be greater by 4.
Entering an alpha character will display NaN (not a number) as the result of our expression evalu-
ation.
On the same note, you can use an AS3 function in the binding expression as long as it returns a
value.
The Flex compiler generates bindable wrappers in AS3 for each property or expression that is be-
ing watched (i.e., PropertyWatcher), and it’ll generate all the required AS3 code for event process-
ing (see the section on events later in this chapter). And of course, it’ll create an instance of an
mx.binding.Binding object that ties everything together.
Metatags are a way of providing compilers/linkers with information that’s not part of the lan-
guage. In the Java universe, annotations are peers of AS3 metatags. For data binding, AS3 offers
the metatag [Bindable]. The information in the metatags is used to generate additional framework
code and instruct the compiler to use the generated code whenever the annotated properties/
methods are used.
For example, let’s see the inner workings of our TextImput/Label binding example (the code is gen-
erated by the Flex compiler). We start in the source code of the TextInput control and analyze the
declaration there. This is what we find:
[DefaultBindingProperty(source=”text”, destination=”text”)]
[DefaultTriggerEvent(“change”)]
[Bindable(“textChanged”)]
[NonCommittingChangeEvent(“change”)]
These binding declarations cause the compiler to generate the following data structures:
myLabel.text = _sourceFunctionReturnValue;
},
“myLabel.text”);
_bindings[0] = binding;
…
watchers[1] = new mx.binding.PropertyWatcher(“myTextField”,
{
propertyChange: true
}
);
watchers[2].addListener(bindings[0]);
watchers[1].addChild(watchers[2]);
bindings[0].uiComponentWatcher = 1;
bindings[0].execute();
What about watching not just the properties but the expressions? Consider this one:
2+2+ Number(myTextField.text)
It works the same way. The Flex compiler automatically generates an anonymous wrapper function
for the source of the event, which is an expression:
function():String {
var result:* = (2+2+ Number(myTextField.text));
var stringResult:String = (result == undefined ? null : String(result));
return stringResult;
}
If you’d like to learn more about binding internals read the section in the Flex Developer’s Guide
called “About the Binding Mechanism.”
Binding in ActionScript
You can put the [Bindable] metatag above one or more properties of an AS3 class, but if you’d like all
the properties of the class to be bindable, just add one [Bindable] metatag above the class definition:
[Bindable]
public class myClass{
…
}
If you don’t specify which event should trigger an update of the destination, Flex will use proper-
tyChange by default. But this metatag allows another syntax that lets you specify any other appli-
cable event name.
For example, if the variable price should trigger some actions when the stock price changes, you can
define a custom event priceChanged (described later in this chapter) and use the following syntax:
[Bindable(event=”priceChanged”)]
var price:Number;
A quick peek at the generated folder reveals that the [Bindable] metatag causes the compiler to
generate a shadow class with getters/setters for each bindable property. In the setter method the
compiler adds a dispatch event to notify listeners of the object change. Also, the destination object
automatically gets a binding/watcher for the respective source.
For details, check out the documentation for the classes BindingUtils and ChangeWatcher.
to a Flex application from the HTML wrapper generated by Flex Builder, and then you’ll see how to
use the binding inside a text string.
Our next assignment will be to write a Flex application that will run against different servers (dev,
uat, prod) without having to recompile SWF. It doesn’t take a rocket scientist to figure out that the
URL of the server should be passed to SWF as a parameter, and we’ll do this by using a special flash-
Vars variable in the HTML wrapper. Flex’s documentation suggests including flashVars parameters
in the Object and Embed tags and reading them using Application.application.parameters in AS3
code. As this was written, this doesn’t work. But as the ancient saying goes, “Adobe closes one door
but opens another one.” But first, let’s get familiar with Flex code:
<mx:Label text=
“Will run the app deployed at http://{serverURL}:{port}/MyGreatApp.html” />
<mx:Script>
<![CDATA[
[Bindable]
var serverURL:String;
[Bindable]
var port:String;
function initApp():void{
serverURL=Application.application.parameters.serverURL;
port=Application.application.parameters.port
}
]]>
</mx:Script>
</mx:Application>
The script portion of this code gets the values of parameters serverURL and port (defined by us)
using the Application object. We’ll add the values of these parameters to the HTML file as described
below. These values are bound to the MXML label as a part of the text string.
If you’ll open the HTML file generated, you’ll find the JavaScript function AC_FL_RunContent that
includes flashVars parameters in the form of key-value pairs. For example, in our sample application
it looks like this:
“flashvars”,’serverURL=MyDevelopmentServer&port=8181&historyUrl=history.
htm%3F&lconid=’ + lc_id
Run the Application and it’ll display the URL of the server it connects to. If you’d like to test your ap-
plication against a QA server, just change the values of the flashVars parameters in the HTML file.
We have one last little wrinkle to iron out: if you manually change the content of the generated HTML
file, next time you clean the project in Flex Builder, its content will be overwritten and you’ll lose the
added flashVars parameters. There’s a simple solution to this problem: instead of adding flashVars
parameters to the generated HTML, add them to the file index.template.html from the html-template
directory, which Flex Builder uses to generate the run and debug versions of the HTML wrapper.
Of course, this little example doesn’t connect to any server, but it gives you an idea of how to pass
the server URL (or any other value) as a Flash parameter, and how to assemble the URL from a mix
of text and bindings
The other drawback to using binding to tie together properties of different components is that it as-
sumes some knowledge about the component internals. It makes application design a bit complex
because it statically links components together and makes changes interdependent. It also requires
the compiler to generate a lot of cross-referencing code that consumes both time and memory.
Alternative architecture is to use loosely bound components. You can read about them in the sec-
tion on Custom Events below.
We’ll tell you a story that might have happened in real life, but first, we’ll remind you of the old
Indian tale about seven blind men and an elephant. One blind man touched the elephant’s head,
another one the tail, another was by the leg and each of them visualized the elephant differently
based on what he touched.
Students usually arrive in the classroom early, but this time three seats were empty. Five minutes
later the instructor got a phone call from one person explaining that the three had gotten stuck in
the elevator and would be there for another 15 minutes until the serviceman arrived. Needless to
say each of them had a laptop (do not leave home without one), so the instructor gave them a short
assignment to help them use the time productively. Here’s the assignment:
Create a window with a panel that can resize itself with the click of a +/- button located in the right-
hand corner of the panel. One click should minimize the panel’s height to 20 pixels, and a subsequent
one should maximize to 100 pixels, and so on. For example, these are the two states of such a panel:
package {
import mx.containers.Panel;
public class ResizableJPanel extends Panel {
// state of the panel
private var isPanelMinimized:Boolean;
isPanelMinimized=state;
}
<mx:Script>
<![CDATA[
function resizePanel(thePanel:ResizableJPanel):void{
if (thePanel.minimized){
minimizeActions.text=”-”;
thePanel.resizeMe();
} else {
minimizeActions.text=”+”;
thePanel.resizeMe();
}
}
]]>
</mx:Script>
</mx:Application>
package{
import mx.containers.Panel;
public dynamic class ResizableSmtPanel extends Panel
{
}
}
<![CDATA[
function resizePanel():void{
if (thePanel.minimized){
minimizeActions.text=”-”;
thePanel.minimized=false;
thePanel.height=thePanel.maxHeight;
} else {
minimizeActions.text=”+”;
thePanel.minimized=true;
thePanel.height=thePanel.minHeight;
}
}
]]>
</mx:Script>
Fifteen minutes later, the three students were in the classroom, and each got an “A” for this elevator
job. And here’s the Flex version:
[Bindable]
public var minimized:Boolean = false;
</mx:Script>
</mx:Panel>
</mx:Component>
There’s another simple solution to this particular assignment and we’ll let the reader try to figure it
out (hint: use states).
What’s the moral of this story? Learn ANOTHER language, no matter what your current background
is. Initially you’ll try to bring your own culture to this new language, but eventually your horizons will
broaden and you’ll become a better programmer.
Object-Oriented ActionScript
You know the drill: a language is called object-oriented if it supports inheritance, encapsulation,
Inheritance lets you design a class by deriving it from an existing one. This feature allows you to
reuse existing code without copying and pasting. AS3 provides the keyword extends for declaring
inheritance.
package com.theriabook.oop{
public class Person {
var name:String;
}
}
package com.theriabook.oop{
public class Consultant extends Person{
var dailyRate:Number;
}
}
package com.theriabook.oop{
public class Employee extends Person{
var salary:Number;
}
}
Encapsulation is an ability to hide and protect data. AS3 has access-level qualifiers such as public,
private, protected, and internal to control the access class variables and methods. Besides Java-like
public, private, protected, and package access levels, you can also create namespaces in AS3 that
will give you another way to control access to properties and methods. This chapter includes some
basic samples of namespaces, and you may want to read about the component manifest tiles in
Chapter 11.
However, if Java enforces an object-oriented style of programming, this isn’t the case with AS3, be-
cause it’s based on the scripting language standard. Object-oriented purists may not like the next
code snippet, but this is how a HelloWorld program can look in AS3:
trace(“Hello, world”);
That’s it. No class declaration is required for such a simple program, and the debug function trace()
can live its own class-independent life, as opposed to Java’s println() doubly wrapped in the Sys-
tem and PrintStream classes. You can write your own functions, attach them to dynamic objects,
and pass them as parameters to other functions. AS3 supports a regular inheritance chain as well
as so-called prototype inheritance where you can add new properties to the class definitions and
they become available to all instances of the class. Moreover, you can disable the validation of the
properties and methods during compilation by turning off the “strict” mode. In Java, behind every
object instance there’s an entity of the type Class. This is not an object itself, but it’s put in memory
by class loaders.
To illustrate how you can design AS3 programs with interfaces, we’ll add some behavior to the
classes from Listing 4.14. Let’s work on the following assignment.
A company has employees and consultants. Design classes to represent the people working in this
company. The classes can have the following methods: changeAddress, giveDayOff, increasePay. Pro-
motion can mean a day off and a salary raised a specified percentage. For employees, the increasePay
method should raise the yearly salary and, for consultants, it should increase their hourly rate.
First, we’ll add all the common methods that are applicable to both employees and consultants to
the Person class.
package com.theriabook.oop {
public class Person {
var name:String;
In the next step, we’ll add a new behavior that can be reused by multiple classes: the ability to in-
crease the amount of a person’s paycheck. Let’s define a Payable interface:
package com.theriabook.oop
{
public interface Payable
{
function increasePay(percent:Number): String;
}
}
package com.theriabook.oop
{
public class Employee extends Person implements Payable
{
public function increasePay(percent:Number):String {
// Employee-specific code goes here …
return “Class Employee:Increasing the salary by “+ percent + “%\n”;
}
}
}
Listing 4.17 The AS3 class Employee implementing the Payable interface
package com.theriabook.oop
{
public class Consultant extends Person implements Payable {
}
}
}
When the Consultant class declares that it implements a Payable interface, it “promises” to pro-
vide implementation for all the methods declared in this interface – in our case there’s just one
increasePay()method. Why is it so important that the class “keeps the promise” and implements all
the interface’s methods? An interface is a description of some behavior(s). In our case the Payable
behavior means the existence of a method with the signature boolean increasePay(int percent).
If any other class knows that Employee implements Payable, it can safely call any method declared
in the Payable interface (see the interface example in the Promoter class in Listing 4.19).
In Java, besides method declarations, interfaces can contain final static variables, but AS3 doesn’t
allow anything in the interfaces except method declarations.
Interfaces are another workaround for adjusting to the absence of multiple inheritance. A class
can’t have two independent ancestors, but it can implement multiple interfaces, it just has to im-
plement all the methods declared in all the interfaces. One way to implement multiple inheritance
(that we often use but don’t recommend it) is to use an “include” statement with the complete
implementation of all classes implementing interface:
But if a program such as Promoter.mxml (see Listing 4.19) is interested only in Payable functions, it
can cast the object only to those interfaces it intends to use. For example:
Now we’ll write an MXML program Promoter that will use the Employee and Consultant classes
defined in Listings 4.17 and 4.18. Click on the button and it’ll create an array with a mix of employ-
ees and consultants. Iterate through this array and cast it to the Payable interface, then call the
increasePay()method on each object in this collection.
<mx:Script>
<![CDATA[
import com.theriabook.oop.*;
function startPromoter():void{
output.text=”Starting global promotions...\n”;
The line p.increasePay(5) in the listing above may look a little confusing. How can we call a con-
crete increasePay method on a variable of an interface type? Actually we call a method on a con-
crete instance of the Employee or a Consultant object, but by casting this instance to the Payable
type we’re just letting the AVM know that we’re only interested in methods that were declared in
this particular interface.
Polymorphism – When you look at our Promoter from Listing 4.19, it looks like it calls the same
increasePay()method on different types of objects, and it generates different outputs for each type.
This is an example of polymorphic behavior.
In the real world, array workers would be populated from some external data source. For example,
a program could get a person’s work status from the database and instantiate an appropriate con-
crete class. The loop in Promoter.mxml will remain the same even if we add some other types of
workers inherited from the Person class! For example, to add a new category of worker – a foreign
contractor, we’ll have to create a ForeignContractor class that implements the increasePays method
and might be derived from the Person class. Our Promoter will keep casting all these objects to the
Payable type during runtime and call the increasePay method of the current object from the array.
Polymorphism allows you to avoid using switch or if statements with the checking type operator
is. Below is a bad (non-polymorphic) alternative to our loop from Promoter.mxml that checks the
type of the object and calls the type-specific methods increaseSalary() and increaseRate() (assum-
ing that these methods were defined):
You’d have to modify the code above each time you add a new worker type.
There is another urban myth that reflection is slow, and you should use it only if you have to. But
this consideration isn’t valid in programs that run on the client’s PCs, because we don’t have to
worry about hundreds of threads competing for a slice of time on the same server’s CPU(s). Using
reflection on the client is fine. Even on the server proper the combination of reflection with caching
allows you to avoid any performance penalties.
AS3 provides very short and elegant syntax for introspection, and we’d like to spend some time il-
lustrating polymorphism without the typecasting and strict Java-style coding.
Let’s revisit our sample application. Workers get pay and benefits and vacations; consultants are
paid hourly wages. But retirees may have some form of receiving pensions, the board of directors
might get paid but no benefits – are they workers? No, they’re not and their objects may not neces-
sarily implement the Payable interface, which means that the typecasting from Listing 4.19 would
cause a runtime exception.
How about raising the compensation of every Person even if it doesn’t implement Payable? If one
of these objects sneaks into the workers array , simple casting to Payable as shown below will throw
an exception:
Payable p = Payable(workers[i]);
This short loop deserves an explanation. First, we’ve declared a variable p of type *. This declaration
means that p can be any type. Using an asterisk a bit more open than var p:Object; allows the vari-
able p to have a special value of an undefined type as used in the above code sample.
It means “Get a reference to the increasePay()function from the array element workers[i].” You may
ask, “Why use the brackets around increasePay instead of the dot notation?” The reason is that dot
notation would ask the compiler to find and validate this function, while the brackets tell the com-
piler not to worry about it, the program will take care of this little something inside the brackets
during runtime.
Basically, the single line above performs the introspection and gets a pointer to the increasePay
function for future execution in the line:
If this particular element of the workers array doesn’t have increasePay defined (its class must be
declared dynamic), add “no luck” to the text field. Otherwise execute this object’s version of in-
creasePay, passing the number five as its argument. The line above is still a potential problem if
the class doesn’t have the increasePay function, but has a property with the same name. The better
version looks like this:
Let’s emphasize that again: this increasePay method doesn’t have be defined in any interface.
Java programmers would call this wild anarchy. Of course, adhering to strict rules and contracts in
Java leads to more predictable code and less surprises at runtime. But modern Java moves toward
dynamic scripting, adding implicit typecasting, runtime exceptions, etc. Overuse of interfaces, pri-
vate, protected, and other “nice clean object-oriented techniques” doesn’t promote creative think-
ing in software developers. We hope all code samples in this chapter break the OOP spell that Java
developers live under.
Namespaces in ActionScript
Namespaces in AS3 as in MXML are used to limit the scope (visibility) of methods, properties, or
constants. They’re also used to avoid naming conflicts in cases where you create your own custom
components that may have the same names as the Flex Framework or other vendor’s counter-
parts.
You can think of access control keywords – public, private, protected, and internal – as built-in
namespaces. If a method has been declared as
protected calculateTax(){}
you can say that the calculateTax()method has a protected namespace. But AS3 lets you define your
own namespaces to use instead of these standard language qualifiers.
To introduce your own namespace, you need to take the following steps:
• Declare a namespace
• Apply the namespace
• Reference the namespace
Let’s write a simple program for an accountant who calculates taxes, but customers who belong
to the Mafia would pay only half the amount. To do this, we’ll start by declaring two namespaces:
regular and riabook.
package com.theriabook.namespaces {
public namespace mafia=”http://www.theriabook.com/namespaces”;
}
Please note that using a URI in the namespace declaration is optional. The listing below doesn’t use
any explicit URI, but the compiler will generate one.
package com.theriabook.namespaces {
public namespace regular;
}
To apply the namespaces, we’ll define a Tax class with two calcTax()methods that will differ in their
namespace access attributes and the amount of tax “calculated”:
package com.theriabook.tax{
import com.theriabook.namespaces.*;
public class Tax
{
regular static function calcTax():Number{
return 3500;
}
riabook static function calcTax():Number{
return 1750;
}
}
}
package com.theriabook.test
{
import com.theriabook.namespaces.*;
import com.theriabook.tax.Tax;
import mx.controls.Alert;
var tax:Number;
tax=Tax.calcTax();
Alert.show(“Your tax is “+ tax,”Calculation complete”);
}
}
}
Since we apply the namespace for the regular customer, s/he will have to pay a tax of $3,500. The
MXML code that uses TestTax is shown below:
The output of this program looks like Figure 4.6. Switch to another namespace by changing the use
statement to look like
and the amount of the tax to be paid will be substantially lower. Besides the directive use that af-
fects the entire block of code, AS3 permits finer-grained notation to refer to a specific namespace
with a name qualifier (a double colon). In our example, this may look like:
tax = Tax.riabook::calcTax();
Using namespaces provides an additional means of visibility control. The methods, class proper-
ties of the constants, can be physically located in different packages, but marked with the same
namespace qualifier, and a one-line namespace change can engage a completely different set of
methods/properties across the entire application.
We’ll show you a really simple application written in Flex 2 that talks to a JSP that generates XML
with the information about employees:
<people>
<person>
<name>Alex Olson</name>
<age>22</age><skills>java, HTML, SQL</skills>
</person>
...
</people>
Let’s just hardcode this XML (we’ve got three persons) into a JSP that consists of one out.println()
statement, where the XML goes between the double quotes:
<%out.println(“...”); %>
The complete JSP looks like this (just put your XML in one line so you won’t be bothered with
string concatenations):
<%
out.println(“<?xml version=\”1.0\” encoding=\”UTF-8\”?><people><person><name>Alex Ol-
son</name><age>22</age><skills>java, HTML, SQL</skills></person><person><name>Brandon
Smith</name><age>21</age><skills>PowerScript, JavaScript, ActionScript</skills></person>
<person><name>Jeremy Plant</name><age>20</age><skills>SQL, C++, Java</skills></person></
people>”);
%>
Deploy this JSP under some servlet container. In the popular Apache Tomcat this means to save
it as employees.jsp under the webapp\test directory. As a sanity check we make sure that we’ve
deployed this JSP correctly: entering http://localhost:8080/test/employees.jsp in the Web browser
has to return the employee data. Now open Flex Builder and create the application:
</mx:columns>
</mx:DataGrid>
</mx:Application>
This code uses the <mx:HTTPService> component that lets you connect to a specified URL either
directly or through a proxy. The HttpService object is designed to communicate with any URI that
understands HTTP requests and responses. In the code above we’ve just specified the URL for the
JSP from Listing 4.24. The data provider of our data grid uses binding (see the curly braces) and
E4X syntax to parse the XML and populate this table with the elements located under the <person>
XML tag that’s coming from our employees.jsp. In the next section we’ll explain Flex data binding
in more detail.
On the applicationComplete event, the code employees.send() makes an HTTP request to the URL
specified in the HTTPService, and our JSP readily returns the XML that’s bound to the data grid.
Compile and run this program, and it’ll show you the following:
Keep in mind that such a direct connection from HTTPService to a JSP is only permitted if your
JSP and Flex application are coming from the same domain, or if the Web server you’re connecting
to has the crossdomain.xml file specifying a cross-domain connection policy with the appropriate
permission for yours or all domains. You can read more about configuring crossdomain.xml in the
product manual under “Building and Deploying Flex 2 Applications.”
To design the form, we’ll be using the <mx:Form> Flex objects container, which differs from the
HTML tag <form>. The latter is an invisible container that holds some data, while <mx:Form> is
used to arrange the input controls on the screen with their labels. We’ll also use <mx:Model> to
store the data bound to our <mx:Form>. Let’s also make the employee’s name a required field and
add a so-called validator to prevent the user from submitting the form without entering the name.
It will look like:
<mx:Model id=”employeeModel”>
<root>
<empName>{empName.text}</empName>
<age>{age.text}</age>
<skills>{skills.text}</skills>
</root>
</mx:Model>
The required=true attribute displays a red asterisk by the required field but doesn’t do any valida-
tion. The <mx:StringValidator> displays the prompt “This field is required” and makes the border
of the required field red if you move the cursor out of the name field while it’s empty, and shows a
prompt when you return to this field again as in Figure 4.8. But we’d like to turn this default valida-
tion off by adding the triggerEvent property with a blank value:
We’ll also add our own AS3 validateEmpName()function. Now the click event of the Add Employee
button will call validateName(), which in turn will either call the submitForm()function if the name
was entered or display a message box “Employee name can not be blank”.
Validators are outside the scope of this chapter, and so we’ll just mention that Flex comes with a
number of pre-defined classes that derive from the base class Validator. They ensure that the input
data meet certain rules. The names of these classes are self-explanatory: DateValidator, EmailVali-
dator, PhoneNumberValidater, NumberValidator, RegExValidator, CreditCardValidator, ZipCode-
Validator, and StringValidator. These validators work on the client side, and round-trips to the serv-
er aren’t required. A program initiates the validation process either as a response to an event or by a
direct call to the method validate() of the appropriate validator instance as in Listing 4.30
The final version of the Flex portion of our application is shown below.
</mx:columns>
</mx:DataGrid>
<mx:Script>
<![CDATA[
import mx.events.ValidationResultEvent;
import mx.controls.Alert;
private function validateEmpName():void{
if (empNameValidator.validate().type == ValidationResultEvent.VALID){
submitForm();
} else{
Alert.show(“Employee name can not be blank”);
}
}
When the user hits the Add Employee button on the form, our HTTPService will submit the employ-
eeModel to a modified employees.jsp, which will now get the parameters from the HTTPRequest ob-
ject, prepare the new XML element newNode from the received data, concatenate it to the original
three employees, and return it back to the client, which will display all the employees in the datagrid:
<%
String employees=”<?xml version=\”1.0\” encoding=\”UTF-8\”?><people><person><name>Alex
Olson</name><age>22</age><skills>java, HTML, SQL</skills></person><person><name>Brandon
Smith</name><age>21</age><skills>PowerScript, JavaScript, ActionScript</skills></person>
<person><name>Jeremy Plant</name><age>20</age><skills>SQL, C++, Java</skills></person>”;
You’ll see more examples of the use of HTTPService object in Chapter 5, where we’ll retrieve finan-
cial news from Yahoo!, and in Chapter 13, where we’ll download photos from the popular Flickr.
com. In Chapter 5 we’ll also use HTTPService through a proxy configured with FDS.
Note: There are other ways to pass the data from Flex to a server-side Web application. For example,
you can create an instance of the URLVariables object, create the data to be passed as its properties,
attach URLVariables to URLRequest.data, and call navigateToURL().
ActionScript 3.0 supports E4X, which is an ECMA standard for working with XML (see http://www.
ecma-international.org/publications/files/ECMA-ST/ECMA-357.pdf). It’s very powerful and yet
simple to use. You can forget about these SAX and DOM parsers. E4X is a step towards making XML
a programming language.
For example, an MXML program can read the XML file people.xml (or any other XML source) shown
in Listing 4.23 into a variable with only one line (without worrying about error processing):
You’ll need another line of code to populate the data grid using Flex data binding (remember, tying
the data from a source to a destination). In our case myXmlFile is the source that populates the data
grid aka destination:
<mx:DataGrid dataProvider=”{myXmlFile.person}”>
This line means that each element <person> will populate one row in the data grid. Let’s make the
XML from Listing 4.23 a bit more complex: we’ll introduce nesting in the name element. Now it
consists of separate <first> and <last> elements.
</person>
<person>
<name>
<first>Victor</first>
<last>Rasputnis</last>
</name>
<age>21</age>
<skills>PowerScript, JavaScript, ActionScript</skills>
</person>
<person>
<name>
<first>Anatole</first>
<last>Tartakovsky</last>
</name>
<age>20</age>
<skills>SQL, C++, Java</skills>
</person>
</people>
Please note that we also want to concatenate the values from the <first> and <last> XML elements
for the data grid’s Name column. A small program in Listing 4.30 does exactly this. The fullName
method concatenates the first and last names, and since we specified the labelFunction property
in the name column, the data rendering will be controlled by the fullName() function. We’ll return
to labelFunction in Chapter 11.
The next step is to add regular expressions to filter the data while populating the data grid. There’s
a nice example of predicate filtering with E4X and RegExp in Darron Schall’s blog at http://www.
darronschall.com/weblog/archives/000214.cfm.
Let’s imagine that a recruiter wants to do a quick search in our XML file to identify people with Java
skills. A small one-line change will do this trick, or at least will be a step in the right direction.
The RegExp class lets you create an instance of the object per the specified pattern, and then find
the substring(s) with this pattern and perform the manipulations with the found substrings, if
any.
In AS3, you can create an instance of the RegExp by using a familiar syntax with a constructor. For
example:
This is a pattern for finding occurrences of “Java,” ignoring the letter case.
We’ll use the latter syntax by feeding the E4X output to this RegExp instance and the result will be
used as a data provider for the data grid. Let’s modify the MXML code for the <mx:DataGrid> tag to
In the line above, /Java/ creates an instance of the RegEx object and the test(skills) method will
ensure that only those XML elements that contain Java are included in the myXmlFile. Now the
resulting window will look as follows:
We still don’t like a couple of things here. First, this output didn’t include Yakov Fain because the
word Java was written in lower case in his skills element. Adding the ignore case option “i” to our
RegExp instance will help:
The next step is to filter out people who were included in this list just because of JavaScript, which
has very little to do with Java. One of the ways to do this is by requesting that there should be a
space or a comma in the regular expression after the word Java:
<mx:DataGrid
dataProvider=”{myXmlFile.person.(/Java? ?,/i.test(skills))}” >
Now we’ve lost both Victor and Anatole. Even though Anatole knows Java, there’s no space or com-
ma after the word Java in his list of skills. Adding an OR (|) condition that means we’re also inter-
ested in people with the word Java as the last word in the string will help.
<mx:DataGrid
dataProvider=”{myXmlFile.person.(/Java? ?, | Java$/i.test(skills))}”
Today, E4X doesn’t support XML Schema, and all the XML elements are returned as text, but it’ll
change in future versions of the ECMAScript for XML. Meanwhile, the implementation of E4X by
any programming language makes it more appealing to developers who have to deal with XML.
Flex comes with a mx.collections package that contains collection classes that have convenient
methods to sort and filter the objects from the underlying collection like XML or array, and they also
fire events when the data in the collection change. This makes collection classes very convenient
data providers for Flex visual controls – as soon as the data change, visual controls that are bound
to this collection immediately reflect the change without any special programming required.
In this section we’ll build a small gas station application that will monitor daily operations like
gasoline sales. While building this application, you’ll get familiar with the XMLListCollection class
and learn how to filter the data in these collections.
The window output in this application will look like Figure 4.12. We’ll read the initial “gas station
activities” data from the following XML:
<messages>
<message msgType=”sale”>
<transID>1234</transID>
<octane>87</octane>
<price>2.50</price>
<gallons>10.2</gallons>
<paidby>MC</paidby>
</message>
<message msgType=”sale”>
<transID>1035</transID>
<octane>89</octane>
<price>2.69</price>
<gallons>14.5</gallons>
<paidby>Cash</paidby>
</message>
<message msgType=”spill”>
<transID>2301</transID>
<octane>93</octane>
<price>2.99</price>
<paidby></paidby>
<gallons>17.3</gallons>
</message>
</messages>
The final version of our application will include a timer with a random data generator that will
add new messages to the window from Figure 4.12, emulating the data feed of messages like sale,
purchase, and spill.
The first version of GasStation.mxml reads and parses the data from GSActivities.xml using this one-liner:
Behind the scenes, Flex creates an object with the reference variable activities used as a data pro-
vider for the data grid as follows:
The dataProvider activities.message represents the XML <message> element from GSActivity.xml,
which is displayed as a row in the data grid.
The AS3 paid() function is called for each datagrif row and calculates the amount by multiplying
the number of gallons and the price per gallon. The <mx:CurrencyFormatter> ensures that the cal-
culated “paid” column is displayed as a dollar amount.
The rest of the code below just displays other controls that we’ll use for filtering and illustrating
master-detail relations later in this section.
<mx:Script>
<![CDATA[
//Data for the Message type combo
[Bindable]
private var messageType: Array = [“all”,”sale”, “spill”, “purchase”];
total*=-1;
}
return “”+usdFormatter.format(total); //USD formatting
}
]]>
</mx:Script>
</mx:Application>
Please note that the combobox cbMsgTypes is populated from a messageType array that is marked
[Bindable] and will be used below for filtering the messages in the data grid. Also, since we didn’t
define the Paid By data grid column in this version of the gas station application, the corresponding
data from the data provider aren’t shown.
Adding XMLListCollection
Flex collection classes implement the Ilist and ICollectionView interfaces that let you add, remove,
and update items in a collection. These interfaces also have methods for dispatching events when
the data in the underlying collection change. This becomes handy when you use a collection as a
data provider of one of the list-based controls – just add a new element to such collection and the
data in these controls automatically reflect the change.
Using collections (see the mx.collections package) as data providers is well described at http://
www.adobe.com/devnet/flex/quickstart/using_data_providers/. We’ll just show you one of the
ways to deal with collections in our gas station application.
Basically we’ll add a middleman between the XML object and the data grid. Now the data grid’s
provider will become an XMLListCollection (built on top of XML activities):
Just recompile and run the application again – it will display the same window as in Figure 4.11.
Filtering
The next step is to allow the user to filter the data by octane (the checkboxes) or message type (the
combo box). We’ll add an init() function that will be called on the applicationComplete event, when
all the objects are constructed to assign the filterMessages() filter function to the collection to do
the filtering:
msgList.filterFunction=filterMessages;
The actual filtering will happen when we call the refresh()function on the collection.
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
backgroundColor=”#e0e0FF” applicationComplete=”init()”>
// some code is omitted here
private function init():void {
// assign the filter function
msgList.filterFunction=filterMessages;
// perform filtering
msgList.refresh();
}
return false;
}
If you need to remove the filter, just set the filterFunction property to null.
Run the application after making these changes and you’ll see an empty table on the screen. When
the creation of the application was complete, Flash VM called the init method, which assigned the
filter function to our XMLListCollection, and called refresh(), which applied this filter to each XML
node of our collection. Since none of the checkboxes was selected, the filterMessages function cor-
rectly returned false to each node leaving the data grid empty. To fix this, let’s make a slight change
in the checkboxes so they’ll be checked off during creation.
Now the program will show all the rows again. Try to uncheck the boxes – nothing happens because
the application doesn’t know that it needs to reapply the filter function to the msgList again. This is
an easy fix – let’s refresh the msgList on each click on the checkbox:
The filtering by octane number works fine. Adding the code snippet below to the beginning of the
filterMessages() function will engage the filtering by message type according to the combo box
selection:
Master-Detail Relationships
We took care of the basic functionality of the data grid control. Since the turnover rate at gas sta-
tions is pretty high, let’s add some help to new employees by populating the Required Actions text
area based on the selected message type. This is a typical master-detail relationships task, where
the data grid with messages is “the master” and the text box shows the details.
We’ll start by creating an actions.xml file where we store the recommended actions for each mes-
sage type.
<MessageTypes>
<message type=”sale”>
<description>Sale of gasoline products</description>
<actions>Sale is good news. No action required
</actions>
</message>
<message type=”purchase”>
<description>Purchase of gasoline products from suppliers</description>
<actions>If the gas station owner is not on premises, please call him at 212-
123-4567. Otherwise no actions is required
</actions>
</message>
<message type=”spill”>
<description>Spill of gasoline products on the ground</description>
<actions> Get a bucket of sand and cover the mess. Expect to receive smaller
pay check this week.
</actions>
</message>
</MessageTypes>
To read and parse this file into an XML object, we just have to write one line (thanks to
E4X):
The next step is to specify that a selection of a different row in the data grid should call the function
that finds and displays the appropriate message from MessageTypes.xml. And again, E4X makes
this job a breeze:
The expression
msgTypes.message.(@type==messageBook.selectedItem.@msgType )
means select the XML <message> element that has an attribute type that is the same as in the
selected row in the @msgType column in the data grid. When this XML element is identified, we
assign its <actions> value to the txtAction text area.
As we said earlier, changing the selected row in the data grid should initiate the getAction() func-
tion call. Let’s modify the declaration of the data grid and add the change event processing:
Compile and run this program, select a row in the data grid, and the action text box will be popu-
lated:
We’re almost there. Why almost? Because if the user starts filtering the data by octane or a message
type, the action text field won’t be cleaned. To fix this, let’s create a refreshData() function that will
not only refresh the XMLListCollection, but also clean the text field:
If the speed of your data feed is crucial, don’t pass the data as XML, and consider using ArrayCol-
lection for storing data instead of XMLListCollection.
</mx:columns>
</mx:DataGrid>
<mx:Label text=”Required actions” fontSize=”15” />
<mx:TextArea id=”txtAction” width=”100%”/>
</mx:VBox>
</mx:Canvas>
<mx:Script>
<![CDATA[
import mx.collections.*;
private var sortMessages:Sort;
[Bindable]
private var grandTotalSale:Number=0;
return false;
}
txtAction.text=msgTypes.message.(@type==messageBook.selectedItem.@msgType).
actions;
}
var gals:String=(numberFormatter.format(Math.random()*50).toString());
newNode=<message msgType={msgType}>
<transID>{transID}</transID>
<octane>{octane}</octane>
<price>{price}</price>
<gallons>{gals}</gallons>
<paidby>{payType}</paidby>
</message>;
We’ve chosen an XML data feed in this application just to introduce the reader to the ease of XML
parsing with E4X. In this case, the better performing solution would be to move the data from XML
to an AS3 data transfer object and use ArrayCollection instead of XMLListCollection. This AS3 ob-
ject should define getters that provide data to all the data grid columns, including the calculated
amount for the Paid column. Keeping calculations in the labelFunction paid() is not a good idea
because the label function is called for each visible row when the new XML element is inserted
into the underlying XML collection. Flash Player repaints each visible data grid row when each
new gas transaction is inserted, which means that the paid amounts for each visible row will be
recalculated.
While using XML and E4X may look very attractive, you shouldn’t forget that when you’re creating
your own AS3 classes, there’s less data to push over the wire.
All of the code for our gas station application fits in three pages of this book. You can create
simple prototype applications in Flex with a relatively small number of lines of code, but let’s not
fool ourselves: making efficient real-world applications still requires of programming in good
old Java.
Events
In object-oriented languages, if object A needs to notify object B about some important event, it’s
done using a so-called Observer design pattern; Java implements this pattern in the Observer in-
terface and Observable class. An observable object may have something interesting going on, and
other objects that want to know about this implement the Observer interface and register them-
selves with the observable class.
AS3 implements this design pattern using an event model. Objects can trigger events to each other.
System events are triggered by the AVM, while others are triggered as a result of user interactions
with your application, such as a click on a button or a mouse move. Below are some situations
when events can be dispatched (triggered):
In an MXML application you’d just specify the name of the event and its handler function (or in-
line code) in the attribute of the component without worrying too much about the underlying
AS3 code. But all Flex events are subclasses of flash.events.Event, and in AS3 programs you should
register an event listener to “listen” to this event and write a function to handle this event when it
arrives. For example, the next code snippet specifies that Flash Player has to call a method onEn-
teringFrame (written by you) on each EnterFrame event:
addEventListener(Event.ENTERFRAME, onEnteringFrame);
In Java, event listeners are objects, but in AS3 only functions or methods can listen to the events.
If you need to trigger an event from the ActionScript class, it has to be either a subclass of Event-
Dispatcher or implement the IEventDispatcher interface. The latter is the more preferred way be-
cause AS3 doesn’t support multiple inheritance, and your class may need to extend another class.
The other reason to use a lighter interface is that you may not need all the functionality that was
defined in the EventDispatcher class and implement the required interface method as you see fit.
For example:
Event Flow
When the event listener calls an event handler function, it receives an event object as a parameter,
which contains various attributes of the event, and the most important one is the event’s target.
This terminology might be a little confusing to Java developers since they refer to the component
that generates an event as an event source. But here we say that all events are generated by the
Flash Player. They are initiated at the stage level and flow to the target component (capturing the
stage), i.e., Button, Shape, etc.. After reaching the target, the event “bubbles” its way through to the
parents. So, when you click on a button, we can say that a button is the event target. If a button is
located on a panel, this event will flow from the stage to the panel and then to the button – and
then all the way back.
Flash Player 9 implements an event model based on the World Wide Web Consortium’s (W3C) speci-
fication entitled Document Object Model Events available at http://www.w3.org/TR/DOM-Level-
3-Events/events.html. According to this document, the lifecycle of an event that deals with display
objects consists of three phases: capture, target, and bubbling.
• Capture: During this phase, Flash Player makes a first pass to check every object from the root
of the display list to the target component to see if any parent component might be interested
in processing this event. By default, events are ignored by the parents of the target component
at the capture phase.
• Target: At this phase, event object properties are set for the target and all registered event
listeners for this target will get this event.
• Bubbling: Finally, the event flows back from the target component all the way up to the root
to notify all interested parties identified during the capture phase. Not all events have a bub-
bling phase and you should consult the AS3 language reference for the events you’re inter-
ested in.
The three event phases described above don’t apply to the user-defined events because Flash Player
9 doesn’t know about parent-child relations between user-defined event objects. But AS3 develop-
ers can create custom event dispatchers, if they want to arrange event processing in three phases.
</mx:Application>
Run this simple program in the debug mode to enable trace and it’ll show you the following out-
put:
Clicking on the button in the Flex Builder’s console will show the following:
This illustrates events propagation or bubbling: the click event bubbles up from the target (button)
to its parent (panel).
Now let’s create another version of this application, where the button and the panel as well as the
event processing are coded in AS3. This way you’ll see and appreciate all the legwork that MXML
did for us:
<mx:Script>
<![CDATA[
import mx.controls.Button;
import mx.containers.Panel;
myPanel=new Panel();
myPanel.width=200;
myPanel.height=150;
myPanel.title=”Just a Panel”;
addChild(myPanel);
If you run this code, the output will look like this:
This is not exactly the result we were looking for and the reason is simple: both the panel and the
button were added to the application’s display list independently. Let’s fix this by adding the button
to the panel by replacing addChild(myButton) with myPanel.addChild(myButton).
Now the hierarchy of the nodes in the display list will be different, and the node representing the
button will be created under the parent node of the panel as shown in Figure 4.16.
This is much better, but still not exactly the same as Figure 4.14. Let’s try to set the coordinate of the
myButton.x=60.5;
myButton.y=38;
It did not help because, by default, the panel container uses the vertical layout (see Chapter 3) and
ignores the absolute coordinates. Let’s add one line to change it into an absolute layout:
myPanel.layout=”absolute”;
Now if you run the application it’ll look the same as in Figure 4.13.
We’ve written a lot of ActionScript code, and we haven’t even processed the click events yet! We still
need to add event listeners and event handlers to the button and the panel:
<mx:Script>
<![CDATA[
import mx.controls.Button;
import mx.containers.Panel;
import flash.events.MouseEvent;
myPanel=new Panel();
myPanel.width=200;
myPanel.height=150;
myPanel.layout=”absolute”;
myPanel.title=”Just a Panel”;
addChild(myPanel);
]]>
</mx:Script>
</mx:Application>
Run this application in debug mode and the console screen will look the same as the MXML ver-
sion of our application:
The order of these messages is a clear indication that the target event was processed first and the
panel responded in the bubbling phase.
Typically, during the capture stage event, listeners on the parent components aren’t called, but
there’s a version of the addEventListener()method that can request calling the listeners during the
capture phase. To turn on event handling during the capture phase, you should use the three-argu-
ments version of the addEventListener() function in the panel:
When the third argument equals true, it tells the Flash Player that we are registering this particular
listener for the capture phase (there’s no way to do this in MXML). Now run the application through
the debug mode again and you’ll see that the panel responds first, then the target button. There’s
no event processing in the bubbling phase.
If you’d like to process parent events during both the capture as well as bubbling phase, register two
listeners for the panel – one with the three arguments and one with two. These listeners
myButton.addEventListener(MouseEvent.CLICK, buttonClickHandler);
myPanel.addEventListener(MouseEvent.CLICK, panelClickHandler, true);
myPanel.addEventListener(MouseEvent.CLICK, panelClickHandler);
will produce the output proving that the panel has processed the button click event twice: during
both the capture and bubbling phases.
Let’s make a change in the panel event handler to show how you can prevent the event from being
delivered to the target if something bad has occurred (from a business application perspective):
The stopPropagation() method can be called at any phase of the event flow. The line
myPanel.addEventListener(MouseEvent.CLICK, panelClickHandler);
means “listen to the click event, and when it’ll occur, call the function panelClickHandler.”
Why do we even need to know about these addEventListener() function calls? Well, first, there are
some classes that don’t have equivalents in MXML, hence you don’t have a choice. Second, if your
program is adding components dynamically, addListener() is your only choice since there’s no way to
use MXML notation there. And third, you may prefer writing your components only in AS3.
Custom Events
While Flex components come with their pre-defined events, developers can create custom events
specific to their applications. Event-driven programming is a very important design concept be-
cause it allows an application to react to user interaction without imposing a pre-defined “flow”
on the end user. It means that unlike back-end processes that tend to have a “single track of mind”
design, front-end applications have to react to what often seems like an unrelated sequence of end-
user actions. Fortunately, the event-driven model offers an excellent architecture for such interac-
tion based on loosely coupled components consuming and throwing the events.
This simply means a properly designed component knows how to perform some functionality and no-
tifies the outside world by broadcasting one or more custom events. We need to stress that such a com-
ponent doesn’t send these events to any other component(s). It just broadcasts its “exciting news” to
the event dispatcher. If any other component is interested in processing this event, it must register a lis-
tener for this event. Unlike direct component-to-component calls via public interfaces, this approach
lets you add processing components and set up priorities without affecting the working components.
Before explaining how to create an event-driven component, we’ll state how to use them. This is a
typical scenario: MyApplication uses Component1 and Component2. The components don’t know
about each other. Any event-handling component has to define this event inside.
For example, Component1 dispatches this custom event and sends out an instance of the event
object, which may or may not carry some additional component-specific data. MyApplication
handles this custom event and, if needed, communicates with Component2 with or without feed-
ing it with data based on the results of the first component event.
We’ll create a new shopping cart application that will include a main file and two components: the
first, a large green button, and the second, a red TextArea field. We’ll create two separate directories,
“controls” and “cart,” respectively, where our components will live.
To create our first MXML component in Flex Builder, select the “controls” directory and click on
the menu File | New MXML Component. In the pop-up screen we’ll enter LargeGreenButton as a
component name and we’ll pick Button from a dropdown as a base class for our component.
</mx:Button>
Next, we’ll make this button large and green with rounded corners (just to give it a Web 2.0 look).
This component will dispatch an event named greenClickEvent. But when? You’ve got it: when
someone clicks on large and green.
Custom events in MXML are annotated within the metadata tag to be visible to MXML. In Listing
4.41 we declared a custom event of the generic flash.events.Event type in the metadata tag. Since the
purpose of this component is to notify the sibling objects that someone has clicked the button, we’ll
define the greenClickEventHandler()event handler to create and dispatch our custom event.
<mx:Metadata>
[Event(name=”addItemEvent”, type=”flash.events.Event”)]
</mx:Metadata>
<mx:Script>
<![CDATA[
private function greenClickEventHandler():void{
trace(“Ouch! I got clicked! Let me tell this to the world.”);
dispatchEvent(new Event(“addItemEvent”, true));// bubble to parent
}
]]>
</mx:Script>
</mx:Button>
Please note that the LargeGreenButton component has no idea what will process its addItemEvent.
It’s none of its business – loose coupling in action!
In dynamic languages the following naming conventions are common practice: to add an “Event”
suffix to each of the custom events you declare, and a “Handler” suffix to each of the event-handler
functions.
<ctrl:LargeGreenButton greenClickEvent=”greenButtonHandler(event)”/>
<mx:Script>
<![CDATA[
private function greenButtonHandler(event:Event):void{
We have defined an extra namespace “ctrl” here to make the content of the “controls” directory vis-
ible to this application. Run this application in debug mode, and it’ll display the window in Figure
4.17. When you click on the green button it will output the following on the console:
Ouch! I got clicked! Let me tell this to the world. Someone clicked on the Large Green Button.
While adding attributes to <ctrl:LargeGreenButton>, please note that code hints work and Flex
Builder properly displays the greenClickEvent in the list of available events under the new custom
component button.
Our next component will be called BlindShoppingCart. This time we’ll create a component in the
“cart” directory based on the TextArea:
<mx:Script>
<![CDATA[
private function init():void{
parent.addEventListener(“addItemEvent”,addItemToCartEventHandler);
}
Note that the BlindShoppingCart component doesn’t expose any public properties or methods to
the outside world. It’s a black box. The only way for other components to add something to the
cart is by dispatching the addItemEvent event. The next question is how to map this event to the
function that will process it. When someone instantiates the BlindShoppingCart, Flash Player will
dispatch the creationComplete event on the component and our code will call the init() private
method that adds the addItemEvent event listener mapping to the addItemToCartEventHandler
function. This function just appends the text “Yes! Someone has put…” to its red TextArea.
Now one more time: the green button component shoots the event to the outside world without
knowing anything about it. That is very different from the case when we would write “glue” code
like cart.addEventListener(“click”, applicationResponseMethodDoingSomethingInsideTheCart).
This class has to extend flash.events.Event; override its method clone to support event bubbling;
and call the constructor of the super-class, passing the type of the event as a parameter. The AS3
class below defines a itemDescription property that will store the application-specific data.
package cart {
import flash.events.Event;
itemDescription=description;
}
The new version of the shopping cart component is called ShoppingCart and its event handler
extracts the itemDescription from the received event and adds it to the text area.
<mx:Script>
<![CDATA[
private function init():void{
parent.addEventListener(ItemAddedEvent.ITEMADDEDEVENT,addItemToCartEventHandler);
}
There’s a design pattern called Inversion of Control or Dependency Injection, which means that an
object doesn’t ask other objects for required values, but assumes that someone will provide the re-
quired values from outside. This is also known as the Hollywood principle or ”Don’t call me, I’ll call
you.” Our ShoppingCart does exactly this – it waits until some unknown object triggers an event
it listens to that carries an item description. Our component knows what to do with it, i.e., display
in the red text area, validate it against the inventory, send it over to the shipping department, and
so on.
Next, we’ll completely rework our LargeGreenButton class into a NewItem component to include a
label and a text field to enter some item description and the same old green button:
<mx:Metadata>
[Event(name=”addItemEvent”, type=”flash.events.Event”)]
</mx:Metadata>
<mx:Label text=”Item name:”/>
<mx:TextInput id=”enteredItem” width=”300”/>
<mx:Button
width=”104” height=”28” cornerRadius=”10” fillColors=”[#00ff00, #00B000]”
label=”Add Item” fontSize=”12” click=”greenClickEventHandler()”/>
<mx:Script>
<![CDATA[
import cart.ItemAddedEvent;
private function greenClickEventHandler():void{
trace(“Ouch! I got clicked! Let me tell this to the world.”);
dispatchEvent(new ItemAddedEvent(enteredItem.text));
}
]]>
</mx:Script>
</mx:HBox>
When we look at our new application with its new ShoppingCart and NewItem components, it’s
almost indistinguishable from the original one. If we kept the old class names, we could have used
the old application.
When the user enters the item description and clicks the green one, the application creates a new
instance of the ItemAddedEvent, passing the entered item to its constructor, and the ShoppingCart
properly displays the selected ”New Item to Add” on the red carpet (see Figure 4.19).
Making components loosely bound simplifies development and distribution but comes at a higher
cost in testing and maintenance. Depending on the delivery timeline, size, and lifespan of your ap-
plication, you’d have to make a choice between loosely coupled or strongly typed components.
One last note. The itemDescription in Listing 4.45 doesn’t have an access-level qualifier. It’s so-
called package-level protection. The ShoppingCart can access itemDescription directly, but the
classes outside the “cart” package can’t.
Summary
This was a large chapter and it just covered the basic concepts of ActionScript programming. As you
start building your Flex application, the coding described will become routine. Making a choice of
which approach to take will not. We hope that such a high-level overview will help you to make an
informed choice about the path to take.
Endnotes
1. To be exact the appropriate Java classloader on each side should be able to find the class in the parental
chain of the classloaders.
2. The function object becomes a candidate for garbage collection.
In this chapter we will illustrate Flex controls, HTTPService, RemoteObject, and Consumer via
two versions of a stock portfolio application. The first version will show communications between
Flash and a plain old Java object (POJO) using Flex remoting. We’ll also explain how to use the
HTTPService to read the RSS news feed. In the other version we’ll add the stock (aka security) price
feed using Flex Messaging and the Java Messaging Service (JMS).
While explaining the FDS capabilities, we will also walk you through a typical design with Flex
containers.
We’ll populate the top portion of the screen with the stocks included in the user’s portfolio. For
simplicity’s sake, we’ll store the user’s portfolio in the XML file as in Listing 5.1.
<portfolio>
<security>
<Symbol>MSFT</Symbol>
<Quantity>10000</Quantity>
<Price>33.38</Price>
<Value>1</Value>
</security>
<security>
<Symbol>IBM</Symbol>
<Quantity>3000</Quantity>
<Price>82.15</Price>
<Value>1</Value>
</security>
…
</portfolio>
When the user clicks on a row with a particular stock (i.e., ADBE as in Figure 5.1), it will populate
the lower data grid with the headlines related to the selected stock. The news should be coming
from http://finance.yahoo.com/rss/headline. The column Link will contain the URL of the news,
and when the user clicks on the link, a new browser window pops up displaying the selected news
article.
The top of the screen contains the toggle buttons Show Grid/Show Chart. When the Show Grid op-
tion is selected, the user will see the screen as in Figure 5.1, and when Show Chart is selected, the
top data grid will be replaced with the pie chart (see Figure 5.2), preserving the same functionality
(clicking on the pie slice repopulates the news headlines according to the selected security). The
market data is refreshed on the screen every second or so.
The first version of the application will query the server POJO that generates random numbers.
Later in this chapter, we’ll subscribe to JMS topic and consume a real-time data feed from an ex-
ternal Java application.
In this application we’ll use the basic MXML and ActionScript from the first chapters of this book.
We assume that the reader has a basic knowledge of Java syntax. We’ve included mini-references
on the Java Naming and Directory Interface and JMS. So let’s roll up our sleeves…
In case of a default namespace (xmlns=”*”), our PortfolioView1.mxml from Listing 5.3 will be co-
located in the same directory with the application file portfolio.mxml.
Let’s discuss the design of PortfolioView1. It contains DataGrid portfolioGrid in a Flex Panel with
the title “Portfolio.” XML from Listing 5.1 is loaded into the portfolioModel e4x object. The list of
securities from that file is fed into portfolioGrid via a binding expression {portfolioModel.security}.
This expression returns an XMLList of all nodes named “security” that are direct children of the
root node:
Even if we won’t add any more code, isn’t it impressive that it takes only a dozen lines of code to
read the XML file, parse it, and display it in a grid shown in Figure 5.3? But this application has a
static nature: it does not connect to any price quote feed. In other words you would always see
$33.38 as the price for Microsoft, and $82.15 for IBM.
In Listing 5.3, the curly braces surrounding the expression indicate that this expression is being
used as a source in data binding. It is crucial for Flex programming to fully understand the strengths
and weaknesses of binding. Binding is based on event listeners automatically generated by the
Flex compiler as a response to declarative binding annotations. To initiate binding generation, de-
velopers use a combination of curly braces, mx:Binding tags, and [Bindable] metadata directives.
(Refer to the Adobe Flex manual for more detail.) In Chapter 4, we’ve given you some examples of
data binding, and in this chapter we’ll keep emphasizing the convenience of binding for automatic
asynchronous code invocation.
Next, we need to periodically connect to the server for new prices and update the Price and Value
columns. So let’s use a special Flex component called RemoteObject:
The RemoteObject component allows calling methods of a specified remote POJO, which is config-
ured on the server as a destination Portfolio in a special XML file. We’d like to emphasize that Flex
transparently calls Java from ActionScript. The client needs to know the name of the destination
and the method to call, for example, getQuotes(). All the dirty work of data marshaling between
ActionScript and Java is done for you by the Flex framework. If, for example, a Java method returns
an object of the StockQuoteDTO.java type, Flex de-serializes the Java object and builds its Action-
Script peer on the client. However, for performance reasons, it is recommended that you create the
peer ActionScript class and register it with the framework. We’ll show the StockQuoteDTO.as later
in this chapter.
Please note that all RPC communications, including RemoteObject, are asynchronous. In other
words, we don’t exactly call a remote method, but rather send a message to the server, requesting
a call of the specific Java method. Not only is the client’s request(s) executed asynchronously, but
even sending to the server is done asynchronously. And if you need to do multiple RemoteObject
invocations in your script, Flex will batch them together and send in the end of the script execu-
tion.
The results of remote invocations are returned via events. RemoteObject provides the result event
for success or fault for failures. You should write the corresponding handler functions. Flex will call
these methods, supplying an Event object as a parameter. It’s your responsibility to get the infor-
mation from the event and act accordingly. Friendly advice: you will save yourself hours of time if
you supply a fault handler.
In the next code snippet we set concurrency to last, because if Flex decides to batch the outgoing
requests, we do not want to send out more then one request in a batch; if a user clicks on the screen
sending more than one request in quick succession, the last request will suppress all previous ones.
Similarly, when the results are coming back we are interested only in the one we sent last:
The tag <mx:RemoteObject> allows using result and fault handling on both the object and method
levels. The method settings will take precedence over the RemoteObject’s ones.
For server-side support, you have to download and install Flex Data Services 2 Express Edition
(http://www.adobe.com/products/flex/), and deploy it as a Web application in the J2EE server of
your choice, for example, in Tomcat. FDS comes with a set of XML files, which you will use to con-
figure your server-side objects.
To register a POJO class with a Flex client we need to update the configuration file on the server
side. This lets you hide details of the service provider (i.e., actual Java class names) by specifying so-
called destinations where you specify access constraints, etc. The following section has to be added
to the remoting-config.xml file.
<destination id=”Portfolio”>
<properties>
<source>com.theriabook.ro.Portfolio</source>
</properties>
</destination>
Clients won’t know that the actual name of our POJO is com.theriabook.ro.Portfolio, but they’ll be
able to refer to it by the nickname Portfolio. Flex looks for classes specified in destination mappings
on the Web Application classpath including jars inside WEB-INF/lib and classes under WEB-INF/
classes. The Java class Portfolio.java (see Listing 5.6) is a simple random number generator simulat-
ing market-like real-time price changes for several hard-coded securities.
package com.theriabook.ro;
import java.util.Random;
import com.theriabook.jms.dto.StockQuoteDTO;
The StockQuoteDTO.Java (see Listing 5.7) contains the last price of a particular stock.
package com.theriabook.jms.dto;
import java.io.Serializable;
public class StockQuoteDTO implements Serializable {
private static final long serialVersionUID = 4672447577075475117L;
public String symbol;
public double last;
public StockQuoteDTO(String sym, double newPrice){
symbol = sym;
last = newPrice;
}
}
However, the client can really benefit from knowledge of the structure and the datatypes of the
returned DTOs. Listing 5.8 shows the ActionScript’s counterpart for the StockQuoteDTO.java ob-
ject. While Flex does not need this definition in order to deserialize the Java object that includes
member variables of standard types (by default it creates a dynamic object and adds the required
properties of the Java object that’s being deserialized), it does help performance (since the deseri-
alized object is immediately allocated in memory), ensures the output datatypes and enforces the
type conversion. The [RemoteClass…] metadata tag above the class definition tells the Flex de-se-
rialization method to use this particular class for de-serialization whenever the server sends com.
theriabook.jms.dto.StockQuoteDTO object down.
package com.theriabook.jms.dto {
[RemoteClass(alias=”com.theriabook.jms.dto.StockQuoteDTO”)]
public dynamic class StockQuoteDTO
{
public var symbol:String;
public var last:Number;
}
When the client successfully gets the quotes, it processes them and asks for new ones:
The E4X provides a very elegant solution for navigating an XML object here. The applyQuotes func-
tion iterates though the quotes from our portfolio and gets the XMLList based on the matching
Symbol attribute via evaluation of the portfolioModel.security expression. (Symbol==quote.symbol.)
This looks similar to XPath, but it’s easier, isn’t it? Since there’s a chance that the E4X expression
above will return an empty XMLList, it’s better to check for zero-length to avoid exceptions. We are
modifying the same XMLList that has been set as the data provider of our grid. In fact, for data grids
Flex maintains an internal XMLListCollection with this XMLList as a source. When the program
changes the data in the XMLList, these changes are automatically reflected on the screen.
Error reporting is often done by calling Alert(), which brings up a pop-up window. But we suggest a
less obtrusive way, whereby as an error condition disappears, the normal display restores without
user interaction. Let’s put a simple red Label control right above the data grid. Later in this chapter
we’ll embed it in the Panel’s title. An error, if any, will be displayed in this Label control, and to make
it a bit fancier, the detailed error description will be displayed as a tooltip whenever the user moves
the mouse over this field:
To implement this functionality, in the scripting section we will create two bindable variables:
[Bindable]
private var errorText:String;
[Bindable]
private var errorTip:String;
When an error occurs, the onFault function sets the values of the variables errorText and errorTip,
and their bindable nature will immediately display these values in the <mx:Label>. But most im-
portantly, we will attempt to recover by pulling the new quotes set.
Do not forget to clean the errorText and errorTip variables in the function onResult, if the next at-
tempt to pull the quotes will be successful.
Let’s spend some time discussing the process of initiating the quote request. The function pullQuotes()
gets initially invoked upon creation of the Panel:
To generate a remote call of some anonymous function every second, we’ll use the setTimeout
mechanism. The anonymous function initiates the call of the Java object proxied by the remoting
destination freshQuotes:
Listing 5.11 has the complete code of the first version of PortfolioView1.mxml, which contains just
a data grid.
width=”100%” height=”100%”
creationComplete=”pullQuotes();”
>
<mx:XML format=”e4x” id=”portfolioModel” source=”portfolio.xml” />
<mx:Label color=”red” toolTip=”{errorTip}” text=”{errorText}” width=”100%”/>
<mx:DataGrid id=”portfolioGrid” width=”100%” dataProvider=”{portfolioModel.security}”
>
<mx:columns><mx:Array>
<mx:DataGridColumn dataField=”Symbol”/>
<mx:DataGridColumn dataField=”Quantity” textAlign=”right”/>
<mx:DataGridColumn dataField=”Price” textAlign=”right”/>
<mx:DataGridColumn dataField=”Value” textAlign=”right”/>
</mx:Array></mx:columns>
</mx:DataGrid>
<mx:RemoteObject id=”freshQuotes” destination=”portfolio”
fault=”onFault(event);” >
<mx:method name=”getQuotes” concurrency=”last”
result=”onResult(event);”
/>
</mx:RemoteObject>
<mx:Script><![CDATA[
import mx.rpc.events.*;
import com.theriabook.jms.dto.StockQuoteDTO;
[Bindable]
private var errorText:String;
[Bindable]
private var errorTip:String;
pullQuotes();
}
Let’s create a simple application that adds the pie chart below the data grid and gives the grid and
the chart 50% of the screen height each:
Flex Panel containers have a layout property (horizontal, vertical, and absolute). Since the vertical
layout is the default, our chart is positioned right under the grid. Please note that chart’s dataProvid-
er is based on the same XMLList portfolioModel.security as is the dataProvider of the portfolioGrid.
In other words, we have two views of the same data model. The data binding feature results in im-
mediate updates of both controls on each change of the model. Java Swing developers will appreci-
ate the benefits of this feature as opposed to the JavaBean and property listeners hassle.
[Bindable]
private var errorText:String;
[Bindable]
private var errorTip:String;
errorTip = “”;
var quotes:Array = event.result as Array;
applyQuotes(quotes);
// Pull new quotes set
pullQuotes();
}
]]></mx:Script>
</mx:Panel>
For the pie chart, we’ve selected a callout type of label positioning, specified so the size of the pie
is proportional to the attribute Value, and we’ve added a 3D depth to the chart by setting explode
Radius to 0.02. Note how we’ve assigned the function name showPosition to the labelFunction at-
tribute of the pie chart. The signature of the labelFunction assumes that the first argument brings
the element of the dataProvider corresponding to the current wedge in the series.
Chart/DataGrid Toggling
Imagine a deck of playing cards: only the top card is visible. Hide the top card and you’ll see the next
one. We’ll use the deck of two “cards”: one card will display the grid, and another one – the chart. To Java
Swing developers this should look like the CardLayout. In Flex jargon it’s called <mx:ViewStack>. The
screen snapshot in Figure 5.6 was made when the portfolioPie was on the top of the portfolioGrid:
</mx:Canvas>
<mx:Canvas label=”Show Chart” icon=”{iconChart}” >
<mx:PieChart id=”portfolioPie” … height=”100%”/>
</mx:Canvas>
</mx:ViewStack>
<mx:ToggleButtonBar dataProvider=”{vs}” horizontalGap=”5” />
<mx:RemoteObject id=”freshQuotes” …/>
<mx:Script><![CDATA[
…
[Embed(source=”images/icon_chart.png”)]
[Bindable]
public var iconChart : Class;
[Embed(source=”images/icon_grid.png”)]
[Bindable]
public var iconGrid : Class;
]]></mx:Script>
</mx:Panel>
The most suitable Flex containers for toggling the views are ViewStack or its direct descendant
TabNavigator. The latter uses more screen real estate to paint the tabs. So we’d rather put the view
toggling controls on the unused area of the Panel’s title bar. The ViewStack component provides
programmatic indexed access to the child containers and shows them one at a time.
The simplest Flex container is called Canvas, so we wrap up the DataGrid and the PieChart sepa-
rately inside it. A Canvas is a descendant of the Container ActionScript class and has the properties
label and icon. There are two “non-programmatic” ways to use these properties. First, certain con-
tainers use them implicitly, for instance, TabNavigator automatically arranges its tabs to display
labels and show icons from the nested child containers. The second way is to explicitly use the
ViewStack as a data provider for the descendants of the NavBar control such as ButtonBar, LinkBar,
and, in our case, ToggleButtonBar. When you use a ViewStack as a data provider, the label and icon
properties of the ViewStack container’s children are used to populate the navigation items. The
ViewStack feeds ToggleButtonbar and ToggleButtonbar controls the ViewStack in return.
[Bindable]
private var errorText:String;
[Bindable]
private var errorTip:String;
applyQuotes(quotes);
// Pull new quotes set
pullQuotes();
}
[Embed(source=”images/icon_chart.png”)]
[Bindable]
public var iconChart : Class;
[Embed(source=”images/icon_grid.png”)]
[Bindable]
public var iconGrid : Class;
]]></mx:Script>
</mx:Panel>
Listing 5.15 PortfolioView3.mxml
The toggle buttons Show Grid/Show Chart use images, and it’s a good idea to embed these resourc-
es right into the SWF file. This way the browser can download the entire client in one HTTP request
(but the size of the SWF file becomes larger). For the same reason, the multi-file Java applets are
packaged into a single jar.
In the previous code sample, we use canvases to wrap, but now we’re going wrap up the entire Port-
folio Panel. Yes, the Panel will become a child of the Canvas. Here is why we need it. The Canvas is
the simplest container, and it’s also the absolute positioning container. In other words, if you place
A and B as children of the Canvas, they overlap unless each of them has specific x and y coordinate
settings. So we’re planning on overlapping the ToggleButtonBar and the PortfolioPanel in a single
Canvas. As an additional measure, to make the ToggleButtonBar appear on the far right, we put
the ToggleButtonBar inside the HBox container. Make sure that the RemoteObject and the XML
are moved out to become children of the Canvas; they have to be at the outermost level – this is an
MXML requirement.
</mx:RemoteObject>
<mx:XML format=”e4x” id=”portfolioModel” source=”portfolio.xml” />
<mx:Script><![CDATA[
import mx.rpc.events.*;
import com.theriabook.jms.dto.StockQuoteDTO;
[Bindable]
private var errorText:String;
[Bindable]
private var errorTip:String;
applyQuotes(quotes);
// Pull new quotes set
pullQuotes();
}
[Embed(source=”images/icon_chart.png”)]
[Bindable]
public var iconChart : Class;
[Embed(source=”images/icon_grid.png”)]
[Bindable]
public var iconGrid : Class;
]]></mx:Script>
</mx:Panel>
<mx:HBox horizontalAlign=”right” width=”100%” paddingRight=”5” paddingTop=”5”>
In particular, we’ll be using the RSS news generator offered by Yahoo! Finance. Just enter the follow-
ing URL in your browser: http://biz.yahoo.com/rss.html.
You should see a screen similar to the one depicted in Figure 5.9. This Web site lets you enter a stock
symbol, for example, ADBE.
You’ll see a little orange XML button, with a new URL that looks like http://finance.yahoo.com/rss/
headline?s=adbe. Just follow this link, which will bring you to the RSS XML feed withthe latest news
about the symbol ADBE, as in Figure 5.10.
By the end of this chapter we’ll be done with programming master-detail relationships; our users
will click on the row in the portfolio grid (Figure 5.7) and see the news as in Figure 5.9, then click on
one of the lines in the column Link, which opens a new Web browser’s window with the full news
content. Let’s implement this chain of actions one step at a time.
Our new MXML application will contain the following HTTPService element:
Your client application will be loaded from some server, which is expected to have a configured
news destination named YahooFinancialNews, or whatever name you prefer.
<destination id=”YahooFinancialNews”>
<properties>
<url>http://finance.yahoo.com/rss/headline</url>
</properties>
</destination>
Now Flex will contact http://finance.yahoo.com, get the news for the symbol specified, and return
it back to the Flash client.
If we knew that the results were coming back as name/value pairs concatenated with an amper-
sand, we could have picked the flashvars format. The text format is suitable for any raw text, but
it’s not easy to parse. The XML format is maintained for compatibility with pre-E4X versions of
the ActionScript, so we’ll pass on this one as well. Considering the other formats listed above, for
our application, we prefer e4X XML. An e4X expression newsFeed.lastResult.channel.item is all you
need to populate the XMLListCollection with news headlines. This XMLListCollection will be used
as the dataProvider of the news DataGrid.
As usual, we’ll separate the code that merely starts the application from the FinancialNews view in
Listing 5.18:
Our newsFeed will initiate the following request from the creationComplete event:
newsFeed.send({s:”ADBE”});
As part of the send method, Flex converts the object’s property into a GET URL parameter using
the object’s properties as parameter names. Here s:”ADBE” will be concatenated in the form of
“?s=ADBE” to the http://finance.yahoo.com/rss/headline specified by the news destination. Since
RSS data can be verbose, we’ll set the relevant columns of the grid with wordWrap=”true” and the
height of the Grid row to be flexible: variableRowHeight=”true”.
<mx:Script>
<![CDATA[
private function onCreationComplete():void {
newsFeed.send({s:”ADBE”});
}
import mx.rpc.events.*;
private function onFault(event:FaultEvent):void {
mx.controls.Alert.show(
“Destination:” + event.currentTarget.destination + “\n” +
“Fault code:” + event.fault.faultCode + “\n” +
“Detail:” + event.fault.faultDetail, “News feed failure”
);
}
]]>
</mx:Script>
</mx:Panel>
drop-in, which is an ActionScript class that you specify as the value of the itemRenderer of any
list-derived control.
inline, where you use an <mx:Component> tag to define a renderer component inside the
<mx:itemRenderer> element.
The ActionScript function flash.net.navigateToURL opens or replaces a window in the Flash Play-
er’s container application – opens it, in our case, in a blank browser.
While inline renderers excel in readability, drop-in renderers are reusable. If you expect to have
links with similar presentation and functionality you may decide to create a class out of it.
Let us introduce the write-only security property for the FinancialView2 class. Please note that we pro-
vide a setter method to send a newsFeed request every time the security (stock symbol) is updated:
A bit later in this chapter, the value of the selected security will be passed to the news data grid
based on the selected row in the portfolio data grid (see Figure 5.1) or the selected slice of the pie
(see Figure 5.2). At this point let’s remove the creationComplete event handler in FinancialNews
and hard-code the stock symbol ADBE as a valve of security for the FinancialNews2 tag:
<mx:Script>
<![CDATA[
import mx.rpc.events.*;
public function set security(value:String):void {
this.title = “News: “ + value;
newsFeed.send({s:value});
}
Another minor modification in Listing 5.20 is that the XML received with Yahoo! Financial news is
now a source property of the <mx:XMLListCollection>. The data grid’s dataProvider is populated
from this collection. You don’t have to use a collection as the middleman between the data and the
GUI component, but it does become handy for customization. In particular you can apply a sort or
set a filter on the collection.
from Listing 5.19 into a security bound to portfolioView.selectedSecurity. So in the scripting section
of PorfolioView5.mxml we’ll declare a bindable variable selectedSecurity:
[Bindable]
public var selectedSecurity:String;
The metatag [Bindable] provides an elegant two-line solution for our master-detail parameter
passing. The tag PortfolioView5 will go by the ID pv, hence a simple {pv.selectedSecurity} repre-
sents the value of this bindable property:
To be precise, the curly braces denote binding between the FinancialNews2.security, the target of
the binding, and the Portfolio5.selectedSecurity as the binding source.
Here is the short explanation of how it works. When Flex compiles PortfolioView5.mxml with the
bindable selectedSecurity (see Listing 5.22), it will produce code that dispatches an event on every
change of that property. Then, while compiling our application, Flex will notice that Financial-
News2.security depends on the binding expression. But the expression, in turn, depends on the val-
ue of PortfolioView5.selectedSecurity, doesn’t it? Accordingly, Flex will add a listener to the change
event associated with pv.selectedSecurity. The task of this listener will be to keep the expression
recalculated at every change of PortfolioView5.selectedSecurity. Following the same logic, Flex will
keep FinancialNews2.security recalculated on every change of the expression. You can read more
about binding in the Flex documentation.
Our application keeps the Portfolio on top of the financial news in a vertical box. To facilitate resiz-
ing between the two parts, we’ve used the VDividedBox container instead of the VBox because it
has a divider between the parts (similar to Java Swing split panes).
Each click on a wedge of the pieChart will generate an itemClick event (the sole parameter of this
event will be of type CharItemEvent) that will include the attribute event.hitData.item correspond-
ing to the selected item (an XML object) in the underlying data provider. That’s why, to populate the
variable selectedSecurity we can write:
In the case of the DataGrid, we’ll be intercepting the change event, which is dispatched when
the selectedIndex or selectedItem property changes as a result of the user’s actions. Note the
selectable=”true” Listng 5.22. This is done to enable highlighting of the selected row.
The following fragment from PortfolioView5.mxml shows the changes/additions that we’ve made
to PortfolioView4. A complete listing is included with the source code in the book samples.
[Bindable]
public var selectedSecurity:String;
import mx.charts.events.*;
private function portfolioPieOnClick(event:ChartItemEvent):void {
selectedSecurity=event.hitData.item.Symbol;
}
…
]]></mx:Script>
…
</mx:Canvas>
Finally, to add a visual effect of the selected security in the pie we will explode the clicked wedge a
bit more (see Figure 5.11):
This concludes our series of Stock Portfolio applications based on Flex remoting.
JNDI has one or more contexts, which comprise a naming tree similar to directories/sub-directo-
ries in a PC file system. The “root directory” in JNDI vocabulary is called the initial context. The
Tomcat server that we will use in our illustration supports it own JNDI tree. So does the ActiveMQ
implementation of the JMS that we will use to complement Tomcat. (When this was written Ac-
tiveMQ was available under the Apache 2.0 license at http://www.activemq.org/.)
Let’s consider an example that shows how to obtain and use the appropriate naming context.
A client program JndiExample (Listing 5.10) creates an instance of the InitialContext class passing
it hard-coded properties relevant to the specific JNDI provider. In particular, the settings of tcp://
localhost:61616 as the value of PROVIDER_URL and ActiveMQInitialContextFactory as the value of
the INITIAL_CONTEXT_FACTORY are unique to ActiveMQ. (There is an alternative technique for
keeping these settings in the jndi.properties on the execution classpath, but it is entirely up to the
JNDI provider to make use of this file.):
// Now you can lookup for JMS objects, i.e. topic connection factory
// TopicConnectionFactory factory = (TopicConnectionFactory)
// ctx.lookup(“jms/flex/TopicConnectionFactory”);
} catch(Excaption e){…}
}
}
In this program we assume that the ActiveMQ creates the JNDI tree and binds TopicConnectionFac-
tory some time prior to the name lookup. Your program also can programmatically bind the object
to the JNDI tree, provided you have enough access privileges to run the following line of code:
ctx.bind(someName, someObject);
This concludes our short introduction to JNDI, but you can find a more detailed JNDI tutorial at
http://java.sun.com/products/jndi/tutorial.
JMS is the standard API to work with MOM. JMS does not transport messages. JMS-to-MOM is
the same as JDBC-to-a-database management system. Java applications could use the same JMS
classes with any MOM vendor.
In this chapter we’ll use the Pub/Sub mode for publishing the stock quotes. Do we need to persist
our messages so the subscribers who are not online at the moment can eventually get them? Ap-
parently not, since it does not make sense to store the price of MSFT as of 11:53:59a.m. and show
it an hour later when the subscriber decides to go online. So our subscribers (and topics) will be
non-durable. Do we need to guarantee the successful delivery of each and every quote, given their
frequency? Again, the answer is, most likely, no. So our publishing will not be transacted.
Types of Messages
Every message created by the JMS provider contains a header, a body (aka payload), and properties.
The header contains standard message identification such as message ID, destination, etc. Proper-
ties and body are optional.
In a typical scenario, properties – name/value pairs – can be used as a “mark” to filter messages by business
purpose. Accordingly, body is best suited to deliver the content. JMS offers the following message types:
• TextMessage: This could be any Java String (any text, CVS, XML, etc.)
• ObjectMessage: This could be any serializable Java object
• BytesMessage: An array of bytes
• StreamMessage: A stream of Java primitives for sequential reading
• MapMessage: Any key/value pair, for example, id=123
• Message: A message that contains the header and maybe properties, but no body
When you’re configuring Flex messaging destinations specific to JMS, keep in mind that at the time
of writting, Flex only supported TextMessage and ObjectMessage types.
The snippet of code in Listing 5.25 illustrates the steps that will be included in our TickerFeed Java
program: look up the topic factory, create the topic connection, session, and publisher and, finally,
publish a serialized object:
Subscribers can be durable and non-durable. A durable topic subscriber gets all of the messages
sent to a destination, including those sent while the consumer is inactive. A non-durable message
consumer gets messages from its chosen destination only if the messages are available while the
consumer is active. This mode is similar to the way the chat rooms operate – you must be online
to get the messages. Please be aware that you cannot possibly create a durable subscriber on the
non-durable transport. In the case of Flex, you’d have to declare your messaging destination (more
on that later in this chapter) as durable.
Now that we’ve touched on the subject of JMS, let’s look at the integration of JMS and native Flex
messaging.
An important point here is that Flex and Java have separate message destinations. The mapping
between the Flex destinations and external messaging destinations has to be configured in the
XML configuration file (under the default configuration scenario – WEB-INF/flex/messaging-config.
xml). Figure 5.12 shows an integration between Flex and Java Messaging using a JMS adapter.
Flex clients can connect to servers using different transport protocols: the Real-Time Messaging
Protocol (RTMP) and the Action Message Format (AMF) that runs over HTTP (you’d need polling
in the latter case). When you configure a destination in the messaging-config.xml, you can specify
more than one channel and Flex will try to access the destination using the protocols in the order
specified. We’d like to emphasize that Flex clients just need to know the names of the FDS destina-
tions. They are decoupled from MOM servers and JMS names. All features of the Flex messaging
are described in the Flex manual called the Flex Developer’s Guide. Now we’ll get back to our stock
portfolio application, but this time we’ll make it JMS-enabled.
/WEB-INF/flex, and create the destination for the “ticker-topic-jms” as in Listing 5.27. Please note
the difference between the destination ID “ticker-topic-jms,” which will be used by the Flex client,
and the jndi-name “ticker,” which the Flex JMS adapter will use for look up in the JNDI tree. The
middleman subscriber created by the Flex JMS adapter won’t be durable; it’s okay to lose the quote
if you aren’t online.
<adapters>
<adapter-definition id=”actionscript” class=”flex.messaging.services.messaging.adapters.
ActionScriptAdapter” default=”true” />
<adapter-definition id=”jms”
class=”flex.messaging.services.messaging.adapters.JMSAdapter”/>
</adapters>
<destination id=”ticker-topic-jms”>
<properties>
<server>
<durable>false</durable>
<durable-store-manager>flex.messaging.durability.FileStoreManager</durable-store-
manager>
</server>
<jms>
<destination-type>Topic</destination-type>
<message-type>javax.jms.ObjectMessage</message-type>
<connection-factory>topicConnectionFactory</connection-factory>
<destination-jndi-name>ticker</destination-jndi-name>
<destination-name>Ticker</destination-name>
<durable-consumers>false</durable-consumers>
<delivery-mode>NON_PERSISTENT</delivery-mode>
<message-priority>DEFAULT_PRIORITY</message-priority>
<acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode>
<transacted-sessions>false</transacted-sessions>
<initial-context-environment>
<property>
<name>java.naming.factory.initial</name>
<value>org.apache.activemq.jndi.ActiveMQInitialContextFactory</
value>
</property>
<property>
<name>java.naming.provider.url</name>
<value>tcp://localhost:61616</value>
</property>
</initial-context-environment>
</jms>
</properties>
<channels>
<channel ref=”my-rtmp”/>
<channel ref=”my-polling-amf”/>
</channels>
<adapter ref=”jms”/>
</destination>
</service>
Note the channel tags. The RTMP channel is listed first, and the AMF polling is the second option.
This means the following: try the push first, but if it doesn’t work (because of firewalls), start polling.
Naturally, we have to guarantee the availability of the ActiveMQ classes on the Web application
class path. To that end we dropped activemq-4.0-M4.jar into the common/lib folder off the Tomcat
root. Here is the full listing of the application listener:
package com.theriabook.jms;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import org.apache.activemq.broker.BrokerService;
To register the listener with the Web application we modify the web.xml file and add the following
XML snippet (according to the DTD it should go right after the filter mappings. If your app does not
have a filter, the placement is right after the application context parameters):
<listener>
<listener-class>com.theriabook.jms.ActiveMQBrokerListener</listener-class>
</listener>
package com.theriabook.jms;
import java.io.Serializable;
import com.theriabook.jms.dto.StockQuoteDTO;
To avoid hard-coding the JNDI properties in the TickerFeed program, we will make sure that the file
jndi.properties as shown in Listing 5.30 belongs to the application classpath:
# use the following property to specify the JNDI name the connection factory
connectionFactoryNames = connectionFactory, queueConnectionFactory, topicConnectionFac-
tory
Now we’re ready to complete our TickerFeed.java program. It continuously publishes the Quotes-
Holder objects to the JMS topic called “ticker.” On your console you should see output similar to
this one:
Publishing quotes...
Publishing quotes...
// TickerFeed.java
package com.theriabook.jms;
import com.theriabook.ro.Portfolio;
import java.util.*;
import javax.jms.*;
import javax.naming.*;
import com.theriabook.jms.dto.StockQuoteDTO;
TopicSession pubSession;
TopicPublisher publisher;
TopicConnection connection;
try {
// Obtain JNDI Context
Context context = new InitialContext();
First, we will replace the <mx:RemoteObject> tag with the following <mx:Consumer> tag:
This is an example of decoupling the application components. If you need to change the MOM
provider, or you decide to use message queues instead of topics, no code modification is needed.
Just change the destination parameter and you’re set.
The second change is to actually start consuming messages. The modified startQuotes will look as
follows:
The third and last change is in the processFault method, due to the differences in mx.messaging.
events.ChannelFaultEvent instead of mx.rpc.events.FaultEvent:
startQuotes();
}
In all other respects the JMS code specific to the PortfolioView is the same as in its remoting coun-
terpart:
<mx:Script><![CDATA[
import mx.controls.Alert;
[Bindable] public var selectedSecurity:String;
private function showPosition(data:Object, field:String, index:Number, percentVal
ue:Number):String {
return data.Symbol + “\n” + “Shares:” + data.Quantity + “\n” + “Price:” +
data.Price + “\n” + “Value:” + data.Value ;
}
[Embed(source=”./images/icon_chart.png”)] [Bindable] public var iconChart :
Class;
[Embed(source=”./images/icon_grid.png”)] [Bindable] public var iconGrid :
Class;
import com.theriabook.jms.dto.StockQuoteDTO;
internal var row:XML;
[Bindable]
private var errorText:String=””;
[Bindable]
private var errorTip:String=””;
import mx.messaging.events.ChannelFaultEvent;
private function processFault(evt:ChannelFaultEvent):void{
errorText = “Server Error”;
errorTip = evt.faultDetail;
startQuotes();
}
private function applyQuotes(quotes: Array):void {
errorText = “”;
errorTip = “”;
for (var i:int=0; i<quotes.length; i++) {
var quote:StockQuoteDTO = StockQuoteDTO(quotes[i]);
var list: XMLList = portfolioModel.security.(Symbol==quote.symbol);
if (list.length()!=0) {
var row:XML = XML(list);
row.Price = Math.round(100*quote.last)/100;
row.Value = Math.round(row.Price * row.Quantity);
}
}
}
Summary
In this chapter we went through different ways of establishing RPC communications between Flex
and Java. In particular, we’ve been using RemoteObject, HTTPService, and Flex JMS adapters to
establish communications.
The simplest way to explain Data Management Services (DS) is to compare them with Remoting.
Whereas Flex Remoting enables one-way requests, FDS combines one-way requests with the pub-
lish/subscribe mechanism so that besides the original result set DS sends the client live updates
produced by other clients of the same destination. And there’s one more dimension in which Data
Services depart from Flex Remoting – support for hierarchical collections, but we won’t be covering
that subject in this book.
In other words, DS resolves the task of programming data collaboration: Several users may edit different
rows and columns of the “same” DataGrid and see each other’s changes automatically pushed by the
server. Now, what if they overlap each other’s work? In terms of DS that’s called a conflict and the DS API
provides for flexible conflict resolution, which may require the user’s intervention.
A DS destination can be configured for working with the data that is persisted to a data store as
well as supporting scenarios that persist the data in the server’s memory. To that end, FDS provides
Java and ActionScript data adapters that are responsible for reading and updating a persistent data
store according to its type. In this chapter we’ll focus on use cases involving Java adapters.
• A Java Data Access Object class that implements retrieve, update, delete, and insert of the data
• Java Data Transfer Objects (DTO)
We just mentioned four classes/files containing hard-coded names of the fields and there are more.
To function properly, these hard-coded values have to be kept in sync, which is an additional main-
tenance effort whenever the data structures change.
Instead of this complexity, the main idea of this chapter is not to cover every twist of the DS API,
but rather automate the development effort that DS takes for granted. We’ll start with a “manual,”
albeit simplified, example of using DataServices. Then we’ll introduce you to the methodology of
complete code generation based on the pre-written XSL templates and DS-friendly XML metadata,
which will be extracted from the annotated Java abstract classes.
This methodology is fully implemented in DAOFlex – an open source utility that’s a complemen-
tary addition to this book. We’ll gradually introduce this tool by leading you through a process of
creating the most comprehensive template that generates a complete DataServices Data Access
Object (DAO). Finally, we’ll show you how to run and customize DAOFlex in your development
environment so that writing and synchronizing routine DataServices support classes becomes a
task of the Ant building tool and not yours!
There are two buttons below the DataGrid: Fill and Commit. As the names imply, these buttons pull
the original data from the database table and submit the data changes back to an DS destination.
A separate Parameters panel permits entering parameters of the back-end method behind the Fill
button, which, in our case, is the employee start date :
We provide only a rudimentary handler of the fault event, that’s sufficient to keep us aware of any
anomalies that may occur along the way. Dynamic referencing of fault and faultString properties
will spare us from casting to a specific event:
By setting autoCommit to false we state that all updates have to be batched and explicitly submit-
ted to the server as a single transaction during the ds.commit() call. By setting autoSyncEnabled
to false we effectively protect our local instance of data from the delivery of messages caused by
other clients connected to destination “Employee.” Setting autoSyncEnabled to false is entirely op-
tional, and we use it to avoid dealing with application specific conflict resolution. In particular, in
the handler of the Commit button’s click event you might uncomment the first line to support the
“optimistic” way of handling the conflicts:
Last, we have to initiate the population of the local collection with the ds.fill() method, which we do
inside the click event handler of the button Fill:
The scripting portion of the application is completed so let’s build the UI. We create a DataGrid
with the dataProvider bound to our collection in Listing 6.1. For brevity’s sake, we didn’t list all the
columns here: you’ll have a chance to scrutinize them in the subsequent section of this chapter.
The DataGrid and ControlBar with Fill and Commit buttons are put inside a Panel, with DataGrid’s
title bearing the name of the destination and a specific getEmployees method of that destination,
which will ultimately be invoked during the ds.fill() call. The second panel, titled Parameters, con-
tains a form with a single item mx:DateField. Both panels are embraced by the VDividedBox.
We’ve included a linkage variable of the data transfer type to ensure that the corresponding Action-
Script class (EmployeeDTO) will be linked into the generated SWF file.
ds.conflicts.acceptAllClient();
ds.commit();
}
private function onFault(evt:Event):void {
Alert.show(evt[“fault”][“faultString”], “Fault”);
}
]]>
</mx:Script>
</mx:Application>
The application above doesn’t cover all use cases of the DS API. We tried to keep it as small as pos-
sible for one reason: to enable metadata-based code generation. Ultimately, it will be entirely up to
you which code you’d elect to generate by modifying the DAOFlex templates.
Finally, we present the listing of the ActionScript class EmployeeDTO that our collection uses in
communicating with the Employee destination:
package com.theriabook.datasource.dto
{
[Managed]
[RemoteClass(alias=”com.theriabook.datasource.dto.EmployeeDTO”)]
public dynamic class EmployeeDTO
{
// Properties
public var EMP_ID : Number;
public var MANAGER_ID : Number;
public var EMP_FNAME : String;
public var EMP_LNAME : String;
public var DEPT_ID : Number;
public var STREET : String;
public var CITY : String;
public var STATE : String;
public var ZIP_CODE : String;
public var PHONE : String;
public var STATUS : String;
public var SS_NUMBER : String;
public var SALARY : Number;
public var START_DATE : Date;
public var TERMINATION_DATE : Date;
Our first stop is an Assembler class that the DS Employee destination should map to. As the Flex
documentation suggests, you can implement the methods on your Assembler class in several
ways:
We’ll take an XML approach that lets us declare a so-called sync-method. The XML contract of the des-
tination’s sync-method prescribes that it accepts a single parameter: a List of flex.data.ChangeObject
elements. We find it convenient to control how we want to process data changes. In particular, we’d
like to maintain the following order: all deletes, then all updates, and then all inserts. After all, if
the user deletes a record for an employee with EMP_ID= 123 and then inserts a new record with
EMP_ID=123, we certainly wouldn’t want our sync-method to issue the INSERT, followed by DELETE
FROM employee WHERE EMP_ID=123 during the batched DS data modifications.
Let’s keep in mind that our ultimate focus is the metadata-based code generation. Should you de-
cide to have your Assemblers as descendants of the AbstractAssembler, you’d have the liberty of
modifying the corresponding DAOFlex template.
Listing 6.3 presents the complete XML describing the destination Employee. Under the default
configuration scenario, this XML would go inside the <services> node of the flex-data-services.xml
file, located in the WEB-INF/lib/flex folder of your Web application.
You’d be able to configure more than one fill-method, although all of them should operate with the
same type of DTO. In the <metadata> node we specified that the EMP_ID property of the DTO has
to be considered as a single key, or identity property of the elements distributed by the destination.
You could use a generated Universal Unique Identifier (UUID) instead of the real data-store field
in place of the identity, which is arguably more flexible, because DS didn’t support updates to the
identity fields when this piece was written.
Even though XML doesn’t explicitly declare that the fill-method returns a List or that the
sync-method takes a List, this is a part of the XML contract for Assembler classes in destina-
tions:
<destination id=”Employee”>
<adapter ref=”java-dao”/>
<properties>
<source>com.theriabook.datasource.EmployeeAssembler</source>
<scope>application</scope>
<metadata>
<identity property=”EMP_ID”/>
</metadata>
<network>
<session-timeout>0</session-timeout>
<paging enabled=”false”/>
<throttle-inbound policy=”ERROR” max-frequency=”500”/>
<throttle-outbound policy=”ERROR” max-frequency=”500”/>
</network>
<server>
<fill-method>
<name>getEmployees_fill</name>
<params>java.util.Date</params>
</fill-method>
<sync-method>
<name>getEmployees_sync</name>
</sync-method>
</server>
</properties>
</destination>
The structure of the EmployeeAssembler Java class is pretty straightforward. This class delegates
the actual data retrieval and update of the data store to the EmployeeDataServiceDAO class, which
we’ll discuss next:
package com.theriabook.datasource;
import java.util.*;
Finally, here’s the EmployeeDTO class that the EmployeeAssembler-based destination will be op-
erating with. It offers a simplistic approach to UUID generation that has to be replaced by a UUID
generator of your choice:
package com.theriabook.datasource.dto;
import java.io.Serializable;
public EmployeeDTO() {
_uid = getUUID();
}
The code for the fill portion of the EmployeeDataServiceDAO is presented in Listing 6.6. By wrap-
ping any Throwable into com.theriabook.DAOFlex.DAOException, a descendant of RuntimeExcep-
tion, we avoid unnecessary throws in both the DAO and Assembler implementation, since fatal
exceptions will bubble up to the Flex framework classes and show up on the client side as a Da-
taServices fault event. Other than that, most of this code is generic, which is precisely why it’s an
excellent candidate for template-based code-generation:
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te);
} finally {
try {rs.close(); rs = null;} catch (Exception e){//your error logging code goes
here}
try {stmt.close(); stmt = null;} catch (Exception e){ //your error logging code
goes here }
JDBCConnection.releaseConnection(conn);
}
}
Conveniently, the creators of DS enabled the ChangedObject to return an array of all property
names that underwent modification, which lets us build a SET clause by iterating over the array
returned by the co.getChangedPropertyNames():
Now let’s set the values for all the modified fields. Here we’ll take advantage of another function of the
ChangeObject – getChangedValues(). This method returns a map of the new values and based on this
map and the array names we can execute relevant setXXX() methods against our prepared statement:
To set the value of the WHERE clause-based parameter EMP_ID, we’ll use another ChangeObject’s
method – getPreviousVersion(), which returns a copy of the old DTO:
stmt.setObject(ii++, co.getPreviousValue(“EMP_ID”));
stmt.setObject(ii++, co.getPreviousValue(“EMP_ID”));
Please note how we rely on Double.isNaN() to distinguish nulls from non-nulls (the alternative
and, arguably, more reliable approach applicable to all nullable types would be to supply explicit
null indicators as part of the DTO from ActionScript to Java and vice versa):
if (Double.isNaN(item.SALARY))
stmt.setNull(13,Types.DOUBLE);
else
stmt.setDouble(13, item.SALARY);
stmt = conn.prepareStatement(sql);
stmt.setInt(1, item.EMP_ID);
. . . .
stmt.setString(12, item.SS_NUMBER);
if (Double.isNaN(item.SALARY))
stmt.setNull(13,Types.DOUBLE);
else
stmt.setDouble(13, item.SALARY);
stmt.setDate(14, DateTimeConversion.toSqlDate(item.START_DATE));
. . . .
if (stmt.executeUpdate()==0) throw new DAOException(“Failed inserting.”);
co.setNewVersion(item);
return co;
} finally {
try { if( stmt!=null) stmt.close(); stmt = null;} catch (Exception e){}
}
}
And this concludes the handcrafting of our DataServices-based example. Now that we’ve been
through the whole process, let’s see how it could have been avoided and automated.
Introducing Metadata
Let’s look at the snippet from the XML file generated by the DAOFlex utility – Employee.xml. Please
note the name of the Java package – com.theriabook.datasource, the name of the Assembler’s fill-
method – getEmployees(), names on the transferring structures on the Java and ActionsScript side,
both pointing to the array of com.theriabook.dto.EmployeeDTO objects, the name of the connec-
tion pool – jdbc/theriabook, and the name of the method’s parameter – startDate:
Starting at this point, we’ll be working our way through this XML while building the complete XSL
stylesheet from scratch. Once we make this stylesheet, it’ll manufacture any DataServiceEmploy-
eeDAO, DataServiceDepartmentDAO, etc. – as long as we have the metadata XMLs like the above
one. You’re probably wondering at this point: “What’s the input of the DAOFlex that lets it generate
this XML?”
The input for DAOFlex is an annotated Java class, like the one presented in Listing 6.11:
package com.theriabook.datasource;
import java.util.Date;
import java.util.List;
/**
* @DAOFlex:webservice pool=jdbc/theriabook
*/
Listing 6.11 Source of the DAOFlex code-generation process – An annotated Java class
Introducing Templates
Let’s put out our first iteration of the SimpleDataServiceDao.xsl stylesheet, which will eventually auto-
matically build DataServiceDao objects for us. We assume that the reader is familiar with XSL basics, but
if you haven’t had a chance to use XSL yet, here’s a good place to start: http://www.w3schools.com/xsl/.
We’ll be using XSL transformations to produce not an XML, but a plain text (Java code), so let’s start
our stylesheet as follows:
<?xml version=”1.0”?>
<xsl:stylesheet
version=”1.0”
xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”
>
<xsl:output omit-xml-declaration=”yes” method=”text”/>
….
</xsl:stylesheet>
For the topmost element in our metadata (WEBSERVICE) we’ll print out the value of the package,
required utility imports, declaration of the class, and its constructor (Listing 6.12):
<xsl:template match=”/WEBSERVICE”>
/* Generated by SimpleDataServiceDao.xsl */
package <xsl:value-of select=”@PACKAGE”/>;
import java.util.*;
import java.sql.*;
import flex.data.*;
import com.theriabook.DAOFlex.JDBCConnection;
import com.theriabook.DAOFlex.DAOException;
import com.theriabook.DAOFlex.DateTimeConversion;
</xsl:template>
/* Generated by SimpleDataServiceDao.xsl */
package com.theriabook.datasource;
import java.util.*;
import flex.data.*;
import java.sql.*;
import com.theriabook.DAOFlex.JDBCConnection;
import com.theriabook.DAOFlex.DAOException;
import com.theriabook.DAOFlex.DateTimeConversion;
} //EmployeeDataServiceDAO
The tag <xsl:apply-templates …/> from Listing 6.11 effectively delegates the processing of all nodes
that can be located relative to the WEBSERVICE via the XPath expression “SERVER[MODE=’JEE’]/
SQL” to a template that matches “SQL.” Before adding such a template, let’s look a bit deeper at the
Employee.xml metadata file.
Listing 6.14 A second look at the Employee.xml metadata with input parameters
}
return list;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te);
} finally
{
try {rs.close(); rs = null;} catch (Exception e){// log your errors here}
try {stmt.close(); stmt = null;} catch (Exception e){ // log your errors here }
JDBCConnection.releaseConnection(conn);
}
}
Listing 6.16 presents a template that generates the code above. Please note that this template in
turn delegates the processing of the input parameters to the named template declareFillParam-
eters as seen in Listing 6.17. The template is abbreviated and we’ll be looking at what’s hidden be-
hind the commented ellipses “//…” in the next section of the chapter:
<xsl:template match=”SQL”>
public final List /*<xsl:value-of select=”@JAVATYPE”/>*/ <xsl:value-of select=”@NAME”/
>(<xsl:call-template name=”declareFillParameters”/>
String sql = “<xsl:value-of select=”COMPILED/BODY”/>”;
public final List /*<xsl:value-of select=”@JAVATYPE”/>*/ <xsl:value-of select=”@NAME”/
>(<xsl:call-template name=”declareFillParameters”/>)
{
String sql = “<xsl:value-of select=”COMPILED/BODY”/>”;
ArrayList list = new ArrayList();
PreparedStatement stmt = null;
ResultSet rs = null;
Connection conn = null;
try {
conn = JDBCConnection.getConnection(“<xsl:value-of select=”@POOL”/>”);
stmt = conn.prepareStatement(sql);
// . . . .
return list;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te);
} finally
{
try {rs.close(); rs = null;} catch (Exception e){ // log your errors here }
try {stmt.close(); stmt = null;} catch (Exception e){ // log your errors here }
JDBCConnection.releaseConnection(conn);
}
}
</xsl:template>
Listing 6.16 This template generates the fill method for each SQL context
Here is the auxiliary template that helped us generate a declaration of parameters for the fill-meth-
od. It puts a comma after each parameter, except the latest and narrows the definition of the Date
to java.util.Date to avoid ambiguity between java.sql and java.util packages imported at the begin-
ning of the class:
<xsl:template name=”declareFillParameters”>
<xsl:for-each select=”PARAM[@IN=’Y’]”>
<xsl:if test=”position()!=1”>, </xsl:if>
<xsl:choose>
<xsl:when test=”@JAVATYPE=’Date’”>java.util.Date</xsl:when>
<xsl:otherwise><xsl:value-of select=”@JAVATYPE”/></xsl:otherwise>
</xsl:choose>
<xsl:text> </xsl:text>
<xsl:value-of select=”@NAME”/>
</xsl:for-each>
</xsl:template>
{
String sql = “select * from employee where start_date < ? or start_date=?”;
ArrayList list = new ArrayList();
PreparedStatement stmt = null;
ResultSet rs = null;
Connection conn = null;
try {
conn = JDBCConnection.getConnection(“jdbc/theriabook”);
stmt = conn.prepareStatement(sql);
stmt.setDate(1, DateTimeConversion.toSqlDate(startDate));
stmt.setDate(2, DateTimeConversion.toSqlDate(startDate));
rs = stmt.executeQuery();
while( rs.next() ) {
com.theriabook.datasource.dto.EmployeeDTO dto = new com.theriabook.data
source.dto.EmployeeDTO();
dto.EMP_ID = (rs.getInt(“EMP_ID”));
dto.MANAGER_ID = (rs.getInt(“MANAGER_ID”));
dto.EMP_FNAME = (rs.getString(“EMP_FNAME”));
dto.EMP_LNAME = (rs.getString(“EMP_LNAME”));
dto.DEPT_ID = (rs.getInt(“DEPT_ID”));
dto.STREET = (rs.getString(“STREET”));
dto.CITY = (rs.getString(“CITY”));
dto.STATE = (rs.getString(“STATE”));
dto.ZIP_CODE = (rs.getString(“ZIP_CODE”));
dto.PHONE = (rs.getString(“PHONE”));
dto.STATUS = (rs.getString(“STATUS”));
dto.SS_NUMBER = (rs.getString(“SS_NUMBER”));
dto.SALARY = (rs.getDouble(“SALARY”));
dto.START_DATE = DateTimeConversion.toUtilDate(rs.getDate(“START_DATE”));
dto.TERMINATION_DATE = DateTimeConversion.toUtilDate(rs.getDate(“TERMINATION_
DATE”));
dto.BIRTH_DATE = DateTimeConversion.toUtilDate(rs.getDate(“BIRTH_DATE”));
dto.BENE_HEALTH_INS = (rs.getString(“BENE_HEALTH_INS”));
dto.BENE_LIFE_INS = (rs.getString(“BENE_LIFE_INS”));
dto.BENE_DAY_CARE = (rs.getString(“BENE_DAY_CARE”));
dto.SEX = (rs.getString(“SEX”));
list.add(dto);
}
return list;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te);
} finally {
try {rs.close(); rs = null;} catch (Exception e){}
try {stmt.close(); stmt = null;} catch (Exception e){}
JDBCConnection.releaseConnection(conn);
}
}
To “teach” our stylesheet to produce this code, we’ll replace the try clause generated by the <tem-
plate match=”SQL”> currently containing:
try {
conn = JDBCConnection.getConnection(“<xsl:value-of select=”@POOL”/>”);
stmt = conn.prepareStatement(sql);
// . . . .
return list;
}
try {
conn = JDBCConnection.getConnection(“<xsl:value-of select=”@POOL”/>”);
stmt = conn.prepareStatement(sql);
<xsl:call-template name=”setParameters”/>
rs = stmt.executeQuery();
while( rs.next() ) {
<xsl:variable name=”itemType” select=”substring(string(@JAVA
TYPE), 1, string-length(string(@JAVATYPE))-2)”/> <xsl:value-of
select=”$itemType”/> dto = new <xsl:value-of select=”$itemType”/>();
<xsl:call-template name=”readRecord”/>
list.add(dto);
}
return list;
}
As you can see, we’ve delegated the work of calling the setXXX() methods to the named template
setParameters and reading of the result set – to the named template readRecord. Let’s walk through
these templates one at a time.
stmt.setDate(1, DateTimeConversion.toSqlDate(startDate));
stmt.setDate(2, DateTimeConversion.toSqlDate(startDate));
We’ve centralized this and similar conversions under the named template convertJavaArgument-
ToJDBC:
<xsl:template name=”convertJavaArgumentToJDBC”>
<xsl:choose>
<xsl:when test=”@JAVATYPE=’Date’”>DateTimeConversion.toSqlDate(<xsl:value-of
select=”@NAME”/>)</xsl:when>
<xsl:when test=”@JAVATYPE=’Time’”>DateTimeConversion.toSqlTime(<xsl:value-of
select=”@NAME”/>)</xsl:when>
<xsl:otherwise>
<xsl:value-of select=”@NAME”/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
After taking care of the Java-to-JDBC conversion, the template setParameters becomes easy:
<xsl:template name=”setParameters”>
<xsl:for-each select=”COMPILED/PARAM[@IN=’Y’]”>
stmt.set<xsl:value-of select=”@JAVATYPE”/>(<xsl:value-of select=”@INDEX”/>,
<xsl:call-template name=”convertJavaArgumentToJDBC”/>);</xsl:for-each>
</xsl:template>
There is one more point to make before we can look at the implementation of the readRecord tem-
plate. The data types per DATASET/FIELDS/FIELD nodes are database-specific types, not JDBC
ones. For example, we have to apply additional mapping to produce getString() for the char data-
base columns and getDouble() for the decimal ones. This mapping is provided by the named tem-
plate mapDBtoJDBC (you may need to tweak it a bit for your DBMS):
And now, let’s look at the readRecord template, which iterates over all the fields of the result set and
generates lines like:
dto.EMP_ID = (rs.getInt(“EMP_ID”));
dto.SALARY = (rs.getDouble(“SALARY));
In addition, JDBC-related date/time types get converted from java.sql to java.util form:
dto.START_DATE = DateTimeConversion.toUtilDate(rs.getDate(“START_DATE”));
<xsl:template name=”readRecord”>
<xsl:for-each select=”DATASET/FIELDS/FIELD”>dto.<xsl:value-of
select=”@name”/> = <xsl:choose>
<xsl:when test=”string(@type)=’date’”>DateTimeConversion.toUtilDate</xsl:when>
<xsl:when test=”string(@type)=’datetime’”>DateTimeConversion.toUtilDate</xsl:
when>
<xsl:when test=”string(@type)=’time’”>DateTimeConversion.toUtilDate</xsl:when>
<xsl:when test=”string(@type)=’timestamp’”>DateTimeConversion.toUtilDate</xsl:
when>
<xsl:otherwise></xsl:otherwise>
</xsl:choose>(rs.get<xsl:call-template name=”mapDBtoJDBC”/>(“<xsl:value-of
select=”@name”/>”));
</xsl:for-each>
</xsl:template>
This concludes the complete implementation of the fill-method. The sync-method templating
comes next.
Listing 6.21 presents the XML metadata we’ve been working with in this chapter, but it’s the first
time that we show the UPDATE node. As expected, the UPDATE node holds the name of the table to
update. It also indicates that the WHERE clause of the generated INSERT/DELETE/UPDATE state-
ments should be based on the key fields (as opposed to the other alternatives: modified fields and
the combination key-and-modified):
ASTYPE=”com.theriabook.dto.EmployeeDTO[]” JAVATYPE=”com.theriabook.dto.
EmployeeDTO[]”
>
<PARAM IN=”Y” INDEX=”1” JAVATYPE=”Date” NAME=”startDate”/>
. . . .
</COMPILED >
<UPDATE TARGET=”EMPLOYEE”>
<TABLE NAME=”EMPLOYEE” UPDATEMETHOD=”key”/>
</UPDATE>
<DATASET><FIELDS>
<FIELD key=”yes” name=”EMP_ID” tableName=”employee” type=”integer”
updatable=”yes”/>
. . . .
</FIELDS></DATASET>
</SQL>
</SERVER>
</WEBSERVICE>
Listing 6.21 The DAOFlex metadata with information for the sync-method
Interestingly, the top-level code for the sync-method doesn’t really depend on any of this. Indeed,
we need to process the entire input List of ChangeObjects. We’ll do it in three passes (as we did in a
manual mode in Listing 6.7) and execute all DELETEs first, with UPDATEs and INSERTs, but again,
the code will be pretty agnostic relative to the underlying SQL. Listing 6.22 presents the template
that automatically generates such a sync-method given the content of the <SQL /> metadata node
as the context:
iterator = items.iterator();
while (iterator.hasNext()) { // Finish with inserts
co = (ChangeObject)iterator.next();
if (co.isCreate()) doCreate_<xsl:value-of select=”@NAME”/>(conn, co);
}
} catch(DataSyncException dse) {
dse.printStackTrace();
throw dse;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te.getMessage(), te);
} finally {
if( conn!=null ) JDBCConnection.releaseConnection(conn);
}
return items;
</xsl:template>
Now, to make sure this template accompanies the original <xsl:template match=”SQL”> we’ll mod-
ify the latter with the <xsl:apply-templates> as shown in the following snippet:
<xsl:template match=”SQL”>
<xsl:variable name=”itemType” select=”substring(string(@JAVATYPE), 1, string-length(st
ring(@JAVATYPE))-2)”/>
</xsl:template>
Since we’re transforming our Employee.xml metadata with the SimpleDataServiceDao.xsl in its
current state, the relevant fragment of the output will look like Listing 6.23:
ChangeObject co = null;
try {
conn = JDBCConnection.getPooledConnection(“jdbc/theriabook”);
Iterator iterator = items.iterator();
while (iterator.hasNext() ) { // Do all deletes first
co = (ChangeObject)iterator.next();
if(co.isDelete()) doDelete_searchEmployees(conn, co);
}
iterator = items.iterator();
while (iterator.hasNext()) { // Proceed to all updates next
co = (ChangeObject)iterator.next();
if(co.isUpdate()) doUpdate_searchEmployees(conn, co);
}
iterator = items.iterator();
while (iterator.hasNext()) { // Finish with inserts
co = (ChangeObject)iterator.next();
if (co.isCreate()) doCreate_searchEmployees(conn, co);
}
} catch(DataSyncException dse) {
dse.printStackTrace();
throw dse;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te.getMessage(), te);
} finally {
if( conn!=null ) JDBCConnection.releasePooledConnection(conn);
}
return items;
}
}
<xsl:call-template name=”doUpdate” />
<xsl:call-template name=”doDelete” />
<xsl:call-template name=”doInsert” />
</xsl:template>
Let’s start with doUpdate. Remember our exercise with handcrafted DataService-based code? That
doUpdate() contained a StringBuffer of the UPDATE statement. Given that our XML context is the
<SQL> node we can generate the required line as
To produce the WHERE clause, which will enumerate all the key columns in the form “key1=?,
key2=?” we can do the following:
Then, to substitute the “?” symbols with the key values we will employ the similar <xsl:for-each/>:
combined with what we learned about the ChangedObject’s getPreviousValue() method:
<xsl:for-each select=”DATASET/FIELDS/FIELD[@key=’yes’]”>
stmt.setObject(ii++, co.getPreviousValue(“<xsl:value-of select=”@name”/>”));</xsl:
for-each>
Ultimately we’ll arrive at the text of the doUpdate template as shown in Listing 6.24:
stmt = conn.prepareStatement(sql.toString());
<xsl:for-each select=”DATASET/FIELDS/FIELD[@key=’yes’]”>
stmt.setObject(ii++, co.getPreviousValue(“<xsl:value-of select=”@name”/>”));</
xsl:for-each>
The template implementing the doDelete method is very similar, except that, due to the syntax of
the DELETE statement it ventures into enumerating the WHERE-hosted keys right off the bat while
preparing the StringBuffer:
<xsl:for-each select=”DATASET/FIELDS/FIELD[@key=’yes’]”>
stmt.setObject(<xsl:value-of select=”position()”/>, co.getPreviousValue(“<x
sl:value-of select=”@name”/>”));
</xsl:for-each>
if (stmt.executeUpdate()==0) throw new DataSyncException(co);
} finally {
try { if( stmt!=null) stmt.close(); stmt = null;} catch (Exception e){}
}
}
</xsl:template>
We did not list the results of the XSL transformation here because they are literally identical to the
handcrafted code we modeled our templates after.
We’re almost there. The only remaining part of the SimpleDataServiceDao.xsl to discuss is the do-
Create template, which will be covered next.
The named template “mapDBtoJDBC” (see Listing 6.20) comes in handy again. Provided the con-
text is a metadata node <FIELD>, we can generate the proper setXXX() call with the line:
stmt.set<xsl:call-template name=”mapDBtoJDBC”/>(arguments);
To perform the type conversion, we’ll add another named template, convertJavaColumnToJDBC.
It expects to use the value of the database column’s type and an expression for conversion. For the
date/time/timestamp types it converts the Java value of the DTO property into the corresponding
value from the java.sql package leaving other expressions intact:
<xsl:template name=”convertJavaColumnToJDBC”>
<xsl:param name=”type”/>
<xsl:param name=”expression”/>
<xsl:when test=”type=’date’”>DateTimeConversion.toSqlDate(<xsl:value-of
select=”$expression”/>)</xsl:when>
<xsl:when test=”type=’datetime’”>DateTimeConversion.toSqlTimestamp(<xsl:value-of
select=”$expression”/>)</xsl:when>
<xsl:when test=”type=’time’”>DateTimeConversion.toSqlTime(<xsl:value-of
select=”$expression”/>)</xsl:when>
<xsl:when test=”type=’timestamp’”>DateTimeConversion.toSqlTimestamp(<xsl:value-of
select=”$expression”/>)</xsl:when>
<xsl:otherwise><xsl:value-of select=”$expression”/></xsl:otherwise></xsl:choose></xsl:
template>
Listing 6.26 The template of converting date/time targeting values to java.sql.* values
And here is the last component. In the absence of dedicated null indicators traveling along with
the DTO, the only way to set NULL values for types like double and float is to have an if statement
similar to:
if (Double.isNaN(item.SALARY))
stmt.setNull(4,Types.DOUBLE);
else
stmt.setDouble(4, item.SALARY);
Putting it all together, we arrive at the template writeRecord. It starts with converting source ex-
pressions like item.BIRTH_DATE, item.START_DATE, etc., into a jdbcValue. Then, depending on the
FIELD type, it generates an if-statement like the one above or outputs a setXXX() statement with
the code:
stmt.set<xsl:call-template name=”mapDBtoJDBC”/>(<xsl:value-of
select=”position()”/>,
<xsl:value-of
select=”$jdbcValue”/>);
<xsl:template name=”writeRecord”>
<xsl:for-each select=”DATASET/FIELDS/FIELD”>
<xsl:variable name=”jdbcValue”>
<xsl:call-template name=”convertJavaColumnToJDBC”>
<xsl:with-param name=”type” select=”@type”/>
<xsl:with-param name=”exp”>item.<xsl:value-of select=”@name”/>
</xsl:with-param>
</xsl:call-template>
</xsl:variable>
<xsl:choose>
<xsl:when test=”@type=’double’ or @type=’decimal’ or @type=’money’ or
(@type=’number’ and @scale!=’0’) or @type=’numeric’”>
if (Double.isNaN(item.<xsl:value-of select=”@name”/>))
stmt.setNull(<xsl:value-of select=”position()”/>,Types.DOUBLE);
else
stmt.setDouble(<xsl:value-of select=”position()”/>, item.<xsl:value-of
select=”@name”/>);</xsl:when>
<xsl:when test=”@type=’float’ or @type=’smallfloat’”>
if (Float.isNaN(item.<xsl:value-of select=”@name”/>))
stmt.setNull(<xsl:value-of select=”position()”/>,Types.FLOAT);
else
stmt.setFloat(<xsl:value-of select=”position()”/>, item.<xsl:value-of
select=”@name”/>);</xsl:when>
<xsl:otherwise>
stmt.set<xsl:call-template name=”mapDBtoJDBC”/>(<xsl:value-of
select=”position()”/>, <xsl:value-of select=”$jdbcValue”/>);</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:template>
If you’ve made it so far, the XSL template for doCreate will look trivial. It builds the SQL INTO clause
of the INSERT iterating over the result set fields, and iterates over it again to place an adequate
number of comma-separated “?” characters. Then, on calling conn.prepareStatement() it invokes
the template writeRecord. That’s it.
stmt = conn.prepareStatement(sql);
Here is the output of the doCreate() template against the Employee.xml metadata:
stmt = conn.prepareStatement(sql);
stmt.setInt(1, item.EMP_ID);
stmt.setInt(2, item.MANAGER_ID);
stmt.setString(3, item.EMP_FNAME);
stmt.setString(4, item.EMP_LNAME);
stmt.setInt(5, item.DEPT_ID);
stmt.setString(6, item.STREET);
stmt.setString(7, item.CITY);
stmt.setString(8, item.STATE);
stmt.setString(9, item.ZIP_CODE);
stmt.setString(10, item.PHONE);
stmt.setString(11, item.STATUS);
stmt.setString(12, item.SS_NUMBER);
if (Double.isNaN(item.SALARY))
stmt.setNull(13,Types.DOUBLE);
else
stmt.setDouble(13, item.SALARY);
stmt.setDate(14, DateTimeConversion.toSqlDate(item.START_DATE));
stmt.setDate(15, DateTimeConversion.toSqlDate(item.TERMINATION_DATE));
stmt.setDate(16, DateTimeConversion.toSqlDate(item.BIRTH_DATE));
stmt.setString(17, item.BENE_HEALTH_INS);
stmt.setString(18, item.BENE_LIFE_INS);
stmt.setString(19, item.BENE_DAY_CARE);
stmt.setString(20, item.SEX);
if (stmt.executeUpdate()==0) throw new DAOException(“Failed inserting.”);
co.setNewVersion(item);
return co;
} finally {
We need to emphasize why we went to such lengths explaining how these stylesheets work.
As we said earlier the rapid application development tools (RAD) that use automated code genera-
tion assume that you feel comfortable with XSL templates. For instance, a JDBC-related template
like the one we’ve been making so far may work slightly differently for a particular JDBC driver. The
metadata reported by different JDBC drivers may also be slightly different. For instance we’ve omit-
ted BLOB and CLOB support from our template. While working with a specific database, you can
tune the stylesheet to match your driver and forget the tedious process of handcrafting, debugging,
and testing the code doing the routine database processing.
Start with the welcome.html file located in the root directory to get a brief intro to DAOFlex, its
setup and usage. Other documents – setup.htm and syntax.html – are located in the docs folder.
Please note file JRun4.zip and Tomcat5.5.zip. These files contain “deltas” – everything you need to
unzip on top of existing Tomcat or JRun to have DAOFlex up and running, including the database
connectivity. You’d also need to install the MySQL test database, applying the backup file test.sql
from mysql_backup folder. All required steps are described in /docs/setup.htm.
The folder dist contains DAOFlex’s Java sources. The Ant build.xml files, residing in dist/generator
and dist/runtime, produce relevant JARS in the build folder. These Ant files rely on the JARS from
the lib folder explained below.
The folder examples contains sample Java source files annotated with the DAOFlex:sql tag. It also
contains a build.xml file to run DAOFlex code generation, with dependencies on the build/dao-
Flex-generator.jar and other files from the /lib folder. While setting up your DAOFlex project you’ll
be copying and modifying this build.xml file. Folder examples also contain the OrderManagement
subfolder, with the source files relevant to the transactional application from Chapter 7.
(Please note that due to differences between Java4 and Java5 we supply two distinct versions of
build files. These build files correspond to two distinct versions or daoflex-runtime.jar and daoflex-
generator.jar from the lib folder. In particular, you’d use Java5 jars and build.xml for Tomcat5.5 and
Java4 versions for JRun4.)
The folder lib contains jars required to build DAOFlex and run code generation by build.xml from
inside the examples folder or your own DAOFlex-based project. You may need to extend the con-
tents of the lib with your specific JDBC driver. We provided late drivers, as of the time of writing,
drivers for Oracle, Sybase, and MySQL. Pre-built daoflex-generator.jar and daoflex-runtime.jar are
also stored here.
The xsl folder contains XSL stylesheets used by the DAOFlex generator. Since the stylesheets’ look-
up is done along the classpath of the DAOFlex doclet, you can overload standard templates with
your own without physically replacing the originals in the DAOFlex/xsl folder.
The root folder of the DAOFlex distribution also contains two properties files: daoflex.properties
and daoflex-runtime.properties.
The file daoflex.properties lists all of the templates that are being applied against the metadata ex-
tracted from the annotated Java files. Here you can explicitly tell DAOFlex to go through your own
template, instead of the standard one, or add templates that, perhaps, generate Grid descendant
controls, etc.
The file DAOFlex-runtime.properties has to be visible to the classloader’s chain of your Web ap-
plication. At present it contains one line with the JNDI prefix of the JDBC namespace and isn’t
required if your application server is JRun or WebLogic (but you would need it for Tomcat and
WebSphere):
datasource.jndi.root=java:comp/env
If you’re planning to use DS under the Apache Tomcat server, you’ll have to install and config-
ure Java Open Transaction Manager (JOTM), an implementation of the full distributed transaction
support for Java applications. You’ll have to drop the JOTM jars into the <tomcat>/common/lib or
WEB-INF/lib of your Web Application. You also would have to add the following lines to the appli-
cation configuration file <tomcat>/conf/Catalina/localhost/theriabook.xml:
You can get details on JOTM/Tomcat configuration in the documentation section at http://jotm.
objectweb.org/index.html. Again, if you simply unzip Tomcat5.5.zip from the DAOFlex root on top
of your Tomcat installation, every configuration step will have been taken care of. You can browse
this zip file to study the required changes in detail.
Let’s start with the configuration properties contained in the build.xml. (The up-to-date version of
the examples/build.xml file may be different from the one described in this section.)
The first group of properties relates to original and generated text files. They are:
You can change these values any way you want, but take into account that it doesn’t make a lot of sense
to keep generated Java files or compiled classes in the source control system. For that reason, we find
it convenient to keep generated Java files in the separate subtree and, for the same reason, build.xml
creates two separate JAR files for compiled source classes and compiled generated classes.
The second group of properties relates to the location of the DAOFlex home directory and the de-
ployment location of the application as a whole and output JAR files in particular:
Once you figure out the values of the above configuration properties you can proceed to setting
up the dataSource (database connection pool)-related files. These files contain the driver URL,
userid, and password to enable the DAOFlex generator to connect to your database and get the
SQL metadata. No harm will be done to the database, and the DAOFlex generator will make sure
that design-time queries return no data. Just to remind you, the file theriabook.properties is inside
the examples/jdbc folder. It corresponds to the connection pool (dataSource name) jdbc/theri-
abook per the annotation in examples/src/com/theriabook/datasource/Employee.java.
Similar to the stylesheets, connection pool properties files are looked up via the DAOFlex Doclet
classpath. According to examples/build.xml, the Doclet classpath includes examples and DAOFlex
home, so if you have multiple projects sharing the same connection parameters you can provide
JDBC connection files relative to DAOFlex’s home directory.
Finally, before running the DAOFlex generator, put the annotated files under the folder pointed to
by the property source.java.root (see above).
As a result, you’ll see the files generated, the Java code compiled, and JARred split into two separate
JARs, and placed as per your settings.
Alternatively, you may use Eclipse. You’d need to go to Java Perspective and create a new Java proj-
ect from the existing Ant file defaulting to the javac task build-original, as shown in Figure 6.3:
Then you’d be able to run and rerun the code-generation process, compilation, and jarring – every-
thing your build.xml does with the Run Ant right-mouse menu off the highlighted build.xml.
Here’s a sample extract from the console output of the DAOFlex code generator:
Next, you can find a complete generated MXML single-grid application in the folder pointed by
generated.test.root. Specifically in case of the Employee.java provided in our examples, the Data
Services testing application Employee__GridTest.mxml will be located under the folder:
examples/generated/web/test/ds/com/theriabook/datasource
Let’s assume again that you allow DAOFlex to output test MXML files directly inside the Flex
project you’re working on or, conversely, that you set up a Flex project using the folder with the
generated file. If you set up the project to be compiled locally, you’ll need one additional step to
run Employee__GridTest.mxml – copy the contents to the root of your project. Otherwise, if your
project is set up to compile on the server, you can run the Employee__GridTest.mxml from its
current location.
Either way Figure 6.5 shows how the application will look. Look familiar? Yep, that’s the applica-
tion we started the chapter with, with one very essential difference: we didn’t write a single line of
code other than a simple annotated Java class as in Listing 6.10. We just processed this class with
DAOFlex.
Summary
In this chapter not only have we shown you a tool that can automate tedious programming of the
datagrid/database communication, but have also explained how you could create such a tool on
your own. In other words, we’ve both given you a fish and taught you how to fish. We generated
Java, MXML, and ActionScript code with Java doclets. With Java5 we could have used Java annota-
tions and the Annotation Processing Tool (APT) that are beyond the scope of this book.
In addition to the open source version of DAOFlex described in this chapter, there is a commercial
DaoFlex plugin for Eclipse, developed by FarataSystems, LLC. You can download this and other
plugins for Flex at http://www.myflex.org.
Endnote
1. In this case DaoFlex looks for jdbc/theriabook.properties in the project folder and then in the DaoFlex home
folder.
This chapter is about data management, client/server data synchronization, and transaction pro-
cessing: the classic topics that represent a large portion of the budget of any enterprise project
whether your industry is e-commerce, financial, manufacturing, or healthcare – any application
centered around data.
We touched on this subject in the previous chapter, when we discussed Flex Data Services, which
are focused on peer-server-peer data replication at the price of server-side caching complexity. At
the same time Flex offers an elegant yet powerful mechanism of Flex Remoting, which has zero
impact on server architecture and, by virtue of absolving the server from data persistence chores,
allows your systems to scale practically without limits.
We’ll start by upgrading a regular Flex Collection to what we call a “destination-aware” collection,
capable of populating itself from a remote destination. Through a detailed study of the mechanics
of Flex Collections and the anatomy of Managed ActionScript objects we will then lead you to the
creation of a “change-tracking” and “updatable” Data Collection. This collection accumulates all
changes in a controlled manner and, at your command, sends them to the server-side Java sync()
method packaged exactly as a DataService would package them for commit().
Finally, we will teach you how you can batch the execution of any arbitrary remote calls so that, for
instance, your ActionScript client can control sophisticated transactions spanning multiple desti-
nations, including calls to sync() methods, calls to stored procedures or, in general, anything that
your application may need to incorporate in a transaction executed by the server.
At the end of this chapter, we will illustrate the use of Flex Remoting for data synchronization tasks
with a sample OrderEntryDemo application.
that the AMF 3 protocol is by far the fastest Flash Player/Server communication mechanism, and
this is why invoking a Java POJO via Flex Remoting can yield an order of magnitude performance
gain over XML/Web Services, depending on the data volume.
To employ the EmployeeDataServiceDao class for Flex Remoting we will configure WEB-INF/
flex/remoting-config.xml to contain the destination “Employee” as shown in Listing 7.1 be-
low:
<adapters>
<adapter-definition id=”java-object”
class=”flex.messaging.services.remoting.adapters.JavaAdapter” default=”true”/>
</adapters>
<default-channels>
<channel ref=”my-amf”/>
</default-channels>
<destination id=”Employee”>
<properties>
<source>com.theriabook.datasource.EmployeeDataServiceDAO</source>
</properties>
</destination>
</service>
Now our class is a legitimate remoting destination – we will use it a bit later.
How about eliminating the middleman – ds? We are talking about a destination-aware collection
capable of taking care of filling itself:
ac.method = “getEmployees”;
Importantly, we brought back to ActionScript what had been hardwired on the server-side by the
DataService approach. Let’s see how the application code can benefit from any data-awareness
of our collection. Listing 7.2 presents an MXML application that we called DestinationAwareCol-
lectionDemo:
}
]]>
</mx:Script>
</mx:Application>
This application contains a data grid with a dataProvider bound to an instance of Destination-
AwareCollection. There is no RemoteObject in sight, no event handlers for ResultEvent and Fault-
Event. The only data-related code contained in our application is the initialization of collection
parameters and the invocation of its fill() method:
Simple, isn’t it? But what’s inside this black box called DestinationAwareCollection?
Then we introduce a public method fill(). Since all AMF invocations are asynchronous messages, we
design fill() to return an AsyncToken, which is a locally cached object. In your typical scenario, Async-
Token gets accessed twice: you use it to store some data related to the particular request during the
send and then, when the response comes, you look up the same data for a just-in-time perusal:
Now let’s get to the implementation details. The only parameter of the fill() method is defined as…
rest array, which in turn is passed to the invocation of the remoting operation:
ro = new RemoteObject();
ro.destination = destination;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
return ro;
}
In the case of FaultEvent, we just pop up an optional Alert. But in the ResultEvent handler we
change the underlying data source of the collection, and that’s why we call the ArrayCollection’s
refresh() method updating all the views associated with the collection:
In both event handlers we re-dispatch the event to the collection itself. You may want to add more
logic here, allowing your collection to prevent the default processing. For instance, you may have
some new content appended to the collection instead of wiping out the existing rows. The full list-
ing of DestinationAwareCollection is presented in Listing 7.3:
// DestinationAwareCollection.as
package {
import mx.collections.ArrayCollection;
import mx.controls.Alert;
import mx.managers.CursorManager;
import mx.rpc.AbstractOperation;
import mx.rpc.AsyncToken;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import mx.rpc.remoting.mxml.RemoteObject;
[Event(name=”result”, type=”mx.rpc.events.ResultEvent”)]
[Event(name=”fault”, type=”mx.rpc.events.FaultEvent”)]
public class DestinationAwareCollection extends ArrayCollection {
public var destination:String=null;
public var method : String = null;
public var alertOnFault:Boolean=true;
protected var ro:RemoteObject = null;
ro = new RemoteObject();
ro.destination = destination;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
return ro;
}
<mx:ControlBar>
<mx:Button label=”Remove” click=”collection.removeItemAt(dg.selectedIndex)”
enabled=”{dg.selectedIndex != -1}”/>
<mx:Button label=”Add” click=”collection.addItemAt(new EmployeeDTO(),
Math.max(0,dg.selectedIndex+1)) “/>
</mx:ControlBar>
<mx:Script>
<![CDATA[
import ChangeSensitiveCollection;
import com.theriabook.datasource.dto.EmployeeDTO;
[Bindable] private var collection:ChangeSensitiveCollection;
// ChangeSensitiveCollection.as
package {
import mx.events.CollectionEvent;
import mx.events.PropertyChangeEvent;
import mx.utils.ObjectUtil;
switch(event.kind) {
case “remove”:
for (var i:int = 0; i < event.items.length; i++) {
var item:Object = event.items[i];
trace (“REMOVED:” + mx.utils.ObjectUtil.toString(item));
}
break;
case “add”:
for ( i = 0; i < event.items.length; i++) {
item = event.items[i];
trace (“ADDED:” + mx.utils.ObjectUtil.toString(item) );
}
break;
case “update”:
for (i = 0; i < event.items.length; i++) {
item = null;
var pce:PropertyChangeEvent = event.items[i] as PropertyChangeEvent;
if ( pce != null) {
item = pce.currentTarget;
}
if (item != null) {
trace (“MODIFIED: “ + mx.utils.ObjectUtil.toString(item));
}
}
break;
}
}
}
}
If we debug the ChangeSensitiveCollectionDemo and, say, delete one row by clicking “Remove”
and type something into another row,3 we’ll see the following trace output:
EMP_LNAME = “Chin”
. . . .
As you can see, the CollectionEvent is pretty talkative and we are going to tap into that pretty soon,
building a collection that’s capable of managing its state.
But take a simple assignment like x.firstName=”Joe” where x is the record in the array that backs a
collection. Such an assignment might go completely unnoticed by the collection. Luckily, the col-
lection API offers an itemUpdated() method to give the application a way to notify the collection of
the data modifications.
Please notice the word “might” above; if an array’s elements dispatch the PropertyChangeEvent,
collection is notified automatically and the idiosyncratic itemUpdated() is out of a job. Flex collec-
tion classes live and breath PropertyChangeEvent so your best bet is to make sure that you “collect”
objects that follow the pattern.
Obviously, you can dispatch PropertyChange events explicitly, but this book isn’t about how to
make you work harder. Flex automates this task for you. One way to automatically dispatch the
PropertyChangeEvent is to use a [Bindable] metadata tag. If you place [Bindable] in front of a class
declaration, Flex will generate the code to dispatch a PropertyChange event for all public proper-
ties; optionally you may annotate individual properties of the class as [Bindable].
An alternative way of ensuring the dispatch of the PropertyChangeEvent is to use managed classes.
If you put [Managed] in front of the class declaration, Flex generates a wrapper class that turns all
your properties [Bindable] and implements an IManaged interface comprised of three other inter-
faces as shown below:
The IPropertyChangeNotifier interface, as the name suggests, mandates dispatching the Property-
ChangeEvent. Actually, it goes further. Not only are you supposed to dispatch the event to the proper-
ties of your class, but you have to do it for the properties of complex data types as well.
An implementation of this interface is expected to construct update events using a special method of
the PropertyChangeEvent class called createUpdateEvent().
The second interface – IEventDispatcher – is the main interface required to enable the dis-
patching of any event. The simplest way to implement IEventDispatcher is to extend the flash.
events.EventDispatcher class; another solution is to aggregate an instance of the EventDispatcher
acting as a wrapper around it.
Finally, implementers of the IUID interface have to provide a getter/setter pair implementing a uid
property.
Loaded with this knowledge, let’s look at the implementation of the EmployeeDTO class, Listing
7.6:
[RemoteClass(alias=”com.theriabook.datasource.dto.EmployeeDTO”)]
[Bindable(event=”propertyChange”)]
public dynamic class EmployeeDTO extends EventDispatcher implements IManaged
{
// Properties
private var _EMP_ID : Number;
private var _EMP_FNAME : String;
. . . .
public function get EMP_ID() : Number{
return _EMP_ID;
}
public function set EMP_ID( value : Number):void{
var oldValue:Object = this._EMP_ID;
if (oldValue !== value) {
this._EMP_ID = value;
dispatchUpdateEvent(“EMP_ID”, oldValue, value);
}
}
The class starts with a [RemoteClass] annotation, stating that this class should be marshaled and re-
created as its peer com.theriabook.datasource.dto.EmployeeDTO on the server side. Then we have a
[Bindable] class-scope annotation. Notice that we’ve implemented all the properties as getter/setter
pairs: we couldn’t just let them stay public variables since we’ve been contracted to use createUp-
dateEvent(). In other words, we couldn’t let Flex auto-generate the event dispatching code. Besides
functional properties like EMP_ID and EMP_FNAME, our class also contains a setter and getter for
the uid property; this qualifies the class as an IUID implementer. Since our class is extending the
EventDispatcher, it already implements inherently IEventDispatcher, and that completes the list of
requirements to qualify the class as an implementation of the IManaged interface.
Everything we’ve done so far can be also achieved by putting a [Managed] annotation in front of the
class as shown in Listing 7.7. As you might remember, having your classes managed is a must-have
requirement with DataServices. That’s why [Managed] or, alternatively, the explicit implementa-
tion of IManaged, becomes an ideal common denominator between DataServices and handmade
just-in-time collections notified by underlying objects:
[RemoteClass(alias=”com.theriabook.datasource.dto.EmployeeDTO”)]
[Managed]
public dynamic class EmployeeDTO
{
// Properties
public var EMP_ID : Number;
public var EMP_FNAME : String;
. . . .
As a reminder, if you use the DAOFlex utility introduced in Chapter 6, you don’t have to write Ac-
tionScript DTO classes at all. DAOFlex generates them based on the SQL metadata that it, in turn,
extracts from SQL query or the stored procedure annotating the signature of the Java method. You
can also use the daoFlex Eclipse plugin available at http://www.myflex.org. It has many extra fea-
tures; in particular, it supports the generation of ActionsScript DTO from existing Java DTO.
Now important things: a DataServiceDAO class from Chapter 6 contains a sync() method that takes
a single parameter – java.util.List of ChangeObjects. Packaging ChangeObjects and the very invo-
cation of sync() have so far been internal FDS affairs. But what stops us from calling sync() methods
from ActionScript directly? Nothing. We’re going to enable 100% reuse of the DAO classes between
FDS and Flex Remoting.
Here’s the plan. First, we’ll make sure that our change-tracking collection class accumulates the
updates, deletes, and inserts done to the collection data. Second, we will teach the collection to
pack all the accumulated changes as an array of ActionScript objects, and each of them will contain
newVersion and previousVersion along with the create/delete/update state variant:
Last, we’ll make sure that these objects get marshaled into Java objects implementing the flex.
data.ChangeObject interface. In Listing 7.8 we indicate that each ChangeObject has to be mar-
shaled to its counterpart ChangeObjectImpl in com.theriabook.remoting package4:
package
{
// This line gets required only in UpdatableCollection
[RemoteClass(alias=”com.theriabook.remoting.ChangeObjectImpl”)]
public class ChangeObject
{
public var state:int;
public var newVersion:Object = null;
public var previousVersion:Object = null;
public var changedPropertyNames:Array= null;
this.state = state;
this.newVersion = newVersion;
this.previousVersion = previousVersion;
}
public function isCreate():Boolean {
return state==ChangeObject.CREATE;
}
public function isUpdate():Boolean {
return state==ChangeObject.UPDATE;
}
public function isDelete():Boolean {
return state==ChangeObject.DELETE;
}
}
}
So let’s implement our plan. As once said, “The goals are clear, tasks are set. To the work, com-
rades!”
Accordingly, we need to modify the onCollectionEvent() handler. Take the remove case, for in-
stance. We have to react differently to original and newly inserted items. Deleting the newly in-
serted items shouldn’t get reported to the server. Further, we have to be careful about what we ask
the server to delete because an item might have been modified and then deleted. In this event it’s
the original item that has to be deleted, not the newVersion of it. All along, we maintain the values
for modifiedCount and deletedCount:
case “remove”:
for (var i:int = 0; i < event.items.length; i++) {
var item:Object = event.items[i];
var co:ChangeObject = ChangeObject(modified[item]);
var originalItem:Object=null;
if (co == null) { // item has not been modified
originalItem = item;
} else if (!co.isCreate()) { // original item has been modified
originalItem = co.previousVersion;
delete modified[item];
modifiedCount--;
} else { // item has been inserted and modified
delete modified[item];
modifiedCount--;
}
if (originalItem!=null) {
deleted.push(originalItem);
deletedCount = deleted.length;
};
}
break;
. . . .
}
The complete code of ChangeTrackingCollection is in Listing 7.9. Besides maintaining the delet-
ed and modified info, our collection includes methods to check and modify the state of the item:
isItemNew(), isItemModified(), and setItemNotModified(). Lastly, it includes resetState()methods
that clear all knowledge about the deleted and modified items and undoItem() that reverts the
item’s properties to their original values:
// ChangeTrackingCollection.as
package {
import flash.utils.Dictionary;
import mx.events.CollectionEvent;
import flash.events.Event;
import mx.events.PropertyChangeEvent;
import mx.utils.ObjectUtil;
import ChangeObject;
[Bindable(event=”propertyChange”)]
public class ChangeTrackingCollection extends DestinationAwareCollection {
}
private function onCollectionEvent(event:CollectionEvent) :void {
if (!trackChanges) return;
switch(event.kind) {
case “remove”:
for (var i:int = 0; i < event.items.length; i++) {
var item:Object = event.items[i];
var co:ChangeObject = ChangeObject(modified[item]);
var originalItem:Object=null;
if (co == null) {
// NotModified
originalItem = item;
} else if (!co.isCreate()) {
// Modified
originalItem = co.previousVersion;
delete modified[item];
modifiedCount--;
} else {
// NewModified
delete modified[item];
modifiedCount--;
}
if (originalItem!=null) {
deleted.push(originalItem);
deletedCount = deleted.length;
};
}
break;
case “add”:
for ( i = 0; i < event.items.length; i++) {
item = event.items[i];
modified[item] = new ChangeObject(ChangeObject.CREATE, item, null);
modifiedCount++;
}
break;
case “update”:
if ( pce != null) {
item = pce.currentTarget;
}
var previousVersion:Object;
if (item != null) {
if(modified[item] == null) {
previousVersion = ObjectUtil.copy(item);
previousVersion[pce.property] = pce.oldValue;
modified[item] = new ChangeObject(ChangeObject.UPDATE, item,
previousVersion);
modifiedCount++;
}
co = ChangeObject(modified[item]);
if (co.changedPropertyNames == null) {
co.changedPropertyNames = [];
}
co.changedPropertyNames.push(pce.property); // TODO avoid duplicates
}
}
break;
}
}
public function isItemNew(item:Object):Boolean {
var co:ChangeObject = modified[item] as ChangeObject;
return (co!=null && co.isCreate());
}
public function isItemModified(item:Object):Boolean {
var co:ChangeObject = modified[item] as ChangeObject;
return (co!=null && !co.isCreate());
}
public function setItemNotModified(item:Object):void {
var co:ChangeObject = modified[item] as ChangeObject;
if (co!=null) {
delete modified[item];
modifiedCount--;
}
}
}
}
Now let’s play with this collection. We’ll create a ChangeTrackingCollectionDemo demo application
with four tabs: “Current,” “Deleted,” “Updated,” and “Created.” At any given moment, each of these
tabs will reveal the state of the corresponding item set. In addition, the “Current” tab will contain the
buttons “Remove,” “Add,” and “Undo” along with counters for the modified and deleted items:
<mx:Canvas label=”Updated”> . . . .
</mx:Canvas>
</mx:TabNavigator>
The next snapshot (see Figure 7.4) was taken when the “Updated” tab was clicked. It shows the
original value of the collection item. To be precise, our application will rebuild the dataProviders
for the Deleted/Updated/Created data grid when the relevant tab is selected:
Similarly, you can view the “Deleted” and “Created” items going to the corresponding tabs. The
complete code for ChangeTrackingCollectionDemo is presented in Listing 7.10:
</mx:DataGridColumn>
<mx:DataGridColumn dataField=”STREET” headerText=”Street” >
<mx:itemRenderer><mx:Component>
<mx:Label
fontWeight=”{outerDocument.collection.isItemModified(data)?’bold’:’normal
’}”/>
</mx:Component></mx:itemRenderer>
</mx:DataGridColumn>
</mx:Array></mx:columns>
</mx:DataGrid>
<mx:ControlBar>
<mx:Button label=”Remove” click=”collection.removeItemAt(dg.selectedIndex)”
enabled=”{dg.selectedIndex != -1}”/>
<mx:Button label=”Add” click=”collection.addItemAt(new EmployeeDTO(), Math.
max(0,dg.selectedIndex+1)) “/>
<mx:Button label=”Undo”
click=”collection.undoItem(dg.selectedItem) “
enabled=”{collection.isItemModified(EmployeeDTO(dg.selectedItem))}”
/>
<mx:Text text=”Modified:{collection.modifiedCount}”/>
<mx:Text text=”Deleted:{collection.deletedCount}”/>
</mx:ControlBar>
</mx:Panel>
<mx:Canvas label=”Deleted”>
<mx:DataGrid id=”dg_deleted” >
<mx:columns><mx:Array>
<mx:DataGridColumn dataField=”EMP_FNAME” headerText=”Emp Fname” />
<mx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import ChangeTrackingCollection;
import com.theriabook.datasource.dto.EmployeeDTO;
[Bindable] public var collection:ChangeTrackingCollection;
private function onCreationComplete():void {
collection = new ChangeTrackingCollection();
collection.destination = “Employee”;
collection.method = “getEmployees”;
collection.fill(new Date());
}
But wait, what was the real purpose of tracking down the changes in the first place? Were we sup-
posed to send them up to the server? Patience, dear reader, check the next section.
Let’s start with the collection class. We’ll extend the ChangeTrackingCollection and introduce an ad-
ditional property – commitRequired, which will be implemented as a getter/setter pair so that any
modifications to deletedCount and modifiedCount also “touches” the property commitRequired:
The most notable feature of the UpdatableCollection is its sync() method. It sends an array of
changes to the server. Our implementation of sync() will assume success and so we’ll clear the
state information in advance, right on the asynchronous send (invoke). However, to handle any
potentially unpleasant surprises, we’ll preserve the same state information in the asynchronous
token:
Now, if things don’t work out, we’ll restore the status quo in the FAULT event handler:
modifiedCount = evt.token.modifiedCount;
deleted = evt.token.deleted;
}
dispatchEvent(evt);
if (alertOnFault) {
Alert.show(evt.fault.faultString, “Error on destination: “
+ evt.message.destination);
}
}
We are all set, short of separating a ResultEvent related to sync() from a ResultEvent originating in
response to fill():
Believe it or not, but this is all there is to the UpdatableCollection; the complete code is in Listing
7.11:
// UpdatableCollection.as
package {
import mx.collections.ArrayCollection;
import mx.controls.Alert;
import mx.events.*;
import mx.managers.CursorManager;
import mx.rpc.AsyncToken;
import mx.rpc.events.*;
import ChangeObject;
act.method = “sync”;
act.modified = modified;
act.deleted = deleted;
act.modifiedCount=modifiedCount;
resetState();
}
}
dispatchEvent(evt);
}
}
}
<mx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import UpdatableCollection;
import com.theriabook.datasource.dto.EmployeeDTO;
[Bindable] public var collection:UpdatableCollection;
private function onCreationComplete():void {
collection = new UpdatableCollection();
collection.destination = “Employee”;
collection.method = “getEmployees”;
collection.fill(new Date());
}
]]>
</mx:Script>
</mx:Application>
All in all we ‘ve taken you through the full cycle: we’ve built a self-sufficient collection that can
feed itself with server-side data and that’s capable of synchronizing changes with the server5. As
you probably realize by now, three layers of inheritance – DestinationAware/ChangeTracking/Up-
dateableCollection – were required purely for didactic purposes. The source code accompanying
this book contains the DataCollection in the com.theriabook.collections package that combines all
functionality in one class.
The order, as a whole, has its own attributes, such as the address and order date:
Once the order is placed, the customer can update it. The customer will expect that the order cre-
ation as well as the order updates follow the transaction or “unit of work” paradigm: it can be com-
pleted only entirely; partial updates won’t happen.
How can we implement transactions in RIA? One thing is certain: BEGIN and COMMIT (or ROLL-
BACK) should happen on the server. If our Java DAO is invoked via a DataServices adapter, the BE-
GIN has already happened. In a Flex Remoting scenario, we should handle transactions ourselves.
Listing 7.13 represents the implementation of the DAO sync() method that would seamlessly work
} else {
if (logger.isDebugEnabled()) logger.debug(“START PARTICIPATING in external
transaction”);
}
getOrders_deleteItems(items);
getOrders_updateItems(items);
getOrders_insertItems(items);
commit = true;
} else {
logger.error(“Cannot start/take part in a JTA transaction”);
}
} catch(DataSyncException dse) {
dse.printStackTrace();
throw dse;
} catch(Throwable te) {
te.printStackTrace();
throw new DAOException(te.getMessage(), te);
} finally {
if (userTransaction!=null) {
try {
if (localTransaction) {
if (commit) {
userTransaction.commit();
if (logger.isDebugEnabled()) logger.debug(“COMMIT userTransaction”);
} else {
userTransaction.rollback();
if (logger.isDebugEnabled()) logger.debug(“ROLLBACK
userTransaction”);
}
} else {
if (!commit)
userTransaction.setRollbackOnly();
if (logger.isDebugEnabled()) logger.debug(“Marked ROLLBACKONLY for
external transaction”);
}
} catch (Exception e){
logger.error(“Could not rollback/mark transaction for rollback”, e);
}
}
}
return items;
}
Listing 7.13 A “universal” Java sync() method for FDS and Remoting
This snippet follows the standard Java Transaction API (JTA) to tentatively begin, commit. or roll
back transactions. If a transaction has been started earlier, it marks it for rollback with setRollback-
Only(); such a transaction can never be committed; it’ll throw an exception if someone attempts
to do it. Please notice that we have broken the real sync into three parts, which will be explained a
bit later:
getOrders_deleteItems(items);
getOrders_updateItems(items);
getOrders_insertItems(items);
When we dealt with one DataCollection everything was simple: we remotely invoked the sync-
Method and it took care of the transaction. In real life we have to deal with multiple DataCollections
at a time. The issue then boils down to:
So let’s step back and look at the DataCollection sync method or at any remote method for that
matter. They can be completely described by destination, method, and parameter values. The Java’s
BatchMember class matches this triad:
package com.theriabook.remoting;
import java.util.*;
Setting aside the client’s task of packing matching ActionScript BatchMembers into
an ActionScript array, let’s see how we could organize the sequential execution of the
batch:
The invoke()method also consists of three major parts, which use the Flex Data Services API. First
we find the destination by name:
MessageBroker mb = MessageBroker.getMessageBroker(null);
RemotingService srv = (RemotingService)mb.getServiceByType(
“flex.messaging.services.RemotingService”
);
Then we get the object’s instance and calculate the method reference:
Finally, we invoke the method and, in the case of an exception, unwrap the cause of the real excep-
tion from within the InvocationTargetException so that by the time the mx.rpc.events.FaultEvent
comes to the ActionScript, it carries an exception as if it was a non-batched call:
try {
result = method.invoke(instance, parameters.toArray());
} catch ( InvocationTargetException e) {
logger.error(e, e.getCause());
throw e.getCause();
}finally {
factoryInstance.operationComplete(instance);
package com.theriabook.remoting;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.*;
import flex.data.DataServiceTransaction;
import flex.messaging.FactoryInstance;
import flex.messaging.util.*;
import flex.messaging.services.remoting.RemotingDestination;
import flex.messaging.MessageBroker;
import flex.messaging.services.RemotingService;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.transaction.*;
import org.apache.log4j.Logger;
import com.theriabook.daoflex.JDBCConnection;
}
return result;
}
result = executeBatch(batch);
commit = true;
return result;
} finally {
if (userTransaction!=null) {
if (commit) {
userTransaction.commit();
if (logger.isDebugEnabled()) logger.debug(“COMMIT userTransaction”);
} else {
userTransaction.rollback();
if (logger.isDebugEnabled()) logger.debug(“ROLLBACK userTransaction”);
}
}
}
}
static Logger logger;
static
{
logger = Logger.getLogger(BatchGateway.class);
}
}
We’ve added executeTransactionBatch(), which has the same mission as executeBatch(); it’s sequen-
tially calling all the listed remote methods and all this is done in a JTA transaction.
So Why bother with a non-transactional batch in the first place? Because a batch comes in very
handy for retrieving. For example, if your screen presents the data from several tables, you don’t
want your application to be in an inconsistent state (half the screen is populated, half is done, half
is refreshed, etc).
<service id=”remoting-service”
class=”flex.messaging.services.RemotingService”
messageTypes=”flex.messaging.messages.RemotingMessage”>
<adapters>
<adapter-definition id=”java-object” class=”flex.messaging.services.remoting.
adapters.JavaAdapter” default=”true”/>
</adapters>
<default-channels>
<channel ref=”my-amf”/>
</default-channels>
. . . .
<destination id=”batchGateway”>
<properties>
<source>com.theriabook.remoting.BatchGateway</source>
</properties>
</destination>
</service>
package com.theriabook.remoting {
[RemoteClass(alias=”com.theriabook.remoting.BatchMember”)]
public class BatchMember {
We are almost there: for each collection that needs to join to the batch, we can write something
like:
var bm:BatchMember;
var batch:Array=[];
bm = new BatchMember(
orderCollection.destination,
orderCollection.syncMethod,
[orderCollection.changes]
);
batch.push(bm);
Then we could place a remote call to BatchGateway and process the callbacks. Mission accom-
plished…or so it seems.
Here’s the problem, however. The simple_order and simple_order_item database tables represent
a master/detail relationship. In referential integrity terms, simple_order_item could have had a
foreign key on the column order_id from simple_order. In this scenario you won’t be able to insert
an item with a non-existent foreign key value; your transaction would succeed only if you inserted
orders first.
In the case of a delete operation, a foreign key definition could possibly prescribe a cascade-dele-
tion of all dependent order items, when an order is being deleted. That’s something we could live
with. But how about this: a foreign key could restrict the deletion of the order until the depen-
dant order items exist. In other words, try to sync your collections in the wrong order and you’re
doomed!
BatchService
To solve the problem identified above, we’ll create a BatchService class that once given a collection,
adds three BatchMembers to the batch: one with deletes, one with inserts, and one with updates. In
the case of more than one collection, our BatchService will consider its priorities and add deletes for all
the collections in reverse order of priority, then add inserts and updates for all – in the opposite order.
Earlier we promised to explain why on the Java DAO side we’ve split the job of sync() into three calls
of this sequence:
getOrders_deleteItems(items);
getOrders_updateItems(items);
getOrders_insertItems(items);
The reason is the need to expose these methods for remoting. As Anton Chekhov used to say6: “If in
the first act you’ve hung a pistol on the wall, then in the following one it should be fired.”
We’ll see how pistols fire from inside our BatchService after introducing a BatchService’s API. Sup-
pose we have two collections – orders and orderItems:
Once the collections are created, we register them with the BatchService specifying their priorities:
batchService.registerCollection(orders,0);
batchService.registerCollection(orderItems,1);
When it’s time to synchronize – perhaps when the user clicks on the Save button – we ask the Batch-
Service to make the batch and send it to the BatchGateway:
That’s all there is to a BatchService API and we can turn our attention to the implementation, see
Listing 7.18. The focal point here is the batchRegisteredCollections() method. This method sends
accumulated collection changes three times,7 which, in case of a getOrdersDAO, translates to a
sequential call via the BatchGateway:
getOrders_deleteItems(items)
getOrders_updateItems(items)
getOrders_insertItems(items)
The other two public methods – registerCollection() and sendBatch() – are rather simple. Please
note how we re-dispatch ResultEvent and FaultEvent from the remote object to the instance of the
BatchService so that the application can process it accordingly.
package com.theriabook.remoting
{
import com.theriabook.collections.DataCollection;
import com.theriabook.remoting.BatchMember;
import mx.rpc.events.*;
import mx.managers.CursorManager;
import mx.rpc.*;
import mx.rpc.remoting.mxml.RemoteObject;
import flash.events.EventDispatcher;
[Event(name=”result”, type=”mx.rpc.events.ResultEvent”)]
[Event(name=”fault”, type=”mx.rpc.events.FaultEvent”)]
public class BatchService extends EventDispatcher
{
public static const BATCH_GATEWAY_DESTINATION:String=”batchGateway”;
protected var ro:RemoteObject = null;
private var registeredCollections:Array=[];
[collection.changes]
);
batch.push(member);
}
for (i=0; i< registeredCollections.length; i++ ) {
collection = registeredCollections[i].collection as DataCollection;
member = new BatchMember(
collection.destination,
collection.method + “_insertItems”,
[collection.changes]
);
batch.push(member);
}
return batch;
}
collection.resetState();
}
CursorManager.removeBusyCursor();
dispatchEvent(evt);
}
The snapshot of a running OrderEntryDemo is presented in Figure 7.6. A click on the Fill button
populates the Orders panel and the selection of a particular order repopulates OrderItems. When-
ever the data is modified on either panel, the Commit button gets enabled and you can click on it
to save the data changes to simple_order and simple_order_item in one transaction:
OrderEntryDemo Pre-requisites
We’re not going to burden the reader again with the details of preparing DAO, Java, and Action-
Script DTO, etc. Suffice it to say that to get everything in one shot, we process the source code of
package com.theriabook.datasource;
import java.util.List;
/**
* @daoflex:webservice
* pool=jdbc/theriabook
*/
/**
* @daoflex:sql
* sql=select * from simple_order_item WHERE ORDER_ID=:orderId
* transferType=OrderItemDTO[]
* updateTable=simple_order_item
* keyColumns=order_id,item_id,product_name
*/
Listing 7.20 The DAOFlex Java source file for an OrderEntryDemo application
As a result, all classes and JARs are properly deployed, and the only remaining thing to take care of
is that our remoting-service.xml points to a generated destination-include file Order.xml:
messageTypes=”flex.messaging.messages.RemotingMessage”>
<adapters>
<adapter-definition id=”java-object” class=”flex.messaging.services.remoting.
adapters.JavaAdapter” default=”true”/>
</adapters>
<default-channels>
<channel ref=”my-amf”/>
</default-channels>
<destination id=”batchGateway”>
<properties>
<source>com.theriabook.remoting.BatchGateway</source>
</properties>
</destination>
<destination-include file-path=”daoflex/remoting-config/Order.xml” />
</service>
OrderEntryDemo: OrdersPanel
Now let’s look at the details of the application code. The top panel of the application, OrdersPanel,
binds its data grid to the collection, a private variable of the component:
The buttons Add and Remove delegate their work to the orderManager in a clean MVC style:
Finally, whenever the user is changing the row selection, we communicate the selected orderId to
the OrderManager:
ndex != -1}”/>
<mx:Button label=”Add” click=”onAdd(Math.max(0,dg.selectedIndex+1)); “/>
<mx:Label text=”Deleted: {collection.deletedCount}”/>
<mx:Label text=”Modified: {collection.modifiedCount}”/>
</mx:ControlBar>
<mx:Script>
<![CDATA[
import mx.core.Application;
import com.theriabook.collections.DataCollection;
[Bindable]
private var collection:DataCollection;
private var orderManager:OrderManager ;
]]>
</mx:Script>
</mx:Panel>
OrderEntryDemo: OrderItemsPanel
The bottom panel of the application, OrderItemsPanel, populates its data grid with data from a
bindable orderItems collection, hosted by the OrderManager:
orderManager = Application.application.orderManager;
collection = orderManager.orderItems;
}
Similar to the OrdersPanel, the buttons Add and Remove delegate their work to the OrderMan-
ager:
import mx.core.Application;
import com.theriabook.collections.DataCollection;
OrderEntryDemo: OrderManager
A class OrderManager is also important. It encapsulates orders and orderItems collections along
with the methods that manipulate these collections.
The most important things here are the methods that populate collections and communicate the
changes to the server. Populating is rather trivial; we delegate it to the fill() method of the appropri-
ate collection:
orders.fill();
orderItems.fill(orderId);
To send the changes to the server in one transactional batch, we use the BatchService:
How do you determine that changes are pending on a DataCollection? You can use the bind-
able property commitRequired. And what if you have several DataCollections? Please notice the
technique we used to determine if anything needs to be saved on at least one of the DataCollec-
tions:
. . .
orders.addEventListener(
PropertyChangeEvent.PROPERTY_CHANGE, onPropertyChange
);
orderItems.addEventListener(
PropertyChangeEvent.PROPERTY_CHANGE, onPropertyChange
);
. . .
We have covered the most interesting details of OrderManager. The complete code for the Order-
Manager class is in Listing 7.25:
// OrderManager.as
package
{
import flash.events.EventDispatcher;
import mx.events.PropertyChangeEvent;
import mx.rpc.events.FaultEvent;
import mx.controls.Alert;
import com.theriabook.collections.DataCollection;
import com.theriabook.datasource.dto.OrderDTO;
import com.theriabook.datasource.dto.OrderItemDTO;
import com.theriabook.remoting.BatchService;
[Bindable]
public function set orderId(newOrderId:String):void {
_orderId = newOrderId;
fillOrderItems(newOrderId);
}
public function get orderId():String {
return _orderId;
}
batchService.sendBatch(batch);
}
}
}
Conclusion
Flex Remoting, as this chapter illustrates, can be a simplified alternative to Flex Data Services. We didn’t
attempt to provide all the functionality offered by FDS. For example, we didn’t address the data push and
pagination that come free with FDS. And yet, there are distinct advantages to using Flex Remoting:
• Your server’s memory isn’t burdened with persisting identities for each subscribed collection.
• You don’t depend on session replication or, for that matter, any clustering features.
• You have unlimited flexibility in managing your data from the ActionScript side.
Either mechanism, as we have shown in this and previous chapters, requires building a routine set
of Java and ActionScript objects, a process that with an open source DAOFlex generator utility can
be completly automated.
Endnotes
1. Flex Data Services terminology might look a bit confusing. At the architectural level, Flex Data Services
encompass Data Management Services, Remoting Services and Messaging Services. At the API level,
DataService object maps to a Data Management Service, which is only a part of the FDS. This chapter
discusses data management with remoting, which is also a part of FDS. Please be aware that elsewhere in
the chapter, when we refer to Data Services we mean a specific part of the Data Management Service.
2. We mean a request possibly pending for this remote object. Flex accumulates requests in batches; a batch
is sent to the Flex MessageBroker servlet after a cycle of script execution and drawing is complete.
3. To be precise, typing alone is not enough: you need to change the focus from the modified cell to activate
the lower-level event that, eventually, results in CollectionEvent.
5. In all honesty, we can’t credit UpdatableCollection with being completely self-sufficient. At the end of the
day it takes two to tango, and without a server-side DAO class it wouldn’t happen.
6. A Russian doctor and short story author who became a world famous playwrite.
7 . You may suggest that we don’t send the entire list of changes each time. Indeed, the copy of BatchSer-
vice that comes with the book extracts deletes, updates, and inserts separately and sends only what is
required. We omitted these details here for clarity’s sake.
The Flex framework contains a pretty impressive Flex library of off-the-shelf controls, which can fit
the bill for many rich Internet applications needs. Yet, it’s just the tip of the iceberg, because Flex
lets you create, combine, and extend existing components with a simplicity and elegance hardly
ever offered by other GUI development systems.
In this chapter we’re going to lead you step-by-step through the process of extending a standard
ComboBox component, which is a combination of an edit field, button, and dropdown list. We’ll be
customizing the API and adding some new functionality, making our ComboBox a bit handier than
the standard one. In particular, we’ll create a ComboBox with a multi-column dropdown list, then
we’ll create a “destination-aware” ComboBox populated from the server using an RPC call, and
we’ll show you how to implement the autocomplete feature for editable controls.
ComboBox Challenges
A typical task, while working with a standard ComboBox, is to programmatically select a specific
value. Suppose our ComboBox is populated with an array of states:
To programmatically select Texas (in the visible portion of the ComboBox), you can write the
following index-fetching loop, comparing val against the label of each element of the dataPro-
vider:
var val:String;
val = ’Texas’ ;
for (var i: int = 0; i < cbx.dataProdider.length; i++) {
if ( val == cbx_states.dataProvider[i].label) {
cbx_states.selectedIndex = i;
break;
}
}
var val:String;
val = ‘TX’ ;
for (var i: int = 0; i < cbx.dataProdider.length; i++) {
if ( val == cbx.dataProvider[i].data) {
cbx_states.selectedIndex = i;
break;
}
}
Either way these index-fetching loops will clutter the application code instead of the simple
cbx_states.value=‘Texas.’
On top of that, index fetching via data is often unapplicable. Consider real-life ComboBox records
coming from databases, messages, etc. We can’t “mandate” these data sources to contain a data
field in the relevant record sets. And while the standard ComboBox provides a labelField property,
allowing us to draw a label value from an arbitrary property, there’s no dataField property, which
would provide a similar flexibility for data.
So far we’ve identified what we would like to improve in setting the value. Now let’s look at the op-
posite operations. The standard ComboBox offers the properties selectedIndex and selectedItem.
When a ComboBox is populated with strings, selectedItem returns the selected string (or null if
nothing is selected). If it’s populated with objects, selectedItem references the selected object (or
contains null):
</mx:Application>
But wait, there’s also a read-only value property: if a selected object has something in the data
property, the value refers to data, otherwise value refers to the label:
As you can see value does half the job: it gives us “read” access and shields us from selectedItem/
selectedIndex. What we miss is the other half and in the following sections we’ll turn value into a
read-write property. That will forever absolve us from index-fetching loops to modify the Combo-
Box selection.
We’ll also introduce the dataField property to allow any arbitrary property in place of the data,
depending on a specific ComboBox use case.
If the ComboBox.mxml is located under the com/theriabook/controls, it’s test application can look
like Listing 8.3.
Run this application and you’ll see the ComboBox displaying the value New York when we’d expect
Illinois. We forgot about the order in which objects’ properties get initialized. The value property
in our case is initialized before the dataProvider. Then the initialization of dataProvider makes the
first (default) item selected and the work done by our value setter is wasted. You can prove the point
just by trading the places of the value and dataProvider in the application code above.
Should we rely on the order of the attributes in the MXML components? Apparently not. Especially
when Flex offers an excellent mechanism to coordinate the updates to multiple properties of the
control – the commitProperties() method.
Here’s how it works: whenever you need to modify a property, raise some indicator, store the value
in the temporary variable, and call invalidateProperties() as in the following snippet:
In response to invalidateProperties() Flex will schedule a call of commitProperties() for later execu-
tion so that all property changes deferred in the above manner can be consolidated in a single
place and in a pre-determined order:
if (dataProviderDirty) {
super.dataProvider = candidateDataProvider;
dataProviderDirty = false;
}
if (valueDirty) {
applyValue(candidateValue);
valueDirty = false;
}
}
Aside from co-ordinating updates to different properties, this coding pattern helps to avoid mul-
tiple updates to the same property and, in general, allows setter methods to return faster, improv-
ing the overall performance of the control. The entire code of our “value-aware” ComboBox is pre-
sented in Listing 8.4:
}
override public function set dataProvider(value:Object):void {
candidateDataProvider = value;
dataProviderDirty = true;
invalidateProperties();
}
if (dataProviderDirty) {
super.dataProvider = candidateDataProvider;
dataProviderDirty = false;
}
if (valueDirty) {
applyValue(candidateValue);
valueDirty = false;
}
}
]]>
</mx:Script>
</mx:ComboBox>
Now everything works as expected. The screenshot of the running application is presented in Fig-
ure 8.1.
If you change the ComboBox selection, the top label, which initially contains a current bound val-
ue, is “IL” and will change accordingly. No miracles here, a regular Flex data binding, one would say.
Indeed, good things are easy to take for granted. Still, we haven’t provided any binding declarations
or binding code in our ComboBox. So why does it work? It works because the original Flex defi-
nition of the value getter ComboBox has already been marked with a metadata tag [“Bindable”],
which makes the property bindable (you don’t have to have a setter to be bindable):
[Bindable(“change”)]
[Bindable(“valueCommitted”)]
But wait, you may say, these binding definitions indicate that data modifications bound to the
value property get triggered in response to change or valueCommitted events. Yet our value set-
ter doesn’t contain a single dispatchEvent call. What’s the catch? Events are dispatched inside the
code that assigns a selectedIndex. This assignment results in invoking a selectedIndex setter, which
ultimately dispatches the events.
<mx:Application xmlns:mx=http://www.adobe.com/2006/mxml
xmlns:lib=”com.theriabook.controls.*”>
. . . . . . . .
<lib:ComboBox id=”cbx_1” width=”150” value=”123” labelField=”state_name”
dataField=”state_code” dataProvider=”{comboData}”/>
</mx:Application>
To do this, we’ll start by adding a public variable dataField to our ComboBox that by default will
store the same value as in the data property:
Next, we’ll modify the applyValue() to do the data comparison of the dataField and the labelField,
instead of directly operating on the data and label properties:
val== dataProvider[i][labelField]) {
selectedIndex = i;
return;
}
}
}
selectedIndex = -1;
}
This time we also have to override the default value getter to recognize the newly introduced
dataField similar to the setter:
When overriding system properties you should take care of the metadata as well. As long as we were
only responsible for the setter, we could have relied on the metadata bindings coming through the
standard getter in the ancestor class. Now that we’ve overridden the getter as well, we’re on our own.
The following lines should be added in front of either the getter or setter for the value property:
[Bindable(“change”)]
[Bindable(“valueCommitted”)]
[Inspectable(defaultValue=”0”, category=”General”, verbose=”1”)]
The complete listing for the customized ComboBox with the new dataField property is presented
in Listing 8.5:
[Bindable(“change”)]
[Bindable(“valueCommit”)]
if (dataProviderDirty) {
super.dataProvider = candidateDataProvider;
dataProviderDirty = false;
}
if (valueDirty) {
applyValue(candidateValue);
valueDirty = false;
}
}
]]>
</mx:Script>
</mx:ComboBox>
The test application code is presented in Listing 8.6. Now you can map any business object’s prop-
erties (regardless of what their names are) while declaring the new version of the ComboBox, which
will give you extra flexibility.
Flex creators envisioned that most of the application-specific richness should come from appli-
cation developers. In particular, while on the surface the standard ComboBox still resembles its
HTML counterpart, an elegant Flex mechanism of custom item renderers lets us turn the boring
single-column dropdown into a fancy multi-column one. We have to mention that it can also im-
plement the multi-column ComboBox without resorting to an explicit item renderer. Please see
MultiColumnComboBoxDropDownFactoryDemo.mxml in the samples that come with the book.
This sample is based on the dropdownFactory property of the ComboBox:
Flex item renderers go inline with the best traditions of Macintosh, OS/2, and Windows presenta-
tion engines, where similar mechanisms were known as an “owner draw” painting. Specifically,
item renderer lets us modify the look-and-feel of items in any list-based control, such as DataGrid,
List, Tree, etc. The dropdown portion of the ComboBox is nothing but the List. Hence we’e going to
build a renderer that will show four columns with controlled widths, separated with vertical lines,
as shown in Figure 8.2.
First, though, we’ll modify the data used to populate the ComboBox. So far we’ve been working with
a collection of U.S. states, each element of the collection being a name-code value pair. Now we’ll
change the comboData collection into an array of four-field objects containing emp_id, fname,
lname, and phone:
The data is ready, and we proceed to the renderer. One way of packaging the item renderer is to
create a special ActionScript class or MXML component file. Alternatively, Flex provides a way to
define a nested MXML component with an <mx:Component> tag. To simplify our example we’ll
go with such an inline renderer; although we were looking for unlimited reusability we’d certainly
select the dedicated file, aka drop-in renderer.
Below is the definition of our inline renderer. We start with the Component tag, which carries spe-
cific scoping arrangements. Most importantly, the property data in the scope of the inline renderer
references the element of the dataProvider that corresponds to the relevant item of the list. (On
par with data there’s another property – outerDocument – that references the same scope that our
ComboBox is within).
The inline component includes an HBox containing four Labels, a separating VRule between each
column, and a PhoneFormatter to format the phone number with a default phone format. We split
the width of the dropdown list between our columns as 10%, 35%, 35%, and 20%. We’ll just set the
height of the HBox to 20 pixels to accommodate the size of the default font. To avoid individual
scrollbars in each cell of the list we turn off both the horizontal and vertical scroll policy styles:
<mx:Component
<mx:HBox horizontalScrollPolicy=”off” verticalScrollPolicy=”off” height=”20”>
<mx:PhoneFormatter id=”phoneFormatter”/>
<mx:Label text=”{data.emp_id}” width=”10%”/><mx:VRule />
<mx:Label text=”{data.fname}” width=”35%”/><mx:VRule />
<mx:Label text=”{data.lname}” width=”35%”/><mx:VRule />
<mx:Label text=”{phoneFormatter.format(data.phone)}” width=”20%”/>
</mx:HBox>
</mx:Component>
For a standard ComboBox to actually inline an item renderer we’d have to write:
However, our case is a bit more complicated because we reference the custom ComboBox through
a different namespace prefixed with lib. Accordingly, to avoid the compiler error “Could not resolve
<mx:itemRenderer> to component implementation,” we’ll prefix the itemRender with lib as well:
</lib:itemRenderer>
</lib:ComboBox>
Let’s set the width of the dropdown list to 350 pixels to accommodate the total width of the four
columns:
MXML creators gave us a handy dropdownWidth property. There is also the ability to decorate a
dropdown list with CSS styles. To avoid gaps between two adjacent vertical VRule lines we set the
CSS vertical padding to zero:
<mx:Style>
.noVerticalPadding{padding-top:0;padding-bottom:0}
</mx:Style>
<lib:ComboBox id=”cbx_1” value=”102” width=”150”
dropdownWidth=”350” dropDownStyleName=”noVerticalPadding”
dataProvider=”{comboData}” labelField=”lname” dataField=”emp_id”>
We’ll be using the RemoteObject tag to communicate with the server-side Java classes (we went
through this excersise in the Stock Portfolio example in Chapter 5). The RemoteObject enables
asynchronous calls to a Java class as long as this class can be found by the Web application. Here’s
the snippet of the MXML application where we declare the service: an instance of the RemoteOb-
ject. The implementation of the Java method getEmployees is shown in Listing 8.8.
<mx:RemoteObject id=”service”
destination=”com_theriabook_composition_EmployeeDAO”
result=”onServiceDataReady(event)” showBusyCursor=”true”
fault=”onServiceFault(event)”>
<mx:method name=”getEmployees” />
</mx:RemoteObject>
The name of the server destination looks like the fully qualified Java class name, where the dots
are replaced by underscores. Actually, you shouldn’t use this naming style in your projects since it
discloses the internal structure of your server-side code. We use such a naming convention in this
book just to help you understand what Java’s counterpart MXML uses.
You don’t have to enumerate remote functions via the method MXML tags, although these tags let
you reconfigure properties such as result, fault, and showBusyCursor on a per-method basis. We’ll
get to these properties a bit later.
A RemoteObject facilitates calls to the Java class mapped through a configurable server-side des-
tination. Assuming the default setup, all remoting destinations should be listed as children of the
services node of the remoting-config.xml, located inside the WEB-INF/flex folder of our Web appli-
cation. Here’s the relevant fragment of the remoting-config.xml that maps our logical destination
to the physical Java class:
<destination id=”com_theriabook_composition_EmployeeDAO”>
<properties>
<source>com.theriabook.composition.EmployeeDAO</source>
</properties>
</destination>
Listing 8.8 shows the com.theriabook.composition.EmployeeDAO.java, the class that our service
remotes to. It uses two utility classes (the source code is available for download): JDBCConnec-
tion, which isolates us from connecting to the datasource and the unchecked DAOException. This
sample assumes that you’ve configured the JDBC data source called jdbc/theriabook on the Java EE
application server.
package com.theriabook.composition;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import com.theriabook.composition.to.EmployeeDTO;
import com.theriabook.daoflex.DAOException;
import com.theriabook.daoflex.DateTimeConversion;
import com.theriabook.daoflex.JDBCConnection;
Java programmers may not like the fact that we named the non-final variables in capital letters, but
this is done to simplify the mapping between these variables and the database column names used
later in this book.
The method getEmployees() returns an array of Java objects shown in Listing 8.9.
package com.theriabook.composition.dto;
public class EmployeeDTO
{
public int EMP_ID;
public String EMP_FNAME;
public String EMP_LNAME;
//. . . . . . . .
public String SEX;
public EmployeeDTO()
{
}
Here’s an interesting situation: a RemoteObject can’t deliver Java objects to the Flash Player, so Flex
will marshall Java EmployeeDTO objects into the matching ActionScript objects. The best practice
– both performance- and usability-wise – is to have ActionScript packages and classes match their
Java counterparts. Otherwise, the incoming data will be un-marshalled into anonymous Objects.
(Flex documentation describes this under the topic Type-to-Type Mapping.)
But declaring the ActionScript class matching its Java counterpart property by property is only half
the deal. The second half of successful Java/ActionScript marshalling is to register the class with
the marshalling mechanism. The Flex ActionScript compiler facilitates this registration with a Re-
moteClass metadata directive:
package com.theriabook.composition.dto
{
[RemoteClass(alias=”com.theriabook.composition.dto.EmployeeDTO”)]
public dynamic class EmployeeDTO
{
public var EMP_ID : Number;
}
}
Flex does lookup among the registered classes when Java objects come from the server. The class
name of the Java object is used as a key to find the registered ActionScript class to deserialize to.
Conversely, when data is sent to the server, Flex carries the information of the Java class – alias – to
create proper objects on the server side.
In the MXML declaration of the RemoteObject service, we have to provide event handlers for the
result, which is dispatched when the method returns successfully, and for the fault, which is dis-
patched when something goes wrong. As a reminder, both events are asynchronous:
To process result we add the function called onServiceDataReady. This function makes use of the C#-
style typecasting introduced in ActionsScript 3 – A as B. The ActionScript compiler wouldn’t let us get
away with the following line because the type on the left isn’t compatible with the type on the right:
we’d end up converting whatever comes through event.result into an array. The outcome of such a
conversion would be a brand new array with one element containing whatever came with the event.
result. The as casting to the rescue!1 Now we request an explicit casting instead of conversion.
Finally, somewhere in our application we have to invoke getEmployees(). Let’s do it right before the
application’s screen becomes visible, that’s during the processing of the application’s creationCom-
plete event:
[Bindable]
public var employeeCollection:ArrayCollection;
public function onCreationComplete():void {
service.getEmployees();
}
</mx:Application>
Listing 8.12 The code that populates the Combobox from a database
Hurray! Our application is running. Remote Java classes are sending us data on demand. Don’t you
feel good? Well, we don’t want to ruin the party, but the Java-to-ActionScript marshalling didn’t
work as expected. Not that the marshalling didn’t happen at all, but despite all of our meticulous
efforts, EmployeeDTO Java classes were converted into anonymous ActionScript Objects.
When we discussed marshaling Java EmployeeDTO into its EmployeeDTO.as counterpart, we made
an assumption that class EmployeeDTO.as is available during runtime.2 The truth is, while compil-
ing and linking our application into the SWF file, Flex had no reason to believe that this class has
to be included in the SWF, because there’s no direct use of a variable of this class in the entire ap-
plication, including implementing the ComboBox. We’ll cover class loading in more detail later in
the book, but for now, let’s just fool the Flex compiler by having a variable declaration somewhere
in the application:
That will do the job and the marshalling will indeed consider the Employee DTO.as class.
Such collections are self-sufficient, they don’t need external controllers and, at the end of the day,
this technique allows you to avoid writing and maintaining mundane code that’s not needed in the
first place.
So is the story with ComboBoxes, because as far as application partitioning goes, there’s a com-
pelling argument to encapsulate instantiation and interoperation with the RemoteObject inside
the visual component, making it a destination-aware one. In this section we’ll demonstrate a
technique for embedding the RemoteObject directly into the ComboBox, which will make our
“Employees ComboBox” fully autonomous and reusable. The following snippet illustrates the
suggested usage pattern of the ComboBox we’re going to make.
<lib:ComboBox id=”cbx_1”
width=”150” dropdownWidth=”350”
labelField=”EMP_LNAME” dataField=”EMP_ID”
destination=”com_theriabook_composition_EmployeeDAO”
method=”getEmployees” creationComplete=”cbx_1.fill()”
/>
This design approach sets application business logic free from low-level details like mundane re-
moting.
Now, you might be worried about our adherence to sacred architectural pillars like separation of
presentation from data, MVC, etc. Let us assure you, MVC is fully preserved, the only change being
that the mix of M, V, and C has been delegated from the application to the component level.
We’ll start by adding two more properties to our ComboBox control – destination and method. We’ll
declare them public so they can be accessed from the outside, and, in particular, at the MXML
level:
We’ll also embed a reference to a RemoteObject instance – ro – and declare a fill() method that cre-
ates (if not created earlier) a real instance of the RemoteObject:
Proceeding with the fill() method, we set the concurrency of the RemoteObject to last (similar to
what we did in Chapter 5, and we’ll cover more on this later in this chapter) and associate the event
listener functions with the result and fault events.
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
Now, suppose ro has been created. How can we call our dynamic method? In a typical scenario,
the following two lines would do the job (the method apply() is equivalent to Java reflection’s
invoke():
However, our ro is an instance of RemoteObject and so it has the method getOperation(), which
accepts the name of the operation as its argument and returns an instance of mx.rpc.AbstractOper-
ation. Conveniently, the AbstractOperation’s send() method assumes the value of the arguments
property as the parameters:
(Check the Flex MXML and ActionScript Language Reference to get more familiar with mx.rpc.
AbstractOperation.)
ro = new RemoteObject(destination);
ro.showBusyCursor = true;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
}
// In a simple scenario,to dynamically invoke a method on ro:
//var functionObject:Function = ro[method];
//functionObject.apply(ro, args);
Another method called ro_onResult() updates the ComboBox’s dataProvider with a brand new re-
sult set when it’s ready:
Having all this code in place, we can further modify the definition of the ComboBox to the follow-
ing:
To sanitize the application code, let’s remove the references to RemoteObject from our sample ap-
plication. In Listing 8.14, the data population is simply handled by calling cbx_1.fill() from within
the ComboBox’s event handler creationComplete.
[Bindable(“change”)]
[Bindable(“valueCommit”)]
[Inspectable(defaultValue=”0”, category=”General”, verbose=”1”)]
override public function get value() : Object {
var item:Object = selectedItem;
if (item == null || typeof(item) != “object”) return item;
return item[dataField] ? item[dataField] : item.label;
}
if (dataProviderDirty) {
super.dataProvider = candidateDataProvider;
dataProviderDirty = false;
}
if (valueDirty) {
applyValue(candidateValue);
valueDirty = false;
}
}
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.AbstractOperation;
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
import mx.managers.CursorManager;
import mx.collections.ArrayCollection;
ro = new RemoteObject(destination);
ro.showBusyCursor = true;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
}
var operation:AbstractOperation = ro.getOperation(method);
operation.arguments = args;
operation.send();
}
private function ro_onFault(evt:FaultEvent):void {
CursorManager.removeBusyCursor();
Alert.show(“Failed retrieving data: “+evt.message, “[DestinationAwareComboBox]”
+ id);
}
]]>
</mx:Script>
</mx:ComboBox>
The autocomplete requirements can be adjusted according to the needs of a particular business
application. Take, for instance, a customer account search. You may want to defer a search until at
least the first three characters of the account are entered, etc.
Before we venture to improve the ComboBox, or to be more accurate, a TextInput child of the Combo-
Box, we’ll pilot autocompletion functionality on a plain TextInput control. Similarly, before we get to
search the remote database records, let’s practice searching against some local ArrayCollection.
We’re going to create an application containing two controls: TextInput inp_1 and List list_1. We’ll
use a vertical layout so that our TextInput is positioned above the List:
Listing 8.16 Code for a client with TextInput and List controls
Here’s our goal: whenever a user modifies the inp_1 field, a matching value from the list_1, if any,
jumps into inp_1. And when this happens, the predicted part of that value should be highlighted.
Thereafter the first user keystroke will replace the selection and the whole process starts all over.
Figure 8.5 shows a screenshot of the pilot application we’re going to develop.
Let’s get the ball rolling by intercepting all interactive changes to a TextInput via its change event:
The autocomplete() function can scan the objects in the dataProvider until it finds a string that
starts with the inp_1.text. If so, the TextOnput field inp_1 should be updated with the string and the
remaining portion of the string should be highlighted:
The only drawback to this approach is that, since autocomplete() is a handler of change event, the
selection we apply to inp_1 will get dismissed by default processing on the return from autocom-
plete(). The delayed rendering causes that. One working solution to alleviate this situation is to
defer the text selection through the setTimeout() function. As a reminder, the first parameter of the
setTimeout() is a reference to a function object to be called, the second parameter is the timeout
when you want the call to happen, while the rest are, well, the rest-style parameters of the function.
In our case, the first parameter is the nested function select():
setTimeout(
function select(fromChar:int, toChar:int):void {
inp_1.setSelection(fromChar, toChar);
}, 50, typedLenth, inp_1.text.length );
inp_1.text = list_1.dataProvider[i];
setTimeout(
function select(fromChar:int, toChar:int):void {
inp_1.setSelection(fromChar, toChar);
},50, typedLenth, inp_1.text.length);
break;
}
}
}
Finally, we’ll take care of the BackSpace button. The user may be annoyed if, after hitting the Back-
Space button, the autocomplete restores the value instead of letting her type a different ending.
Let’s add the processing to the keyDown event on inp_1 so that we’ll know if the last key was the
BackSpace. The full listing of our example is presented in Listing 8.19.
if (lastKeyBackspace) {
lastKeyBackspace = false;
return;
}
},
50, typedLenth, inp_1.text.length
);
break;
}
}
}
]]>
</mx:Script>
<mx:TextInput id=”inp_1” change=”autocomplete(inp_1.text)” keyDown=”onKeyDown(event
)”/>
<mx:List id=”list_1” width=”180”>
<mx:dataProvider>
<mx:Array>
<mx:String>Apple</mx:String>
<mx:String>Application</mx:String>
<mx:String>Sign</mx:String>
<mx:String>Signature</mx:String>
<mx:String>Singleton</mx:String>
</mx:Array>
</mx:dataProvider>
</mx:List>
</mx:Application>
Let’s start with Java. Earlier in this chapter we implemented the method getEmployees() in the Em-
ployeeDAO class (see Listing 8.8). Now we will add one more method getEmployeesByName() as
shown in Listing 8.20:
package com.theriabook.composition;
import . . .
{
public EmployeeDAO()
{
}
public final EmployeeDTO[] getEmployees()
{
. . . .
}
public final EmployeeDTO[] getEmployeesByName(String namePart)
{
String sql = “select * from EMPLOYEE where emp_lname like ?”;
EmployeeDTO[] result = null;
ArrayList list = new ArrayList();
PreparedStatement stmt = null;
ResultSet rs = null;
Connection conn = null;
try
{
conn = JDBCConnection.getConnection(“jdbc/theriabook”);
stmt = conn.prepareStatement(sql);
stmt.setString(1, namePart);
rs = stmt.executeQuery();
while( rs.next() ){
EmployeeDTO to = new EmployeeDTO();
to.EMP_ID = (rs.getInt(1));
to.EMP_FNAME = (rs.getString(3));
to.EMP_LNAME = (rs.getString(4));
. . . . .
to.SEX = (rs.getString(20));
list.add(to);
}
result = new EmployeeDTO[list.size()];
result = (EmployeeDTO[])list.toArray(result);
return result;
}
}
We’re done with the Java part. Now, let’s find out how the standard ComboBox control is processing
change events for its TextInput child component and modify this routine.
We’ll do something like Sherlock Holmes did at the end of each solved case. He’d explain to Dr.
Watson how he solved the mystery.
Flex 2.0 comes with source code and we found the class ComboBox.as and its ancestor – Combo-
Base.as – inside the folder frameworks\source\mx\controls. The easiest way to find the location
of the event-handling code is to search for “addEventListener” in these two files. Here’s what we’ve
found in ComboBase.as:
. . . . . .
public var textInput:TextInput;
public var downArrowButton:Button;
protected function textInput_changeHandler(event:Event):void
. . . . . .
override protected function createChildren():void
{
super.createChildren();
// Create the border first, in the back.
. . . . . .
// Next, create the downArrowButton before creating the textInput,
// because it can be as large as the entire control.
if (!downArrowButton) {
downArrowButton = new Button();
. . . . . .
addChild(downArrowButton);
downArrowButton.addEventListener(
FlexEvent.BUTTON_DOWN, downArrowButton_buttonDownHandler
);
}
// Create the textInput on top.
if (!textInput)
{
textInput = new TextInput();
textInput.editable = _editable;
. . . . . . .
addChild(textInput);
textInput.addEventListener(Event.CHANGE, textInput_changeHandler);
. . . . . .
}
}
Do you know what real happiness is for a component developer? Are you ready to learn? Okay,
we’ll share it with you. The pinnacle of happiness for a component developer is finding out that
the function he wants to enhance wasn’t declared private in the ancestor class. Yes! The textIn-
put_changeHandler was declared protected. So in our ComboBox, we could simply override the
handler in the following manner:
“Elementary, my dear Watson!” In fact, the line doesn’t appear in the Conan Doyle books, only in
Sherlock Holmes movies.
Please note that the only argument of fill() is the text + “%” expression, where text is the ComboB-
ox’s property that contains, well, the text, as the user typed it in the editable portion of the Combo-
Box. As per the implementation of getEmployeesByName(String partName), its argument is used to
prepare the query select * from EMPLOYEE where emp_lname like ?. This query will bring us all the
data that start with the specified text, if any.
Now we can implement the autocomplete() similar to our pilot example in the previous section.
There’s one important distinction though. In our pilot example the dataProvider was a collection of
strings. Now that we’re dealing with a collection of objects, several scenarios are equally possible:
How do we get the true label? Or, to put it differently, how do we know what should be considered a
label by the ComboBox? Praise the Flex creators again, because there’s a convenient public method
itemToLabel() that covers all the scenarios. Check with the Flex documentation (see Adobe Flex 2
ActionScript and MXML Language Reference) about the exact order of preferences implemented
by itemToLabel(). Meanwhile we’re going to use it for our benefit here:
But wait, the RPC calls that are hitting the database are expensive, aren’t they? Suppose a user types
really fast. Shouldn’t we skip the RPC between two fast keystrokes? One way to minimize the num-
ber of RPCs is to wait and issue a call after, say, 300 milliseconds via a setTimeout():
var timer:uint = 0;
override public function textInput_changeHandler(event:Event):void
{
super.textInput_changeHandler(event);
But if an RPC is expensive why add an extra 300 milliseconds on top of an already slow operation?
Shouldn’t we just issue the RPC requests as soon as possible? Quite a dilemma, isn’t it? The answer
depends on the network configuration and the threading limitation of your servers.
Another important point is in setting the concurrency property of the Remote Object method to
last. Its default value is multiple, and it allows as many invocations on the server side as there are
incoming requests. But the value last asserts that any new RPC request will cancel the ones that are
in progress or haven’t been started. This is exactly what we need because we don’t need to process
outdated requests. And since our implementation of fill() method is using last, it will guarantee
that the outdated result set will be disregarded. You may need to tune the timeout based on the
network and threading capacity of Java EE server.
Here’s the sample application to test our ComboBox. Note that in this application we’ve turned the
ComboBox editable property to true:
<mx:PhoneFormatter id=”phoneFormatter”/>
<mx:Label text=”{data.EMP_ID}” width=”10%”/><mx:VRule />
<mx:Label text=”{data.EMP_FNAME}” width=”35%”/><mx:VRule />
<mx:Label text=”{data.EMP_LNAME}” width=”35%”/><mx:VRule />
<mx:Label text=”{phoneFormatter.format(data.PHONE)}” width=”20%”/>
</mx:HBox>
</mx:Component>
</lib:itemRenderer>
</lib:ComboBox>
</mx:Application>
The complete code of our destination-aware ComboBox with autocomplete and dataField support
is presented below:
[Bindable(“change”)]
[Bindable(“valueCommit”)]
[Inspectable(defaultValue=”0”, category=”General”, verbose=”1”)]
override public function get value() : Object {
var item:Object = selectedItem;
if (item == null || typeof(item) != “object”) return item;
return item[dataField] ? item[dataField] : item.label;
}
return;
} } }
selectedIndex = -1;
}
if (dataProviderDirty) {
super.dataProvider = candidateDataProvider;
dataProviderDirty = false;
}
if (valueDirty) {
applyValue(candidateValue);
valueDirty = false;
}
}
autoComplete(text);
if (lastKeyBackspace) {
lastKeyBackspace = false;
return;
}
}
private function autoComplete(txt:String):void{
var textLength:int = txt.length;
for (var i : int = 0; i < dataProvider.length; i++) {
var label:String = itemToLabel(dataProvider[i]);
if ( label.substr(0, textLength).toLowerCase() == txt.toLowerCase() ) {
textInput.text = label;
setTimeout(
function select(fromChar:int, toChar:int):void {
textInput.setSelection(fromChar, toChar);
},
50, textLength, textInput.text.length);
break;
} }
}
import mx.controls.Alert;
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
ro = new RemoteObject(destination);
ro.destination = destination;
ro.showBusyCursor = true;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
}
autoComplete(txt);
}
]]>
</mx:Script>
</mx:ComboBox>
We’re going to offer two solutions here. The first solution will be to build a business-specific Em-
ployeeComboBox as an extension of the ComboBox with extra properties containing a remote des-
tination and method. The second solution will be to encapsulate these extra properties in a sepa-
rate resource class and have our generic ComboBox point to resource instances when the design
choice is referred to as an “is” versus “has” pattern.
Listing 8.24 is a reprint of the AutoCompleteComboBoxDemo, Listing 8.22, with some lines printed
in bold.
</lib:itemRenderer>
</lib:ComboBox>
</mx:Application>
To illustrate the first solution we’ll encapsulate all the lines, except the bold ones, inside the new
ActionScript class EmployeeComboBox. For the second solution, we’ll encapsulate these lines in-
side the EmployeeComboBoxResource and modify our custom ComboBox from Listing 8.24 to rec-
ognize such resource classes.
Under the first scenario, our application is going to get simplified to this one:
Alternatively, under the second scenario, our application will look like:
<lib:ComboBox xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:lib=”com.theriabook.controls.*”
labelField=”EMP_LNAME” dataField=”EMP_ID”
destination=”com_theriabook_composition_EmployeeDAO”
method=”getEmployeesByName”
. . . . .
</lib:ComboBox>
The itemRenderer of the EmployeeComboBox is the one-to-one copy of the inline implementation
we had before:
ComboBox xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns=”com.theriabook.controls.*”
. . . . . .
>
<itemRenderer>
<mx:Component >
<mx:HBox height=”20” horizontalScrollPolicy=”off” verticalScrollPolicy=”off”
>
<mx:PhoneFormatter id=”phoneFormatter”/>
<mx:Label text=”{data.EMP_ID}” width=”10%”/><mx:VRule />
<mx:Label text=”{data.EMP_FNAME}” width=”35%”/><mx:VRule />
<mx:Label text=”{data.EMP_LNAME}” width=”35%”/><mx:VRule />
<mx:Label text=”{phoneFormatter.format(data.PHONE)}” width=”20%”/>
</mx:HBox>
</mx:Component>
</itemRenderer>
. . . . . . .
</ComboBox>
The style trick, which helped us create a vertical grid with VRules, has moved inside EmployeeCom-
boBox and so has the declaration of a linkage variable that we used to force EmployeeDTO to be
included in the generated SWF:
</mx:Script>
</CompleteComboBox>
This illustrates the resource separation technique based on the control extension (“is”). The second
solution (“has”), based on the dedicated resource classes, is covered in a following section.
different modules. It helps isolate developers working on screen prototyping from the implementa-
tion details of the database communications. It simplifies solutions that are based on dynamically
changing the component’s functionality and presentation during the runtime. And it paves the way
for building systems that allow on-demand loading of business-driven metadata repositories.
Let’s start with the definition of the base class for all the ComboBox resources. This class will be
extended by EmployeeComboBoxResource and other ComboBox resource classes alike:
package com.theriabook.resources {
import mx.core;
public class ComboBoxResource {
public var dataField : String = null;
public var destination:String=null;
public var dropdownWidth : int = 0;
public var editable:Boolean = false;
public var itemRenderer:IFactory = null;
public var labelFunction : Function = null;
public var method : String = null;
];
//Code to be shared by all instances of the resource
. . . . . .
}
}
As you can see from Listing 8.26, the EmployeeComboBoxResource relies on the compiler mapping
the MXML attributes dataField, destination, method, editable, and dropdownWidth to the match-
ing public variables of the underlying class ComboBoxResource:
. . . . . . .
</ComboBoxResource>
Similarly, the value of the itemRenderer variable in the EmployeeComboBoxResource will be set to
the class factory of the inline component based on the HBox:
We’re going to do some more work with both ComboBoxResource and EmployeeComboBoxRe-
source classes a bit later. For now, let’s put the resource classes to work as they are. Let’s add a
new property – resource with setter and getter – to our custom ComboBox. The setter, given the
resource class name, creates an instance of this object and copies its properties into this object of
the ComboBox. For brevity’s sake, we’ll show only the part of the ComboBox listing relevant to the
resource:
if (instance[props[i]] != null) {
this[props[i]] = instance[props[i]];
}
}
Now we can run the application using the new resource property.
To complete the ComboBoxResource we’ll emulate the vertical grid with our VRules by creating
and using a style that eliminates vertical padding. In the above code snippet, we’ve referred to this
style as the comboBoxResourceDropDownStyle. Although it’s possible to declare this style through
a document-wide stylesheet or via the default stylesheet used by the compiler, we’re going to cre-
ate and initialize this style in the constructor of the ComboBoxResource. We’ll be checking for the
existence of the style in the global StyleManager, since the style could have already been created by
another call to the same constructor (if not created through the global or default stylesheet):
package com.theriabook.resources {
import mx.core.IFactory;
import mx.core.UIComponent;
import mx.styles.CSSStyleDeclaration;
import mx.styles.StyleManager;
And finally, let’s make one more modification to the EmployeeComboBoxResource class. We’ll make
it carry functions, in particular – the implementation of the labelFunction, which was included in
the class on purpose. The full listing of the EmployeeComboBox is presented below:
<mx:HBox height=”20”
horizontalScrollPolicy=”off” verticalScrollPolicy=”off” >
<mx:PhoneFormatter id=”phoneFormatter”/>
<mx:Label text=”{data.EMP_LNAME}” width=”40%”/><mx:VRule/>
<mx:Label text=”{data.EMP_FNAME}” width=”40%”/><mx:VRule />
<mx:Label text=”{phoneFormatter.format(data.PHONE)}” width=”20%”/>
</mx:HBox>
</mx:Component>
</itemRenderer>
<mx:Script>
<![CDATA[
import com.theriabook.composition.dto.*;
private var linkage:EmployeeDTO;
private function fullName(data:Object):String {
return data.EMP_LNAME + “,” + data.EMP_FNAME;
}
]]>
</mx:Script>
</ComboBoxResource>
This change will affect all the screens using this resource without needing to modify each and every
use case. Unlike the direct classes, like EmployeeComboBox, the resources don’t need to be linked
with the modules that use them, making development by a team of programmers much easier. And
it shows that the resources are full-blown classes, letting you mix data, presentation, and script.
This concludes the illustration of the resource-classes technique. Arguably, this is a much cleaner
way to separate code from metadata: you modify the resource property on the ComboBox to a
CustomerComboBoxResource of your own and – voila! – you can search customers instead of em-
ployees using the same code.
In industrial-scale systems spanning a set of Flex projects, it makes sense to maintain the resources
as well as the reusable components in shared runtime libraries. We’ll cover the topic of creating,
loading, and using such libraries in Chapter 10.
Summary
In this chapter we went through several practical examples of customizing a Flex component,
namely ComboBox.3 Such customization has several benefits:
• Your productivity increases as you create components that can be reused in multiple projects.
• Commonly used components can help you divide your application into distinct modules.
• The functionality of Flex controls can be substantially enhanced.
• The new breed of destination-aware components can in some cases literally provide drag-
and-drop programming of Web applications. You drop a component on the screen that not
only knows on which remote server its data resides, but also arrives on your Web browser pre-
populated with data.
The Flex component model lets you extend visual and non-visual components as you see fit.
Endnotes
1. A major difference between the two ways of casting is not highlighted here, but is worth mentioning
anyway: if an object you are trying to cast a traditional way is not matching the target type, you will get a
runtime exception; under the same scenario as casting will return null.
2. Strictly speaking Flash Player operates with class definitions that get loaded into application domains;
here we are discussing the presence of the definition of EmployeeDTO.as in the main application domain.
3. Please be aware that as of Chapter 8 we have not made sure that the ComboBox will work well as a ren-
derer in the List-based controls. The complete version would require overriding the setter for the data
property. The adequate ComboBox code can be found inside /TheRiaBook/code/flex/theriabook folder of
the DVD that comes with the book.
In Chapter 3, we introduced the Flex Tree control in a very simplistic scenario. It’s time to switch
gears and slowly push the accelerator pedal to the floor.
What comes to mind when you have to represent a hierarchical data structure, but forgot every-
thing you learned in your college Data Structures class? XML, of course. Let’s build a simple tree
based on a static XML file of U.S. states and cities.
<?xml version=”1.0”?>
<!-- PlainXmlTreeDemo.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:Tree id=”tree1” labelField=”@label” showRoot=”false”
width=”160”>
<mx:dataProvider>
<mx:XML format=”e4x”>
<states>
<state label=”California” data=”CA” isBranch=”true”/>
<state label=”Pennsylvania” data=”PA”>
<city label=”Philadelphia” population=”1479339” />
</state>
<state label=”Arizona” data=”AZ” isBranch=”true”/>
<state label=”Texas” data=”TX” />
<state label=”Illinois” data=”IL” />
<state label=»New York» data=»NY» />
</states>
</mx:XML>
</mx:dataProvider>
</mx:Tree>
</mx:Application>
The Tree control gets its data from a hierarchical data provider. Since the dataProvider property of
the control is implemented as a setter function, there’s a lot of flexibility in what we can assign. In
particular, instead of the E4X XML object (above) we could have assigned a string with a valid XML
text, XMLList, XMLListCollection, or any object that could be interpreted as a hierarchical data
provider according to the rules of the ITreeDataDescriptor interface.
In Listing 9.1, only the Pennsylvania <state> node has a real child – the <city> of Philadelphia.
But if you look at Figure 9.1, you’ll notice that California and Arizona are also folder nodes. We’ve
achieved this effect by using the node attribute isBranch=”true.” Similarly, if for any reason you
don’t want to process a particular branch of the tree, explicitly set isBranch=“false” and the child
nodes will be ignored.
Each node in our XML contains an attribute “label” that is supposed to be displayed as a value of
the tree node. Had it been an array of objects, each containing a label property, Tree controls could
readily act on that. However, we’re dealing with XML and because of that we have to explicitly
specify via the labelField property of the Tree control that our labels are stored as attributes:
labelField=”@label”
Why? The attribute “label” and the child node <label> are equally good choices (and that’s just for
starters because we could have had a child node <name> with the attribute “label”, etc.). How on
earth does the Tree control know the location of the label? It doesn’t, until we intervene.
Another specific of XML data sources is that they always have a root node. If you don’t want to dis-
play the root node, just set the showRoot property to false.
Our next example will use an Array as a data provider. Note that we don’t need to set a
showRoot=”false” here. We also don’t have to explicitly declare a labelField= “label” because the
label attribute is assumed by default.
In the next example we’ll use nested arrays of ActionScript objects to populate the tree. A default
implementation of ITreeDataDescriptor interface – DefaultDataDescriptor – interprets the children
property as a repository of the branch nodes. With MXML we can lay out sub-node arrays with an
mx:children tag:
<?xml version=”1.0”?>
<!-- PlainArrayTreeDemo.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:Tree id=”tree1” width=”160”>
<mx:dataProvider>
<mx:Array>
<mx:Object label=”California” data=”CA” >
<mx:children><mx:Array/></mx:children>
</mx:Object>
<mx:Object label=”Arizona” data=”AZ” >
<mx:children><mx:Array/></mx:children>
</mx:Object>
<mx:Object label=”Pennsylvania” data=”PA”>
<mx:children>
<mx:Object label=”Philadelphia” population=”1479339” />
</mx:children>
</mx:Object>
<mx:Object label=”Texas” data=”TX” />
<mx:Object label=”Illinois” data=”IL” />
<mx:Object label=»New York» data=»NY» />
</mx:Array>
</mx:dataProvider>
</mx:Tree>
</mx:Application>
Warning: When you use arrays as data providers, you can’t use the property isBranch.
Table 9.1
While these APIs are definitely fine for shaping your Tree control to any form, they’re synchronous
methods. As long as data is already on the client side, these methods let you customize the process
of assembling the tree. But the ability to act as a retriever for the server data is entirely missing
here.
Abandoning ITreeDataDescriptor, we’ll illustrate the approach to dynamic population of the tree
based on using the itemOpen event of the Tree control.
Let’s create a tree populated by a pseudo-remote data feed. To emulate the asynchronous nature
of data retrieval we’ll use the setTimeout() function. We’ll also use plain vanilla arrays for data and
focus on handling the asynchronous data returns.
The itemOpen event is dispatched when a corresponding branch has been expanded. While pro-
cessing this event, we’ll only initiate data retrieval. We can’t expect more from an asynchronous
call, can we? However, while initiating data retrieval we should also make a provision that lets us
identify the response when (and if ) it comes back. The program from Listing 9.3 dynamically ap-
pends the nodes by reacting to the event itemOpen.
tree.dataDescriptor.removeChildAt(
item, ellipsisItem, 0, tree.dataProvider
);
The code snippet above says, “Two seconds from now please call the function onRootChildren-
Ready(), passing it the argument array bigStates.”
Our function onRootChildrenReady() simply assigns the array of the states to the tree’s dataPro-
vider. Since we’ve started the busy cursor during the onCreationComplete(), on the data “return”
we need to take it out:
Now that we’ve taken care of the root level, let’s look at the children. The expansion of a tree item
will be intercepted by our event listener – tree_OnItemOpen shown below. Please note that “item”
is an instance of the Object, i.e., the dynamic class. The property item.isPopulated is a dynamic
property that’s set just once to indicate that the node has been populated.
Prior to sending a request for children we create a visual node that contains the label “…” (ellip-
sisItem) to indicate the progress to the user. It will be removed when the data comes back and the
folder is filled.
As soon as the first child arrives, we have to remove the ellipsis and repopulate the branch by add-
ing the real children. We cast the children of the item to IList, which gives us an agnostic way of
navigating through the collection, be it a collection based on XMLList or Array. Once ellipsisItem
is removed, we add all children iteratively. In both item removal and addition, we delegate to the
tree’s dataDescriptor. To ensure the immediate visual update of the tree branch, we collapse and
then expand the item again:
var list:IList =
IList(tree.dataDescriptor.getChildren(item,tree.dataProvider))
var ellipsisItem:Object = list.getItemAt(0);
tree.dataDescriptor.removeChildAt(
item, ellipsisItem, 0, tree.dataProvider
);
tree.expandItem(item,true,true); CursorManager.removeBusyCursor();
}
To relate the process to Java EE standard procedures in the following sections, we’ll present a hand-
ful of patterns used in the book for one and only one purpose: to justify our naming convention.
This joke has obviously been circulating for a long time now. But please note the following: M. Jor-
dain takes pride in his sudden intimacy with prose, but he’s not sure whether it’s a universal ability
or whether he’s special.
By now you have probably guessed our take on the subject. Time and again the authors of this book
have been pleasantly surprised to find how often we speak… well, use one or the other pattern
without realizing it.
Complete code for DepartmentDAO.java is on the DVD that is included with the book.
You can find the formal description of the DAO design pattern at http://java.sun.com/blueprints/
corej2eepatterns/Patterns/DataAccessObject.html.
ACT is created before the HTTP request is sent to the server (you remember that all RPC requests
go through HTTP, don’t you?). Importantly, a “stub” of the ACT travels to the server. Both the cli-
ent and server continue their processing, and when the server sends a response, bad or good, it
includes the ACT “stub” in the response. Then, the client uses the ACT stub to identify the original
ACT object and all the properties associated with it react accordingly. For example, Listing 9.7 has
the following lines:
To understand these lines, think of how people mail a certified letter at the post office. First you get
a receipt #12345 (var token) confirming that you’ve asked for a particular postal service (getChil-
dren). You can scribble any useful information on this receipt, such as a reference to an item. The
fact that you have a receipt doesn’t mean that the letter has been delivered to the recipient. Two
days later, confirmation #12345 comes in the mail, so you can make a note that this particular letter
has been delivered and do whatever you need with the item reference, which has been thoughtfully
scribbled on your receipt. Here’s an example of how an ACT token can be used at the completion
of the operation:
The Flex Developer’s Guide in the section “Data Management Service Destinations” says it differ-
ently: “An assembler class is a Java class that interacts indirectly or directly with a data resource.
A common design pattern is for assembler to call a Data Access Object (DAO) that calls a data
resource.”
Not that this deviation is accidental – it represents a major paradigm shift toward the assembly of
DTOs in the client. Accordingly, the server-side Assembler most of the time (but not necessarily
always) acts as a pure façade.
This façade will return an array of appropriate DTOs, either departments or employees:
To make this class accessible from the client, we’ll add the following destination in the flex-remot-
ing-service.xml:
For more information on the façade pattern, please visit the Web page http://en.wikipedia.org/
wiki/Facade_pattern.
var list:IList;
if (item!=null)
list = IList(tree.dataDescriptor.getChildren(item,tree.dataProvider));
else
list = IList(tree.dataProvider);
tree.dataDescriptor.removeChildAt(
item, ellipsisItem, 0, tree.dataProvider
);
CursorManager.removeBusyCursor();
var token:AsyncToken = event.token;
var item:Object = event.token.item;
removeEllipsis(item);
]]>
</mx:Script>
<mx:Tree id=”tree” width=”50%” height=”100%”/>
}
// Force to link all required objects into SWF
import com.theriabook.composition.dto.*;
internal var linkage:Object={t1:DepartmentDTO, t2:EmployeeDTO};
]]>
</mx:Script>
This code looks more elegant than the one in Listing 9.7, doesn’t it? This is encapsulation in ac-
tion.
In particular, we will move the creationComplete() code from the application in Listing 9.7 into the
custom Tree control’s creationComplete(). This, in turn, will enable us to keep the onItemOpen()
event listener as a private method of our Tree.
Also, similar to the DataCollection and destination-aware ComboBox, we will create a fill() method,
which executes the remote call against the externally provided destination. To simplify the code,
we stick to the name getChildren(). (In comparison, in Chapter 8 we showed how to parameterize
both destination and method.)
Naturally, we will localize the instantiation of the RemoteObject along with onResult() and on-
Fault() callbacks. Notice, however, that now we will change the concurrency mode to multiple, so
that the fast clicking user could expand more than one item at a time. The last remaining move is
to encapsulate onChildrenReady() and that will complete our job:
<mx:Script>
<![CDATA[
import mx.collections.*;
import mx.controls.Alert;
import mx.events.TreeEvent;
import mx.managers.CursorManager;
import mx.rpc.*;
import mx.rpc.events.*;
import mx.rpc.remoting.mxml.RemoteObject;
ro = new RemoteObject(destination);
ro.concurrency = «multiple”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
return ro;
}
}
private function ro_onFault(event:FaultEvent):void {
CursorManager.removeBusyCursor();
var token:AsyncToken = event.token;
var item:Object = event.token.item;
removeEllipsis(item);
You may ask, what’s the big deal? The total number of lines of code stays almost the same. There’s
an important difference though. We’ve created a reusable Tree component that can be included
in any application that needs composite hierarchical data and the code to do this will be almost
identical to Listing 9.8. All you need to do to adapt it to different databases/tables is to change the
code in the treeAssembler and DAOs behind it. The Tree we created is data-agnostic. The only as-
sumption it makes is that you’ll provide a POJO assembler with overloaded getChildren() methods
that return whatever your business hierarchy is about. This solution supports as many levels of
hierarchy as the treeAssembler cares to provide.
As a reminder, List-based controls (Tree, List, DataGrid, et al) delegate the display of individu-
al data items using so-called item renderers. We’ve touched on this topic in Chapter 5, where we
made the DataGrid column appear as a clickable LinkButton and in Chapter 8 where we emulated
a “dropdown DataGrid” inside the ComboBox List part. In both cases we’ve been placing our own
item renderers instead of default ones. Similarly, we will be replacing the default item renderer of
the Tree control.
Listing 9.10 contains the MXML code of the application that will make use of our custom item
renderer (once we complete it toward the end of the chapter) to produce such a checkboxed
tree:
import com.theriabook.composition.dto.*;
internal var linkage:Object={t1:DepartmentDTO, t2:EmployeeDTO};
]]>
</mx:Script>
This code is pretty compact for the obvious reason: all functionality is encapsulated in the
CheckedTreeItemRenderer.as. Now we’ll start building this item renderer.
The Flex Tree control employs a default drop-in renderer called TreeItemRenderer. This renderer
draws the text associated with each item in the tree, an optional icon, and – for branch nodes – a
default triangle disclosure icon (by default, the triangle) that the user can click on to expand or col-
lapse the branch.
In our case, when we’re adding a checkbox to each item of the Tree, extending TreeItemRenderer
seems quite natural. Accordingly, we’ll be building our custom CheckedTreeItemRenderer as a de-
scendant of TreeItemRenderer.
According to the Flex manual, all children of the custom components must be created in the cre-
ateChildren() method. TreeItemRenderer follows the rules and so will we. In our first version of the
custom renderer – CheckedTreeItemRenderer1 – we’ll override the createChildren() method. That
will let us create a default set of children by delegating to super.createChildren() and then add an
extra CheckBox child. Please note how we follow the Flex component creation practice of passing
the component’s style definition to its children:
package com.theriabook.controls {
import mx.controls.CheckBox;
import mx.controls.treeClasses.*;
public class CheckedTreeItemRenderer1 extends TreeItemRenderer {
public var checkBox:CheckBox;
override protected function createChildren():void
{
super.createChildren();
if (!checkBox) {
checkBox = new CheckBox();
checkBox.styleName = this;
addChild(checkBox);
}
}
}
}
This first version of the custom renderer produces the screen shown in Figure 9.6. We have omitted
the listing of the CheckedTreeDemo1 application since it is the exact replica of CheckedTreeDemo
with CheckedTreeItemRenderer1 instead of CheckedTreeItemRenderer:
The empty squares on the left side are the empty checkboxes added by the renderer. Clearly the
checkboxes aren’t participating in the layout and have landed at the leftmost position of each List
item.
Following the manual, positioning (as well as sizing) the component children has to be done via
the updateDisplayList() method, which is called before the Flex component appears on the screen.
Flex schedules a call to the updateDisplayList() in response to one or more calls to another method
– invalidateDisplayList(). At any rate, the very execution of the updateDisplayList() happens during
the next rendering event. The implementation of the addChild() method also automatically results
in invalidateDisplayList() and so causes updateDisplayList().
In other words, we can address positioning issues by overriding updateDisplayList(), which is guar-
anteed to happen due to our addChild() in particular. The second version of the renderer is shown
in Listing 9.12.
//CheckedTreeItemRenderer2.as
package com.theriabook.controls {
import mx.controls.treeClasses.*;
import mx.controls.*;
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (checkBox) {
checkBox.x = (icon)?icon.x:label.x;
checkBox.setActualSize(checkBox.measuredWidth, checkBox.measuredHeight);
if (icon) {
icon.x = icon.x + checkBox.measuredWidth - 6;
}
label.x = label.x + checkBox.measuredWidth - 6;
}
} //CheckedTreeItemRenderer2
}
We want to put our checkbox in front of the icon. However, if the tree item chooses not to display
the icon, we want the checkbox in front of the label. Let’s position the checkbox:
checkBox.x = (icon)?icon.x:label.x;
Then we’ll set the checkbox size to its measured size (every control has one):
checkBox.setActualSize(checkBox.measuredWidth, checkBox.measuredHeight);
Now let’s move the icon and the label to the right for the width of the checkbox:
if (icon) {
icon.x = icon.x + checkBox.measuredWidth ;
}
This second version of CheckedTreeItemRenderer produces the visual in Figure 9.5. The empty
boxes have moved aside, but now there’s a gap between the checkbox and the icon:
Figure 9.5 The second version of the checkboxed tree with gaps
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (checkBox) {
checkBox.x = (icon)?icon.x:label.x;
checkBox.setActualSize(checkBox.measuredWidth,
checkBox.measuredHeight);
if (icon) {
icon.x = icon.x + checkBox.measuredWidth - 6;
}
label.x = label.x + checkBox.measuredWidth - 6;
}
}
This hard-coded number six doesn’t looks too good. But the Flex CheckBox class extends the class
Button and when we wrote this chapter the class mx.controls.Button.as had the following:
package mx.controls
{
public class Button extends UIComponent
implements IDataRenderer, IDropInListItemRenderer,
IFocusable, IlistItemRenderer {
…
override protected function measure():void
{
super.measure();
…
// Pad with additional spacing, but only if we have a label.
if (label && label.length != 0)
w += extraSpacing;
else
w += 6; //This is our hardcoded value
measuredMinWidth = measuredWidth = w;
measuredMinHeight = measuredHeight = h;
}
}
}
We’re sure this will be fixed in the next version of Flex, so we are merely compensating for the
w+=6.
The last missing detail is sizing. That’s done with the measure() method, which sets the compo-
nent’s default size and, optionally, suggests the component’s minimum size. This method is called
as a result of one or more invalidateSize() calls happening before the screen’s next refresh. In par-
ticular, method addChild() calls invalidateSize() and so results in measure().
Our implementation of measure() is pretty straightforward; we’ll add the width of the checkbox to
the total width of the rendered item:
Let’s take care of the user input first. We’ll register the listener to the “click” event immediately after
the checkbox is added to the renderer:
if (!checkBox) {
checkBox = new CheckBox();
checkBox.styleName = this;
addChild(checkBox);
checkBox.addEventListener(MouseEvent.CLICK,
checkBoxClickHandler);
}
}
The listener – checkBoxClickHandler() – has to reflect the changes to the checkbox’s selected prop-
erty in the checked property of the appropriate dataProvider’s item. How do we get to the item?
Good question. An instance of drop-in item renderers has a property listData. (A pair of getter and
setter methods for listData property is mandated by the IDropInListItemRenderer interface.) In
case of Tree item renderers, reference to the dataProvider’s item can be found after casting listData
to TreeListData, as shown below:
Beware: this technique works only as long as items of the tree’s dataProvider have property checked
or are outright dynamic classes. Otherwise, an assignment to item.checked will cause a runtime
exception.
With the user input handled, let’s look at the proper display of the item state. The natural place to
handle it is in the setter of the listData. We’ll set the selected property of the checkBox to true when
the underlying item.checked is true. In the remaining cases – item.checked is false and item.checked
is undefined – we set checkBox’s selected to false:
Here’s the complete listing of the custom renderer for the checkboxed tree:
package com.theriabook.controls {
import mx.controls.treeClasses.*;
import mx.controls.*;
import flash.events.*;
import mx.controls.listClasses.*
if (!checkBox) {
checkBox = new CheckBox();
checkBox.styleName = this;
addChild(checkBox);
checkBox.addEventListener(MouseEvent.CLICK, checkBoxClickHandler);
}
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (checkBox) {
checkBox.x = (icon)?icon.x:label.x;
checkBox.setActualSize(checkBox.measuredWidth,
checkBox.measuredHeight);
if (icon) {
icon.x = icon.x + checkBox.measuredWidth -6;
}
label.x = label.x + checkBox.measuredWidth -6;
}
}
override protected function measure():void
{
super.measure();
if (checkBox) {
measuredWidth = measuredWidth +
checkBox.measuredWidth -6;
}
}
You can test our item renderer with the demo application CheckedTreeDemo presented earlier in
Listing 9.10 and Figure 9.3. The kaleidoscope of checkboxes is gone; positioning, sizing, and check-
box values are all taken care of.
Summary
In this chapter we showed you how to asynchronously populate Tree controls from remote sources,
where hierarchy of the data is not pre-built, but rather dynamic and, possibly, composite. The cus-
tom Tree control that we built can be applied for a use case with any number of levels by chang-
ing the server-side treeAssembler and DAO classes. We also demonstrated the complete process of
extending a standard item renderer for the Flex Tree control. All in all, we showed how standard
Flex framework controls can be enhanced to provide developers with simple yet powerful compo-
nents.
10
In this chapter we’ll cover how to set up large applications intended for Web or, more broadly speaking,
distributed deployment. As an example let’s consider an enterprise application that consists of hun-
dreds of screens, reports, forms, and dashboards. Accordingly, about a dozen engineers specializing in
GUIs, frameworks, data layers, and business domains are working on this application in parallel.
Large monolithic applications, the way Flex builds application SWFs by default, have several prob-
lems: they take a lot of time to build on each change, they do not support the isolation of two teams
working on two independent “portlets”, they do not allow the incremental delivery of patches to
the systems, and they do not support the independent delivery of libraries of reusable components
without rebuilding the entire application.
We’ll show how to accommodate these requirements emphasizing the productivity of team devel-
opment and deployment flexibility. But first let’s review the deployment scenarios from the busi-
ness point-of-view in detail.
Deployment Scenarios
Throughout this chapter we’ll use the term patches, which are the fixes made to an application be-
tween releases. Add-ons are the parts of the application that are typically added over time. Paches
as well as add-ons blend seamlessly into the hosting application, both visually and programmati-
cally.
In some cases the application build may not even “know” about specific add-ons since they’re
different for each user type. For example, an enterprise application can reveal more screens or
more functionality within these screens to internal users. In this case we talk about portlet-style
add-ons.
Plug-ins are independent applications that don’t share the look-and-feel of the main application.
No intensive interaction between the main application and plug-ins is expected.
The Flash Player loads class definitions from SWF files into the instances of the flash.system.Appli-
cationDomain class – aka application domains. Application domains are organized in a hierarchy
with system domain containing all application domains. If a class is already loaded into a parent
domain, loading a different definition into the child domain will have no effect. If this sounds fa-
miliar, you may have worked with Java ClassLoaders.
Don’t mistake application domains for security domains. The latter are relevant for issues like sub-
loading an SWF file from a different server and are outside the scope of this chapter.
Let’s move on. There are three classes in the Flex library that facilitate SWF loading: flash.
display.Loader, mx.controls.SWFLoader, and mx.modules.ModuleLoader. With each of them you
get two choices of where you want to load the classes: a new (child) domain or an existing ap-
plication domain. ModuleLoader has an applicationDomain property. If you set it to new Applic
ationDomain(ApplicationDomain.currentDomain), new classes will be loaded into a child of the
currentDomain (the domain where the main application runs); to enforce loading in the same do-
main you should set applicationDomain’s value to ApplicationDomain.currentDomain. In each
case with Loader and SWFLoader, you control the target domain by similarly assigning the object’s
loaderContext.applicationDomain.
We have mentioned the overshadowing of children’s class definitions by the parent ones. Accord-
ingly, when you bring existing Flex subsystems (perhaps even written in a different version of Flex)
under a common application umbrella, it makes sense to resort to a separate application domain,
i.e., a child of the system domain. On the other end of the specter, if you need to dynamically load
resources like DataGrid definitions, you will be better off with the same domain where the main
application is running.
Specifically, when you compile with RSLs, Flex generates code to preload the relevant SWFs during
the application’s bootstrap. To be exact, definitions contained in the SWF are loaded directly into
the applicationDomain of the hosting application.
Now how does the application’s bootstrap know which SWF files are to be pre-loaded?
a. You made the file FlexLibrary.SWC (running the compc compiler explicitly or just by rebuild-
ing the Flex Builder’s Library Project).
b. You’ve created the file FlexApplication.mxml, which refers to components from
FlexLibrary.SWC.
c. While compiling FlexApplication.mxml you instructed the mxmlc compiler that
FlexLibrary.SWC contains an image of an SWF to be pre-loaded during the bootstrap (this will
be explained later in this chapter).
Then, the corresponding ActionScript file generated by the mxmlc compiler will have the code
fragment shown in Listing 10.1. You’ll find this and other files in the generated folder of your appli-
cation project once you set the compiler’s option to keep-generated-actionscript=true:
Listing 10.1 The fragment of the generated SystemManager class for FlexApplication.mxml
Listing 10.1 contains the code of the SystemManager class of the FlexApplication. Flex SystemManager
is the first display class created within an application and the parent of all other displayable objects.
SystemManager also creates the mx.preloaders.Preloader that loads SWF files.
Please note that FlexLibrary.swf in and of itself is not an RSL. As we said above, RSL is a usage pat-
tern rather than a file. What makes FlexLibrary.swf part of this pattern is the intent to pre-load it
during the application startup communicated by us to the mxmlc compiler.
“currentDomain”: ApplicationDomain.currentDomain,
This is why class definitions from the FlexLibrary.swf are loaded into the same domain where the
definition of the application classes belong. Accordingly we find the RSL technique especially use-
ful for delivering various patches, which should be loaded prior to any other class definitions. RSLs
are also the best way to package component libraries and resources.
• External: The catalog.xml in the FlexLibrary.swc will be used to resolve references; however
the definitions contained in library.swf won’t be included in the body of the FlexApplication.
swf. The External link type assumes that by the time FlexApplication needs to create instances
of classes from the library.swf part the definitions for these classes will be accessible from the
currentDomain.
• RSL: The catalog.xml in the FlexLibrary.swc will be used to resolve references; the defini-
tions contained in library.swf won’t be included in the body of the FlexApplication.swf. So far
sounds like External, right? Here’s the difference: all definitions originally contained in the
library.swf part will be upfront-loaded into the main applicationDomain during application
startup.
referenced classes as well as the classes they depend on are loaded into the main application-
Domain.
A Merge-in scenario is often called static linking, while External and RSL are cases of dynamic link-
ing.
Suppose we went with dynamic linking via RSL. As illustrated in Listing 10.1, this means pre-load-
ing the FlexLibrary.swf. Here’s the question: where do we get this FlexLibrary.swf from? Under one
scenario we can let Flex Builder extract and rename the library.swf from the FlexLibrary.swc. In Flex
Builder (project Properties >Flex Build Path> Library Path) this option is called Auto extract. Alter-
natively, we could have declined auto-extracting and unzipped the SWF from the SWC ourselves.
As we’ll show later, there’s yet another way of explicitly controlling the upfront build of FlexLibrary.
swf.
To ensure that our CustomPanel is accounted for (in both library.swf and catalog.xml) we have to
verify that it’s included in the Flex Library Build Path. Please be aware that every time you add or
rename files in your Library Project, the corresponding checkbox in Flex Builder gets cleared.
After we click OK, Flex Builder will invoke the compc compiler to create the FlexLibrary.swc in the
output bin folder1.
Then we’ll link our library (see Figure 10.4), compile, and run the application. The output window
will look like this:
Figure 10.4 illustrates the details of adding our recently created library FlexLibrary.swc to the proj-
ect’s Library Build Path. The default link type is to merge-in the SWC’s content (to change the link
type, if needed, select the Link Type line and press the button Edit on the screen below):
Merging the contents of SWC results in an optimized, non-overlapping size of the monolithic ap-
plication. As shown in Figure 10.5, the size of such a self-sufficient FlexApplication.swf is 123KB.
Now let’s change the Link type to RSL. We’ll accept the default value of Auto extract=true:
As a result of the Auto extract, the file FlexLibrary.swf will appear adjacent to the FlexApplication.
swf. The size of the FlexLibrary.swf will be 236K, nearly as much as the entire FlexLibrary.swc, but
the size of the FlexApplication.swf will decrease to 40K:
Now you can see why the default Link Type in Flex is Merge into code. This ensures the smallest size
of the resulting monolithic SWF that carries only the code that was deemed relevant during the
compilation process.
Naturally, the total of 236K + 40K takes two times longer to download then downloading of the
statically linked 123K. However, once you have a family of three applications to offer the same user,
all approximately the same size and all reusing the same FlexLibrary.swf, it becomes (236 + 3*40)
versus 3*123 and you break even.
The size/download considerations are less relevant on the fast connections and, perhaps, are not
relevant at all in scenarios where you can count on the browser cache to keep SWF files loaded for
the next run of the application. A typical example where the time of the initial download is not an
issue would be a corporate environment, but then again, some administrators set policies to wipe
out the browser’s cache on user logoff.
Let’s look at enterprise applications. Driven by user requirements, these applcations tend to change
frequently, growing in functionality and, accordingly, size, with phased delivery to the users. As an ap-
plication gets to tens of megabytes, the time required to build the monolithic SWF becomes a notice-
able setback to developer productivity. The problem gets magnified in a team development where it
translates into many man-hours wasted every day.
And, regardless of size, let’s look at the use case of portlet-style add-ons. These are modules that are
simply impossible to reference statically in advance. In fact, they are not even supposed to be pre-
loaded at all: unlike RSLs they get loaded on demand (more on that later in the chapter).
All in all, we need to be able break the application into a set of modules that can be built indepen-
dently and linked dynamically at runtime.
Oh, but doesn’t that ruin the hope of dynamic linking? The answer is no, and the explanation is just
around the corner in the next section.
First, however, let’s create an application to expose the problem. We’ll build a FlexApplication2 appli-
cation. Unlike our previous example, it won’t contain static references to CustomPanel. Instead, Flex-
Application2 will create instances of a CustomPanel (or any other object for that matter) dynamically,
given a name of the class definition as it’s done in the function createComponent() of Listing 10.4:
If you run the application and click the “Create Panel” button, the code terminates abnormally as
shown in Figure 10.8.
The reason for this error is that many times mxmlc complements classes with additional initial-
ization code at the SystemManager level. But if the relevant classes are completely shielded from
mxmlc it’s absolved from taking care of them. Let’s explain this in detail. Please have another look
at the generated SystemManager corresponding to FlexApplication from Listing 10.3.
package {
import mx.managers.SystemManager;
import flash.utils.*;
import flash.system.ApplicationDomain;
import mx.core.IFlexModuleFactory;
public class _FlexApplication_mx_managers_SystemManager extends mx.managers.SystemManage
r implements IFlexModuleFactory {
public function _FlexApplication_mx_managers_SystemManager() {
super();
}
override public function info():Object {
return {
“currentDomain”: ApplicationDomain.currentDomain,
“layout” : “vertical”,
“mainClassName” : “FlexApplication”,
“mixins” : [“_FlexApplication_FlexInit”,
“_activeTabStyleStyle”, …
“_ControlBarStyle”, “_PanelStyle”, “_CustomPanelWatcherSetupUtil”
]
,
If we compare this SystemManager with the one generated for our latest example – FlexApplica-
tion2 – we’ll see that in the latter case the mixins array is short of the three values: “_ControlBar-
Style,” “_PanelStyle,” and “_CustomPanelWatcherSetupUtil.”
The classes referenced in the mixins array take part in the initialization sequence of the application
upon the initial load. In particular, CustomPanelWatcherSetupUtil is the class that facilitates the
binding for the variable instanceNumber of CustomPanel. In the case of FlexApplication2, this part
of the initialization “gets forgotten.”
[RemoteClass(alias=”com.theriabook.composition.dto.EmployeeDTO”)]
package {
[Mixin]
public class _SimpleAutoCompleteWithDynamicDataDemo_FlexInit
{
. . . .
public static function init(fbs:IFlexModuleFactory):void
{
. . . .
flash.net.registerClassAlias(
“com.theriabook.composition.dto.EmployeeDTO”,
com.theriabook.composition.dto.EmployeeDTO
);
. . . .
}
} // FlexInit
} // package
flash.net.registerClassAlias(
“com.theriabook.composition.dto.EmployeeDTO”,
com.theriabook.composition.dto.EmployeeDTO
);
Now imagine the scenario in which your RSL defines EmployeeDTO and the classes in RSL antici-
pate using it, but the application does not explicitly mention EmployeeDTO anywhere. What hap-
pens? The above initialization code does not get generated at all.
All in all, MXML files as well as metadata-annotated ActionScript classes might not get the expect-
ed initialization support if you put them in RSL and don’t explicitly reference them in the calling
application.
We will politely decline a suggestion to “AutoExtract” SWF from SWC. We will be making the right
SWF ourselves via an Ant build file that controls how we build the SWF. Namely, we will build it as
an application to guarantee that, effectively, our library will initialize itself. As far as SWC goes, we
will restrict its role to merely supporting the name resolution during the compilation of the main
application.
To that end, we’ll add the following FlexLibraryMain.xml application and FlexLibraryMain.as class
(Listings 10.6 and 10.7, respectively):
// FlexLibraryMain.as
package {
import mx.core.SimpleApplication;
public class FlexLibraryMain extends SimpleApplication {
public function FlexLibraryMain() {
// Custom library initialization code should go here
trace(“FlexLibrary.swf has been loaded and initialized”);
}
// Enforce merging-on of required classes by static references here
private var linkage:Object = {
r1:CustomPanel
};
}//FlexLibraryMain
}
Inheriting your FlexLibraryMain from mx.core.SimpleApplication ensures that the compiler will
initialize all the classes referenced by your application, while wrapping it as FlexLibrary.mxml will
support the CSS-style-related portion of the initialization.
We’ve said that we wanted to build the FlexLibrary.swf ourselves. Since we started with Flex Build-
er’s Library Project, the default outcome of the project is only an SWC file. However, nothing stops
us from creating the ANT file that will be calling the mxmlc compiler against our FlexLibrary.mxml
“application.”2
Before we present the listing of the Ant build.xml file let’s ask ourselves several questions.
There could be references to the Flex framework classes from the FlexLibrary project. Do we want
to merge-in the contents of the framework.swc, utilities.swc, etc., to the FlexLibrary.swf? If we want
to keep our library tiny, the answer is “no,” assuming of course that the required Flex framework
classes will somehow be present in the target application domain. That’s why in our build.xml we’ll
extern the framework swc files with lines like the following:
<arg line=”-external-library-path=’${swclibs}/framework.swc’”/>
The next question is where is the deployment destination of FlexLibrary.swf? It should go into the
same folder that the FlexApplication expects it to be. In our scenario, that means:
c:/theriabook/code/applications/FlexApplication/bin/FlexLibrary.swf
<arg line=”-output
c:/theriabook/code/applications/FlexApplication/bin/FlexLibrary.swf”/>
</exec>
</target>
</project>
Please note that the value of the sdkdir property will be different if you use FlexBuilder instead of
Flex Builder Plugin:
When you “Run As Ant” the build.xml above will generate the customized FlexLibrary.swf that will
replace the one previously auto-extracted during the build of the FlexApplication. Now we need to
prevent future unwanted auto-extracts. To that end we need to revisit Flex Build Path and turn off
the “Auto Extract swf” option for FlexLibrary.swc.
But wait, who’s going to ensure that everything from framework.swc, utilities.swc, etc., is going to
await our FlexLibrary.swf in the runtime? Here’s the issue: the default setting for framework.swc,
utilities.swc, flex.swc, and rpc.swc (although the later isn’t relevant to our example) was to “merge-
in” their contents. This was meant to pick only statically referenced classes. When we denied the
FlexApplication rights to auto-extract FlexLibrary.swf we also absolved it from responsibility for
accounting for all the classes that FlexLibrary.swf might need from these “merge-ins” (remember
catalog.xml ?).
Eureka! We’ll turn framework.swc, utilities.swc, and flex.swc to “auto-extract” RSLs. All the above
Flex Application settings are presented on Figure 10.9:
Figure 10.9 The FlexApplication Build path extracts framework libraries and
doesn’t extract FlexLibrary.swf
After we do a clean build (see Flex Builder’s Project menu) and run our application, it functions
properly, as shown in Figure 10.10:
Figure 10.11 shows the deployment directory of the FlexApplication project at this point. You can
see a major increase in the size of the initial download because of the 1Mb of framework.swf. This
is the price paid for the utmost flexibility in the delivery of the modules and development produc-
tivity.
To illustrate this, we’ll create the application project ComboBoxCode that will contain everything
from the original project ComboBox except the sub-folders com/theriabook/resources and com/the-
riabook/composition/dto. We’ll also create the library project Resources containing precisely these
sub-folders as shown in Figure 10.12.
Please note that we show the state of the Resources project after three extra files Resources.mxml,
ResourcesMain.as, and build.xml have been added to the project. Let’s go over them one by one.
Resources.mxml is a clone of FlexLibrary.mxml from Listing 10.6 except that it refers to Resources-
Main.as:
The file ResourcesMain.as enforces the static linkage of the classes EmployeeComboBoxResources
and EmployeeDTO and registers the alias of the EmployeeDTO class:
// ResourcesMain.as
package {
import mx.core.SimpleApplication;
import com.theriabook.composition.dto.EmployeeDTO;
import com.theriabook.resources.EmployeeComboBoxResource;
import flash.net.registerClassAlias;
The third file – build.xml – facilitates building Resources.swf with Ant and mxmlc. Please note that
unlike the example in Listing 10.8, where we referenced the Flex SDK SWC files, here we point to
WEB-INF/flex/libs folder. The reason is that we need fds.swc, which isn’t a part of the Flex SDK. Also
note that we direct the Resources.swf output file straight into the deployment folder of the Combo-
BoxCode application:
When we run this build.xml as an Ant task, it produces a Resources.swf file of 20,851 bytes.
At the same time, let’s not forget the original purpose of Resources.swc – it should help in resolving
all references during the application’s build. That’s why we check off all the classes the application
might need as shown in Figure 10.13. The output folder for the Resources.swc will be WEB-INF\
flex\user_classes:
</flexLibProperties>
As you can see, out of the three files listed in (DOT) directly in front of flexLibProperties, our Re-
sources.as, shown in Listing 10.10, explicitly references EmployeeComboBoxResource and Employ-
eeDTO. We did not have to register the base class – ComboBoxResource – as this is the compiler’s
job.
Now let’s take care of the application settings. For the ComboBoxCode project we’ll set the Link
Type of all the libraries except Resources.swc to RSL with Auto extract, while Resources.swc will be
set as RSL without Auto extract as in Figure 10.14.
Finally, we’ll comment out of the linkage variable in the application, since the pre-load of Resourc-
es.swf that we have built as a self-initializing library will automatically load the EmployeeCombo-
BoxResource class in the currentDomain.
Listing 10.13 The code for the ResourceComboBoxDemo from the ComboBoxCode project
The application is ready to run and after a slight delay it will display a familiar picture:
Unlike RSLs, on-demand loading leaves open the choice of an application domain to load to. Ar-
guably, complete independent subsystems should be loaded into separate domains. On the other
hand, when we load a small “flexlet” that contains some extra business function to augment the
existing application, we load it into the main application domain to allow seamless interoperability
between the new and old classes.
That said, everything we ‘ve done so far to guarantee the self-sufficiency of the libraries is equally rele-
vant to all of them irrespective of the exact loading method: on demand or pre-loaded as in RSL case.
If you click on the “2. Show Library Grid” button, the application will assign an array of data to the
DataGrid’s dataProvider as it would to any ordinary loaded DataGrid:
dg.dataProvider = [
{name:”Anatole Tartakovsky”, phone:”5618325611”},
{name:”Victor Rasputnis”, phone:”7184017234”},
{name:”Yakov Fain”,phone:”7322342654”}
];
Meanwhile the DataGrid won’t contain any data, being a pure “resource” file, as shown in Listing
10.14:
<mx:DataGrid xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”name” headerText=”Name” width=”150”/>
<mx:DataGridColumn dataField=”phone” headerText=”Phone”/>
</mx:Array>
</mx:columns>
</mx:DataGrid>
We’ll begin working on our application by adding the AuthorsGrid to the FlexLibrary project and
registering it with the FlexLibraryMain.as class:
// FlexLibraryMain.as
package {
import mx.core.SimpleApplication;
public class FlexLibraryMain extends SimpleApplication {
public function FlexLibraryMain() {
// Custom library initialization code should go here
trace(“FlexLibrary.swf has been loaded and initialized”);
}
// Static linking of the required classes should go here
private var linkage:Object = {
t1:CustomPanel,
t2:AuthorsGrid
};
}//FlexLibraryMain
}
}
Listing 10.15 The Resources.as file with the static linkage of AuthorsGrid
At this point we can rerun the Ant’s build.xml file, which will place the updated FlexLibrary.swf in
the same folder that we expect our FlexApplication3 to run from.
Let’s “prepare” this application by removing the FlexLibrary.swc from the FlexApplication project’s
Build Path. Up till now we’ve been pre-loading the FlexLibrary.swf the RSL way, which we don’t
want it any more. Accordingly, we will comment out the static reference to CustomPanel inside the
FlexApplication.mxml, otherwise the project’s build will fail:
xmlns=”*”>
<!-- Comment out to illustrate on demand loading with FlexApplication3-->
<!--CustomPanel /-->
</mx:Application>
Now we’ll code the component that facilitates the loading process – LibraryLoader; a partial listing
of the component is shown in Listing 10.17. It can be further developed to provide the progress and
error handling. We’ll inherit this component from the flash.display.Sprite class and make it contain
a child instance of the flash.display.Loader:
Since we prefer seamless programmatic access to classes of dynamically loaded resources, we’ll put
the loaded classes in the loading application’s domain:
dispatcher.addEventListener(Event.COMPLETE, onEvent);
dispatcher.addEventListener(HTTPStatusEvent.HTTP_STATUS, onEvent);
dispatcher.addEventListener(Event.INIT, onEvent);
dispatcher.addEventListener(IOErrorEvent.IO_ERROR, onEvent);
dispatcher.addEventListener(Event.OPEN, onEvent);
dispatcher.addEventListener(ProgressEvent.PROGRESS, onEvent);
dispatcher.addEventListener(Event.UNLOAD, onEvent);
// LibraryLoader.as
package com.theriabook.util
{
import flash.display.Sprite;
import flash.display.Loader;
import flash.net.URLRequest;
import flash.events.*;
import flash.system.LoaderContext;
import flash.system.ApplicationDomain;
We’re ready to write the application FlexApplication3.mxml. To illustrate that fonts bound to the
application’s SystemManager are proliferated to the loaded classes, we’ll purposely throw in a non-
standard style definition for the DataGrid fonts (please notice the larger than usual characters in
Figure 10.16):
<mx:Style>
DataGrid {
fontFamily: Arial; fontSize: 14; headerStyleName:”dgHeader”;
}
.dgHeader {
fontFamily: Arial; fontSize: 14pt; fontWeight:bold;
}
</mx:Style>
We’ll prepare two functions, individually invoked from the buttons “1. Load Library” and “2. Show
Library Grid.” The showGrid() function instantiates the DataGrid freshly loaded by loadLibrary(),
given the name AuthorsGrid:
Let’s run the application in the debug mode to see the debugger’s trace messages. This is what
you’ll see in the console window when the application starts:
These messages reflect the fact that all of the above libraries are marked as RSLs with “Auto extract.”
Now let’s press the “1. Load Library” button. The following output will go to the console:
At this point we can press the button “2. Show Library Grid.” The grid with the data will appear
exactly as shown in Figure 10.16.
Congrats! We’ve just loaded a visual dynamic object AuthorsGrid that can access other objects and
be accessed the same way as any other class. In particular, AuthorsGrid adheres to global styles
while its properties and methods are directly accessible from the application class.
Here is the listing of InnerApplication.mxml, which shows the Panel with two label controls on a
light pink background:
<?xml version=”1.0”?>
<!-- InnerApplication.mxml-->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” backgroundColor=”0xffeeff”>
<mx:Script>
[Bindable]
public var value:String = “From InnerApp with love!”;
</mx:Script>
Before compiling InnerApplication.mxml into InnerApplication.swf, let’s figure out the Link Type
for the Flex framework libraries. If we plan to run the InnerApplication as standalone and offer it to
the broad unprepared clientele over the Internet, we need to keep the size minimal, so we would
choose to merge the framework libraries. However, this is not our case.
Specifics of our case is that the InnerApplication is being brought to life by the OuterApplication,
which has already taken care of the framework libraries. That is why we will mark all the framework
libraries as external.
But, if we’re going to keep the OuterApplication.mxml and InnerApplication.mxml in the same Flex
Builder project, they will compete for a single set of Flex Build Path settings. Settings for OuterAp-
plication are not supposed to extern framework libraries, rather they should AutoExtract them. To
avoid the problem and allow both InnerApplication and OuterApplication to stay in one project,
we will leave the Library path to the OuterApplication and take care of the InnerApplication with
the additional InnerApplication-config.xml file to the project, as in Listing 10.22. Both Flex Builder
and a command-line mxmlc compiler try to read an <ApplicationName>-config.xml file (aka, local
configuration guide) before using the project properties (you can read more on the precedence of files
and command-line parameters in the Adobe Flex manual in the section “Using Command-line Com-
pilers”). InnerApplication-config.xml, shown below, exclusively externs all the framework libraries for
the InnerApplication:
<flex-config>
<!--InnerApplication-config.xml-->
<compiler>
<external-library-path>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/playerglobal.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/framework.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/utilities.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/flex.swc</path-element>
</external-library-path>
</compiler>
</flex-config>
Let’s mark the InnerApplication as the default one and build the project. This will build an InnerAp-
plication.swf.
Now let’s focus on the OuterApplication. First and foremost, it will to have an instance of SWFLoad-
er, which loads the InnerApplication.swf:
Next, it will have a label, whose value gets replaced by the value obtained from the label_1 of the
InnerApplication when the “Read inner label” button is clicked:
It will also contain a text field, where we’ll type some text, and two buttons to pass this text directly
into the InnerApplication’s label_1 and the corresponding value variable:
The default setting of the loaderContext of the SWFLoader is to load new definitions into the child
domain. Accordingly, to access the label_1 inside the InnerApplication we may do something like
this:
(Flex provides several other ways Outer- and Inner-applications can interoperate, such as Share-
dObjects, LocalConnection, and ExternalInterface. We discuss the last two in Chapter 15.)
<?xml version=”1.0”?>
<!-- OuterApplication.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:Script>
<![CDATA[
import mx.managers.SystemManager;
public var innerApplication:Application = null;
</mx:Application>
When we run the OuterApplication it displays the picture shown in Figure 10.17. As you can see, ap-
plications are isolated in different application domains and their style settings (backGround color)
are different:
Now let’s type “Passed From Outer App” in the text field and click all three buttons in a row. The first
button click will read the control’s value from the InnerApplication, while the clicks on the second
and the third buttons will modify the values of the InnerApplication’s control and public variable,
respectively. The outcome is shown in Figure 10.18.
You may say that the communications between the applications is not as seamless as it is with
add-ons. This is correct. But let’s face it, plug-ins serve a different purpose: they’re an easy way
to add third-party content to your application. They’re complete applications with their own UI,
including styling. Their functionality doesn’t depend on host applications. In fact, you have to be
very careful with references to the objects from the plug-in, since live references will prevent the
unloading of plug-in classes.
ModuleLoader facilitates the loading of modules. Take a regular Flex application, replace <mx:Ap-
plication> with <mx:Module>, compile, and you have the module. Not surprisingly, modules are
completely self-initialized, much like normal applications.
Programmatically, loading modules looks almost identical to using SWFLoader. To illustrate this
point, we have rewritten our OuterApplication/InnerApplication example and created InnerMod-
ule and OuterModuleLoader.
All in all, modules seem to be an ideal way of plugging in independent UI widgets, subsystems, or
applications, similar to SWFLoader.
Listing 10.23 presents the code for InnerModule. We cloned the code from InnerApplication and
added the lines in bold:
<?xml version=”1.0”?>
<!-- InnerModule.mxml-->
<mx:Module xmlns:mx=”http://www.adobe.com/2006/mxml” implements=”IHeyModule”
backgroundColor=”0xffeeff”>
<mx:Script>
[Bindable]
public var value:String = “From InnerModule with love!”;
public function getProperty(name:String):* {
if (name==”value”) return value; else return undefined;
}
public function setProperty(name:String, newVal:*):void {
if (name==”value”) value=newVal;
}
</mx:Script>
<mx:Panel title=”This Panel is a part of InnerModule” >
<mx:Label id=”label_1” text=”This label contains static text” />
You’ll notice that our module implements the IHeyModule interface, but please don’t get the idea
that modules have anything to do with interfaces. Likewise, modules and applications loaded by
SWFLoader are free to implement any interface, much as OuterApplication and OuterModule-
Loader (later in this section) are free to ignore an interface as long as the names of the public prop-
erties are known and there is an abundance of double quotes.
<flex-config>
<!--InnerModule-config.xml-->
<compiler>
<external-library-path>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/playerglobal.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/framework.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/utilities.swc</path-element>
<path-element>C:/Program Files/Adobe/Flex Builder 2 Plug-in/Flex SDK 2/frame-
works/libs/flex.swc</path-element>
</external-library-path>
</compiler>
</flex-config>
// IHeyModule.as
package
{
public interface IHeyModule
{
function getProperty(name:String):*;
function setProperty(name:String, value:* ):void;
}
}
<?xml version=”1.0”?>
<!-- OuterModuleLoader.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:Script>
<![CDATA[
import mx.managers.SystemManager;
public var innerDisplayObject:DisplayObject = null;
// innerDisplayObject[“value”] = new_value.text;
</mx:Application>
When you run OuterModuleLoader, its look and behavior will be indistinguishable from OuterAp-
plication, Figure 10.18.
Finally, we present samples of using the IHeyModule interface by InnerApplication and OuterAp-
plication, Listings 10.27 and 10.28, respectively.
<?xml version=”1.0”?>
<!-- InnerApplication.mxml-->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” implements=”IHeyModule”
backgroundColor=”0xffeeff” >
<mx:Script>
[Bindable]
public var value:String = “From InnerApp with love!”;
public function getProperty(name:String):* {
if (name==”value”) return value; else return undefined;
}
public function setProperty(name:String, newVal:*):void {
if (name==”value”) value=newVal;
}
</mx:Script>
<mx:Panel title=”This Panel is a part of InnerApplication”>
<mx:Label id=”label_1” text=”This label contains static text” />
<mx:Label text=”This label is bound to ‘value’, currently - {value}”/>
</mx:Panel>
</mx:Application>
<?xml version=”1.0”?>
<!-- OuterApplication.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>
<mx:Script>
<![CDATA[
import mx.managers.SystemManager;
public var innerApplication:Application = null;
// innerApplication[«value»] = new_value.text;
}
]]>
</mx:Script>
</mx:Application>
Listing 10.28 Version of OuterApplication that makes use of the IHeyModule interface
Speaking of modules and applications, just as an example case, this pair of options enables you to
extern for the module everything that will be loaded by the application. However, if you plan to ever
reuse the same module for the different hosting application, this technique is not applicable.
There is an opposite way to use the -link-report option. Earlier we explained why you should use
self-initialized RSLs for component and resource libraries (as opposed to visual plugins, where
modules and applications reign). If you recall, we managed to keep these RSLs extremely tiny by
externing an entire set of Flex framework SWC files under the assumption that the main applica-
tion would supply those via AutoExtract. The only downside has been the indiscriminating extract
of the entire set of classes (resulting in a large 1Mb framework.swf in particular). But why tolerate a
wholesale extract? If you use the compiler’s option –include you can go back to merge-in Link Type
and have the application merge in all the classes required by your libraries.
In this scenario, which applies to self-initialized RSLs as well as modules, you run -link-report on
the module or library and instead of optimizing the module, you optimize the application. No need
to rebuild your libraries or modules to satisfy an individual application – they stay 100% reusable.
Instead, you tune your applications.4
And, speaking of size, don’t forget the -debug option. By turning it to false, you may strip up to 30%
of the size taken by the debugging information. By the same token, you may want to recompile
framework.swf from the Adobe Flex Framework source files to take its size down in the first place,
prior to resorting to –include.
Summary
In this chapter we went through a number of techniques of utmost importance when it comes to
large application development. We showed you how to:
Endnotes
1. A word of advice: make a decision where you want to keep your SWC files and stick to it. Avoid the situ-
ation where the SWC linked in by your application is not the same one that you’re making with the Flex
Builder Project.
2. In Flex 2.0.1 you can coordinate running the Ant file with the build of the SWC by adding the extra
“builder” to the project.
3. During the lifetime of any resource project or component library project, the corresponding Resource-
Main.as file will need to be kept in sync with the project contents. One way to achieve this is to include a
code-generation target in your Ant script and treat the contents of .flexLibProperties as input data. Alter-
natively, to automate this and all other Flex build-related tasks, you can use the Flex2Ant utility developed
by FarataSystems, see http://www.myflex.org for more information.
4. The current release of Flex does not provide automation tools for this optimization, so you may want to
create the automation process yourself. Alternatively, you can use Flex2Ant, by FarataSystems, see http://
www.myflex.org for more information
11
Advanced DataGrid
Advanced DataGrid
The subject of DataGrid control, let alone advanced control, has no limits. In any UI framework, the
robustness of the DataGrid, or whatever the name might be, depends on formatting and validating
utilities as well as a whole suite of data input controls: CheckBoxes, ComboBoxes, RadioButtons, all
sorts of Inputs, Masks, and so on. Using theatrical terminology, the role of the king is played by his
entourage. Practically speaking, touching up on the DataGrid is touching up on a large part of the
Flex framework. Hence this chapter is a ride with fast-changing scenery.
We’ll start our DataGrid journey upgrading a standard DataGrid to a “destination-aware” control
capable of populating itself. Since we introduced this technique in earlier chapters you should ease
right on in. Next, we’ll look at formatting DataGrid columns and that would naturally lead us to a
hidden treasury of the DataGridColumn, which, once you start treating it like a companion rather
than a dull element of MXML syntax, can help you do amazing things.
To set the stage for the DataGrid’s satellite controls, we’ll lead you through making a reusable Flex
library that supports the mapping of your custom tags to the arbitrary hierarchy of implementation
classes. We will show you the power of computed expressions in place of styles such as color, and
font, making our DataGrid truly data-driven. We will build a suite of effective controls to use as item
renderers/editors, as well as standalone. Then we will step up the offense and show you how the
entire sets of DataGridColumn definitions, including item editors and renderers, can be dynami-
cally computed based on the data!
<!-- DestinationAwareDataGridExDemo.mxml-->
<?xml version=”1.0” encoding=”utf-8”?>
In the listing below we’ve subclassed the standard Flex DataGrid. The code in our DataGrid bor-
rows the relevant code from Listing 8.12:
// DataGrid.as
package com.theriabook.controls {
import mx.controls.DataGrid;
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.AbstractOperation;
import mx.rpc.events.*;
import mx.controls.Alert;
import mx.managers.CursorManager;
ro = new RemoteObject(destination);
ro.showBusyCursor = true;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
}
var operation:AbstractOperation = ro.getOperation(method);
operation.arguments = args;
operation.send();
}
private function ro_onFault(evt:FaultEvent):void {
CursorManager.removeBusyCursor();
Alert.show(“Failed retrieving data: “+evt.message, “[DestinationAwareDataGrid]” +
id);
}
If we run the application, our screen will show the employee records grid in its default formatting:
A labelFunction is a callback and being invoked by the DataGrid, it receives the appropriate data
item plus information about the column, so that you can technically apply one function to more
than one column. As far as the formatting techniques per se, Flex offers plenty of pre-defined for-
matters that can be used out-of-the-box or be customized to your specific needs. For instance, to
format social security numbers (SS_NUMBER) we could have used mx.formatters.SwitchSymbol-
Formatter and created the following function:
import mx.formatters.SwitchSymbolFormatter;
private var sf:SwitchSymbolFormatter;
private function ssnLabelFunction(item:Object, column:DataGridColumn):String {
if (!sf) {
sf = new SwitchSymbolFormatter();
}
return sf.formatValue(“###-##-####”, item[“SS_NUMBER”]);
}
Similarly, in Listing 11.2 we can apply the same technique to the PHONE field, setting the format-
String to (###)###-####:
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<mx:DataGridColumn dataField=”PHONE” labelFunction=”phoneLabelFunction”
/>
<mx:DataGridColumn dataField=”SS_NUMBER” labelFunction=”ssnLabelFunction”
/>
</mx:Array>
</fx:columns>
</fx:DataGridEx>
<mx:Script>
<![CDATA[
import mx.formatters.SwitchSymbolFormatter;
private var sf:SwitchSymbolFormatter;
private function ssnLabelFunction(item:Object, column:DataGridColumn):String {
if (!sf) {
sf = new SwitchSymbolFormatter();
}
return sf.formatValue(“###-##-####”, item[“SS_NUMBER”]);
}
private function phoneLabelFunction(item:Object, column:DataGridColumn):String {
if (!sf) {
sf = new SwitchSymbolFormatter();
}
return sf.formatValue(“(###)###-####”, item[column.dataField]);
}
]]>
</mx:Script>
</mx:Application>
A more pragmatic approach is to introduce the formatString as an extra attribute for DataGridCol-
umn and have it encapsulate the implementation details. We’re talking about the following alterna-
tive:
Implementation of such syntax is within arm’s reach. We just need to extend – well, not the
arm, but the DataGridColumn, so that instead of mx:DataGridColumn we would use, say, our
fx:DataGridColumn. The mx.controls.dataGridClasses.DataGridColumn is just a respository of
styles and properties to be used by the DataGrid. In the Flex class hierarchy it merely extends CSS-
StyleDeclaration. Nothing prevents us from extending it further and adding an extra attribute. In
the case of formatString we delegate the actual job of assigning the value of labelFunction to a
helper class - FormattingManager:
Wait a minute, where did the FormattingManager come from? Well, we’ll get to the implementation
of that class a bit later. At this point, we have to eliminate a possible naming collision between our
to-be-made DataGridColumn and the standard mx.controls.dataGridClasses.DataGridColumn.
To break the spell and abstract the namespace from the exact file location, we have to use the com-
ponent manifest file. Component manifest is an XML file that allows mapping component names
to the implementing classes. Below is an example of a component manifest that combines our
custom DataGrid and DataGridColumn located in different folders:
<?xml version=”1.0”?>
<componentPackage>
<component id=”DataGrid” class=”com.theriabook.controls.DataGrid”/>
<component id=”DataGridColumn”
class=”com.theriabook.controls.dataGridClasses.DataGridColumn”/>
</componentPackage>
To benefit from the use of this component manifest you have to compile your components with the
compc or use the Flex Library project. To be more specific, you have to instruct compc to select the
URL that your application can later use in place of the hard-coded folder in the xmlns declaration.
So we’ll create a new FlexLibrary project – theriabook, where we will put the theriabook-manifest.
xml containing the XML above and set the relevant project properties as shown in the Figure 11.3:
We will add theriabook project to the Flex Build Path of our application project as “SWC folder”.
Now we can move the DataGrid from our application project to theriabook and replace xmlns:
fx=”com.theriabook.controls” with xmlns:fx=”http://www.theriabook.com/2006”, provided that the
Flex Build Path of our application project includes a reference to theriabook.swc. As a result, our
application will reference fx:DataGrid and fx:DataGridColumn, irrespective of their physical loca-
tion.
As we mentioned, the “dirty” job of locating and assigning the proper label function has been del-
egated to the helper class FormattingManager. This class, presented in Listing 11.4, should be put
into our theriabook project:
package com.theriabook.controls.dataGridClasses
{
public class FormattingManager
{
import mx.controls.dataGridClasses.DataGridColumn;
import mx.formatters.SwitchSymbolFormatter;
private static var sf:SwitchSymbolFormatter;
formatString:String):void {
switch (formatString.toLowerCase()) {
case “ssn”:
dgc.labelFunction = ssnLabelFunction;
case “phone”:
dgc.labelFunction = phoneLabelFunction;
}
}
private static function ssnLabelFunction(item:Object, column:
mx.controls.dataGridClasses.DataGridColumn):
String {
if (!sf) {
sf = new SwitchSymbolFormatter();
}
return sf.formatValue(“###-##-####”, item[“SS_NUMBER”]);
}
private static function phoneLabelFunction(item:Object, column:DataGridColumn):S
tring {
if (!sf) {
sf = new SwitchSymbolFormatter();
}
return sf.formatValue(“(###)###-####”, item[column.dataField]);
}
}
}
Tada! And the winner is… the developer. Once we add theriabook.swc (with DataGrid, DataGridCol-
umn, and FormattingManager) to the library path, the application code gets reduced to the following:
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<fx:DataGridColumn dataField=”PHONE” formatString=”phone” />
<fx:DataGridColumn dataField=”SS_NUMBER” formatString=”ssn” />
</mx:Array>
</fx:columns>
</fx:DataGridEx>
</mx:Application>
Improving FormattingManager
In the previous examples we’ve used the SwitchSymbolFormatter for both phone and ssn format-
ting. As soon as we start formating numbers or currency values, it’s natural to use NumberFormat-
ter or CurrencyFormatter – descendants of mx.formatters.Formatter. In fact, Flex offers a dedicated
formatter even for the phone formatting.
While SwitchSymbolFormatter derives from Object, all the rest of the formatters descend from For-
matter. By encapsulating this specific SwitchSymbolFormatter in the custom class MaskFormatter,
we’ll help ourselves to base the next version of FormattingManager entirely on Formatters:
//MaskFormatter.as
package com.theriabook.formatters {
import mx.formatters.Formatter;
import mx.formatters.SwitchSymbolFormatter;
Look how this MaskFormatter1 simplifies our FormattingManager: we can replace all private meth-
ods with an anonymous function, as shown in Listing 11.7. Please note that the reference to the
appropriate formatter is preserved with the closure:
//com.theriabook.controls.dataGridClasses.FormattingManager.as
package com.theriabook.controls.dataGridClasses
{
public class FormattingManager
{
import mx.controls.dataGridClasses.DataGridColumn;
import mx.formatters.*;
import com.theriabook.formatters.MaskFormatter;
dgc:mx.controls.dataGridClasses.DataGridColumn,
formatString:String):void {
var formatter:Formatter = null;
switch (formatString.toLowerCase()) {
case “ssn”:
formatter = new MaskFormatter(“###-##-####”);
break;
case “money”:
formatter = new CurrencyFormatter();
CurrencyFormatter(formatter).precision=2;
break;
case “phone”:
formatter = new PhoneFormatter();
break;
case “shortdate”:
formatter = new DateFormatter();
break;
case “zip”:
formatter = new ZipCodeFormatter();
break;
}
if (formatter) {
dgc.labelFunction = function (
item:Object,
dgc:mx.controls.dataGridClasses.DataGridColumn):String
{
return formatter.format(item[dgc.dataField]);
}
}
}
}
}
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<fx:DataGridColumn dataField=”SALARY” formatString=”money” />
<fx:DataGridColumn dataField=”PHONE” formatString=”phone” />
<fx:DataGridColumn dataField=”SS_NUMBER” formatString=”ssn” />
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
If you run it, the DataGrid dg will be formatted as shown in Figure 11.4:
Let’s focus on the hard-coding that we allowed in the case of the money value:
case “money”:
formatter = new CurrencyFormatter();
CurrencyFormatter(formatter).precision=2; break;
This hard-coding reflects, perhaps, the most “popular” case. But what if we want to have the full
advantage of the properties of the corresponding formatter such as precision in the case of the
CurrencyFormatter? To address these cases we’re going to introduce one more fx:DataGridColumn
property – formatData. Here’s how it will be used in the application MXML:
<fx:formatData>
<mx:Object formatString=”money” precision=”0”/>
</fx:formatData>
</fx:DataGridColumn>
The elegance of MXML lets us implement this extension with just a few lines of extra code in com.
theriabook.controls.dataGridClasses.DataGridColumn2:
Then, to accommodate the change on the FormattingManager side, we’ll iterate through all the
properties of the formatData object and attempt to assign them to the appropriate properties of
the formatter with an emphasis on the word “appropriate.” The MXML compiler isn’t going to help
us check the properties of the unsealed <mx:Object> against the properties of the formatter. So, to
protect ourselves from the no-such-property-exceptions, we surround the property assignments
with try/catch:
The complete listing of renewed FormattingManager is presented below3. Of course, when maintain-
ing your own framework, you’d transform this class to accommodate your particular requirements:
//FormattingManager.as
package com.theriabook.controls.dataGridClasses
{
public class FormattingManager
{
import mx.controls.dataGridClasses.DataGridColumn;
import mx.formatters.*;
import com.theriabook.formatters.MaskFormatter;
switch (fs.toLowerCase()) {
case “ssn”:
formatter = new MaskFormatter(“###-##-####”);
break;
case “money”:
formatter = new CurrencyFormatter();
CurrencyFormatter(formatter).precision=2;
break;
case “phone”:
formatter = new PhoneFormatter();
break;
case “shortdate”:
formatter = new DateFormatter();
break;
case “zip”:
formatter = new ZipCodeFormatter();
break;
default:
if (fs.indexOf(“#”)!=-1) {
formatter = new MaskFormatter(fs);
};
}
if (!(formatData is String)) {
for (var property:String in formatData) {
try {
formatter[property] = formatData[property];
} catch (err:Error) {
// Property does not match formatter type
}
}
}
if (formatter) {
dgc.labelFunction = function (
item:Object,
dgc:mx.controls.dataGridClasses.DataGridColumn
):String {
return formatter.format(item[dgc.dataField]);
}
}
}
}
}
When you run the application it will produce the DataGrid shown in Figure 11.5:
We’ll continue beefing up our custom DataGridColumn after a short detour into CheckBox and
RadioButton controls.
The state of a CheckBox control is managed by the Boolean property selected. At the same time,
many business systems use either Y/N or, sometimes, 0/1 flags. As a result, translating business-
specific values into selected and vice versa burdens the application code. Listing 11.11 presents
a custom CheckBox that supports application-specific on and off values along with the current
value:
//CheckBox.as
package com.theriabook.controls
{
import mx.controls.CheckBox;
_value = val;
invalidateProperties();
}
public function get value():Object {
return selected?onValue:offValue;
}
override protected function commitProperties():void {
selected = (_value == onValue);
super.commitProperties();
}
}
}
<fx:DataGridColumn dataField=”BENE_DAY_CARE”
itemRenderer=”com.theriabook.controls.CheckBox” >
</fx:DataGridColumn>
Obviously, we have to modify the CheckBox some more to take care of the value in the data setter:
But how will we communicate to our CheckBox-turned-itemRenderer the offValue and onValue
properties? Ideally, we’d need something like:
<fx:DataGridColumn dataField=”BENE_DAY_CARE”
itemRenderer=”com.theriabook.controls.CheckBox” >
<fx:extendedProperties>
<mx:Object onValue=”Y” offValue=”N” />
</fx:extendedProperties>
</fx:DataGridColumn>
Flex creators thought of this in advance. An object referenced by itemRenderer isn’t a CheckBox,
but rather an instance of mx.core.ClassFactory wrapped around the CheckBox. The mechanism
of mx.core.ClassFactory lets Flex generate multiple instances of another class – com.theriabook.
controls.CheckBox, in our case. Importantly, each instance created by the factory is assigned iden-
tical properties borrowed from the properties of the factory object. So, all we have to do is pass the
value of the extendedProperties as properties of the itemRenderer.
//DataGridColumn.as
package com.theriabook.controls.dataGridClasses{
import mx.controls.dataGridClasses.DataGridColumn;
Below is the listing of the test application, ExtendedPropertiesDemo. When you run it, it produces
the DataGrid shown in Figure 11.6.
xmlns:fx=”http://www.theriabook.com/2006”>
<fx:DataGrid id=”dg” creationComplete=”dg.fill()”
destination=”com_theriabook_composition_EmployeeDAO” method=”getEmployees”
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<fx:DataGridColumn dataField=”BENE_DAY_CARE” itemRenderer=”com.theriabook.
controls.CheckBox” >
<fx:extendedProperties>
<mx:Object onValue=”Y” offValue=”N” />
</fx:extendedProperties>
</fx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
We should have mentioned the alternative run-of-the-mill approach with inline itemRenderer,
Listing 11.14:
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<mx:DataGridColumn dataField=”BENE_DAY_CARE”>
<mx:itemRenderer>
<mx:Component>
<fx:CheckBox onValue=”Y” offValue=”N”/>
</mx:Component>
</mx:itemRenderer>
</mx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
Arguably, the extendedProperties approach is more efficient, since it absolves MXML of generating
an extra nested class (mx:Component) for each column of this kind4. We’ve introduced you to yet
another way of customizing a DataGridColumn, and we’ll continue building on top of it in the fol-
lowing sections.
Nitpicking CheckBox
There are some additional remarks that we ought to make about our CheckBox implementation at
this point.
The first one is related to the horizontal alignment of the CheckBox. Instinct tells us that a label-
free checkbox should be centered in the column rather than stuck in the left-most position. At first,
you may try applying a textAlign style to the DataGridColumn – to no avail. Then you might resort
to another run-of-the-mill approach to center the checkbox by putting it inside a container such
as an HBox. Here’s the performance-based advice endorsed by Flex Framework engineers: avoid
containers inside the DataGrid cell at all reasonable cost. In particular, instead of using HBox, why
not subclass the CheckBox and override the updateDisplayList() method? It gets quite natural, once
you’ve stepped on this path, so we’ll add the code shown below to our CheckBox (the complete
code for the com.theriabook.controls.CheckBox is presented in Listing 11.15):
import mx.core.mx_internal;
use namespace mx_internal; . . . .
override protected function updateDisplayList(
unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (currentIcon) {
Note the use of namespace mx_internal. It’s required to reference the currentIcon that visualizes
the checkbox, since currentIcon – the child of the original CheckBox – is originally scoped as mx_
internal.
And, when we run it, all checkboxes are in their proper place:
The second nitpicking point is related to undefined as a possible value of a property. Under our cur-
rent business scenario, we can assume that some of the employees are not eligible for the daycare
benefit, and relevant items in the dataProvider’s collection are lacking the BENE_DAY_CARE prop-
erty, which for dynamic items can be expressed as item.BENE_DAY_CARE==”undefined.”
Does it make sense to show checkboxes for non-eligible employees? Perhaps, it doesn’t. In this
case we’d make currentIcon invisible. You can select a different approach and show a fuzzy check-
box image instead, but this is beyond the point5. The following modification of updateDisplayList()
does the job of removing checkBox when the value is undefined:
unscaledHeight:Number):void
{
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (currentIcon) {
var style:String = getStyle(“textAlign”);
if ((!label) && (style==”center”) ) {
currentIcon.x = (unscaledWidth - currentIcon.measuredWidth)/2;
}
currentIcon.visible = (_value!=undefined);
}
}
To accommodate this change we have to loosen up the class definitions for value as shown in List-
ing 11.15, where we change Object to undefined.
The next and probably the most important fix is that our CheckBoxes have been silenced. Try to
click on one, scroll the row out of view and scroll it back in. The checkbox doesn’t retain your se-
lection and it shouldn’t; we’ve never communicated the change to the underlying data. To remedy
the situation we’ll add the constructor method, where we’d start listening on the “change” event;
once the event is intercepted we’ll modify the data item with the CheckBox value. That, in turn, will
result in either onValue or offValue, as per our value getter:
And the last point: Flex collections by themselves do not notice any changes done to the underlying
data items; it is the application’s responsibility to keep the collections informed, especially if you have
more then one view based on the same collection. In our case, change of the data would go totally
unnoticed by the collection displayed by DataGrid, until we explicitly notify it with the COLLECTION_
CHANGE event. The complete code for the second version of CheckBox is presented in Listing 11.15:
//CheckBox.as
package com.theriabook.controls
{
import flash.events.Event;
import mx.controls.CheckBox;
import mx.controls.dataGridClasses.DataGridListData;
import mx.core.mx_internal;
use namespace mx_internal;
super.updateDisplayList(unscaledWidth, unscaledHeight);
if (currentIcon) {
var style:String = getStyle(“textAlign”);
if ((!label) && (style==”center”) ) {
currentIcon.x = (unscaledWidth - currentIcon.measuredWidth)/2;
}
currentIcon.visible = (_value!=undefined);
}
}
}
}
Next comes the test application. We’ve added the “Revoke day care benefit” button, which turns
DAY_CARE_BENE into undefined on the currently selected DataGrid item. We also had to notify the
collection with the itemUpdated() call:
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<fx:DataGridColumn dataField=”BENE_DAY_CARE” textAlign=”center”
itemRenderer=”com.theriabook.controls.CheckBox” >
<fx:extendedProperties>
<mx:Object onValue=”Y” offValue=”N” />
</fx:extendedProperties>
</fx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
When you run the above application, you’ll see that checkboxes retain the selection after scrolling
out and back into view. If you click the “Revoke” button for the first two rows, you’re going to see a
picture similar to the one below:
The last CheckBox fix will come in handy once you declare the DataGrid editable. Why declare it
editable in the first place if we seem to be editing the DataGrid already? Let’s not forget that the
only field we’ve been editing so far is the checkbox BENE_DAY_CARE. Should you decide to allow
editing of the text fields, you would have to change the definition of the DataGrid as it is shown in
bold in the following snippet6:
>
But once you do that, a click on the beautiful checkbox of ours would turn it into a default editor
– TextInput, quite like in a Cinderella story. To make the miracle last, you’d declare that your ren-
derer is good to go as an editor as well:
By default, DataGrid reads the text property of the item editor. You can nominate a different prop-
erty via editorDataField (in our case that would be value). Alternatively, and that will help us later
in the chapter, you can “upgrade” the checkbox to carry the text property:
We leave it to the reader to try the latest changes in the CheckBox and test the application. Or you
can find the solution in the source code that comes with the book. We’ll be counting on it later in
the chapter.
</mx:Array>
</fx:options>
</fx:DataGridColumn>
To support this use case we need to build the renderer class and make the DataGridColumn pass it
the array of options. The latter can be done by adding the following options setter to our DataGrid-
Column:
package com.theriabook.controls.dataGridClasses{
. . . . .
public class DataGridColumn extends mx.controls.dataGridClasses.DataGridColumn
{
. . . . .
public function set options(val:Array):void {
if (itemRenderer) itemRenderer [“properties”] = {options:val};
}
}
}
Now let’s build the renderer. By definition, to be an item renderer, the component has to imple-
ment an IListItemRenderer interface. To qualify as drop-in, a component also has to implement
IDropInListItemRenderer. A standard CheckBox implements both interfaces, so when we were ex-
tending CheckBox in the last section, we didn’t have to mention a single implements and just mer-
rily used data and listData at our convenience.
This is not the case now. Had RadioButtonGroup been at least a UIComponent, we’d need to im-
plement IDataRenderer and IDropInListItemRenderer interfaces and be done. But RadioButton-
Group isn’t even a DisplayObject! So we’ll base our renderer on mx.containers.Box with RadioBut-
tonGroup embedded8:
Having a RadioButtonGroup is just the beginning. Whenever our component gets assigned
options, we’ll translate them into a set of RadioButton controls. Each RadioButton will be added as
a child of the renderer (container):
. . . .
_options=opt;
for (i= 0; i < opt.length; i++) {
var rb:RadioButton = new RadioButton();
rb.label = opt[i].label;
rb.value = opt[i].data;
addChild(rb);
}
}
Note how subscribing a RadioButton to the group is delegated to the overridden addChild() meth-
od:
Had we done it directly in the options setter, there would be no need for addChild() at all, so
why go the convoluted way? The answer is: to enable the potential use of RadioButtonGroup-
Box as a regular container, outside the renderer context. In other words, whenever a RadioBut-
ton gets added to the component – as part of the options or not – it gets associated with the
group.
Next, since we want the component as a drop-in renderer, we need to implement the IDropInLis-
tItemRenderer interface, so that the extra information about the hosting List will be at our fingertips:
And once we have the listData, we can offer the following override of the data setter of IDataRen-
derer:
Similarly, we consider both use cases of the standalone component and item renderer while imple-
menting the property value. In the case of the item renderer, our component updates the underly-
ing data:
Finally, how about capturing the selection of a radiobutton? Since we need to listen to the change
event on the RadioButtonGroup, we’ll set up the listener right in the constructor method, handling
the Event.CHANGE with the anonymous function:
The complete code of the RadioButtonGroupBox is presented in Listing 11.17. See if you can dis-
cover the discrepancies between the listing and what we outlined in our snippets. There are really
just a few things.
• We’ve added the text property so that in the item editor use case we don’t have to specify
editorValue=”value”.
• We’ve made the properties text and value bindable by “change” and “valueCommit” events,
dispatching events being done by the anonymouos Event.CHANGE handler and value setter
correspondingly.
• We allowed the dynamic re-assignment of options by removing the existing dynamic
RadioButtons before building new ones from the options array.
// RadioButtonGroupBox.as
package com.theriabook.containers
{
import flash.display.DisplayObject;
import flash.events.Event;
import mx.containers.Box;
import mx.core.IDataRenderer;
import mx.controls.dataGridClasses.DataGridListData;
import mx.controls.listClasses.BaseListData;
import mx.controls.listClasses.IDropInListItemRenderer;
import mx.controls.RadioButton;
import mx.controls.RadioButtonGroup;
import mx.events.FlexEvent;
import mx.core.mx_internal;
use namespace mx_internal;
group.addInstance(child as RadioButton);
}
return super.addChild(child);
}
[Bindable(“valueCommit”)]
[Bindable(“change”)]
public function get text():Object {
return value;
}
[Bindable(“valueCommit”)]
[Bindable(“change”)]
[Inspectable(category=”General”)]
public function get value():Object {
return group.selectedValue;
}
public function set value(v:Object) : void {
group.selectedValue = v;
if (listData && listData is DataGridListData) {
data[DataGridListData(listData).dataField] = group.selectedValue;
var event:CollectionEvent = new CollectionEvent(CollectionEvent.COLLECTION_
CHANGE, false, false, CollectionEventKind.UPDATE, -1, -1, [data]);
DataGrid(DataGridListData(listData).owner).dataProvider.dispatchEvent(event);
}
dispatchEvent(new FlexEvent(FlexEvent.VALUE_COMMIT));
}
_listData = value;
}
}
_options=opt;
To take the standalone RadioButtonGroupBox for a spin, we wrote the small application RadioBut-
tonGroupBoxStandAloneDemo presented in Listing 11.18. When you run it, Figure 11.9, you can
check that it’s still a normal Box container enriched with the ability to dynamically create as many
RadioButton controls as there are option values.
</mx:Array>
</fx:options>
<mx:HRule/>
<mx:RadioButton value=”R” label=”Retired”/>
</fx:RadioButtonGroupBox>
</mx:Application>
Now let’s test the itemRenderer/itemEditor scenario. Not that it’s required, but we would prefer to
lay out the radiobuttons horizontally. So, we’ll create RadioButtonGroupHBox as a simple exten-
sion of RadioButtonGroupHBox, taking care of the box’s direction and adding a couple of padding
pixels (the default Box padding is 0):
// RadioButtonGroupHBox.as
package com.theriabook.containers
{
public class RadioButtonGroupHBox extends RadioButtonGroupBox {
public function RadioButtonGroupHBox() {
super();
direction = “horizontal”;
setStyle(“paddingLeft”, “5”);
}
}
}
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” headerText=”Last Name” />
<mx:DataGridColumn dataField=”EMP_FNAME” headerText=”First Name” />
<fx:DataGridColumn dataField=”STATUS” width=”270” headerText=”Status”
rendererIsEditor=”true” itemRenderer=”com.theriabook.containers.RadioButtonGroupHBox”>
<fx:options>
<mx:Array id=”options”>
<mx:Object data=”A” label=”Active”/>
<mx:Object data=”T” label=”Terminated”/>
<mx:Object data=”L” label=”On leave”/>
</mx:Array>
</fx:options>
</fx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
} else {
setStyle(“color”, “green”);
}
}
}
]]>
</mx:Script>
</mx:Label>
</mx:Component>
</mx:itemRenderer>
</mx:DataGridColumn>
As you can see, we used Label, an immediate descendant of UIComponent, as a component base.
Why? Because updateDisplayList(), a UIComponent’s method, would be out of reach for a standard
DataGridItemRenderer based on the UITextField. Alernatively, we could have achieved the same
functionality with a more elegant binding expression syntax:
Listing 11.21 presents the complete code for the sample application StandardDynamicStyleDemo.
Besides the DataGrid, we’ve thrown in “Increase” and “Decrease” buttons that let us modify the
salary values in increments of 10k:
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<mx:DataGridColumn dataField=”SALARY” textAlign=”right”>
<mx:itemRenderer>
<mx:Component>
<mx:Label
color=”{data.SALARY>50000?255*256*256:255*256}”
/>
</mx:Component>
</mx:itemRenderer>
</mx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
When you run StandardDynamicStyleDemo, you’ll see the picture in Figure 11.11:
// Label.as (theriabook.swc)
package com.theriabook.controls
{
import mx.controls.Label;
}
}
As you can see, we’ve defined not one, but two styles – backgroundAlpha and backgroundColor
– and we use both values with graphics.beginFill() inside the overridden implementation of up-
dateDisplayList(). Once we add Label.as to theriabook.swc and register it in the component mani-
fest XML, the DataGridColumn can be redefined as in the following snippet:
</mx:Component>
</mx:itemRenderer>
</mx:DataGridColumn>
The difference between the approach above and the way we defined a similar DataGridColumn
in Listing 11.22 is that now we compute backgroundColor instead of the color and use fx:Label
instead of the one from mx namespace. If you do the replacement and run the program, you’ll see
the picture in Figure 11.12.
Despite the seemingly satisfying result, there’s something wrong here: using the powerful item ren-
derer mechanism to manage styles seems to be design overkill. Let’s speak our minds: we’re after
dynamic runtime styles, right? So, wouldn’t it be nice if we added an extra DataGridColumn attri-
bute, called, say, runtimeStyles, where we could list all styles and abstract from the implementa-
tion. Below is an example:
This approach would let developers concentrate on the substance rather than on the process. Let’s
make it happen.
package mx.controls {
public class DataGrid extends DataGridBase implements IIMESupport
{
public function DataGrid()
{
super();
itemRenderer = new ClassFactory(DataGridItemRenderer);
. . . . . .
}
}
}
We have to fight the temptation to replace the assignment of the itemRenderer with
Here is why. A ClassFactory instance is a “factory object,” which is used to generate instances of an-
other class (aka a generator class), with the newInstance() method. According to our plan we need
to intercept data changes to any instance of the generator class item renderer. Precisely, we’ll have
to listen to the FlexEvent.DATA_CHANGE event on every instance of the com.theriabook.controls.
Label created by “the factory.” Hmm, what could be simpler than adding the needed event listener
to the controls? That would be okay if we commit ourselves to fx:Label as the only item renderer
and by no means do we propose to take the power of custom item renderers away. To make the
runtimeStyles control mechanism agnostic to the type of renderer, we’d like to listen to FlexEvent.
DATA_CHANGE on the instances of any generator class.
It only sounds difficult. After all, a ClassFactory is nothing but an implementation of the IFactory
interface with a single property – properties and single method – newInstance(). That’s it. So we can
easily wrap a standard ClassFactory inside our custom one to intercept the newInstance() call. We’ll
call our wrapping class factory the UIClassFactory:
function DataGrid() {
super();
itemRenderer = new UIClassFactory(ClassFactory(com.theriabook.controls.La-
bel));
}
The constructor of the UIClassFactory would simply store the reference to the instance of the
real class factory – cf. Meanwhile UIClassFactory’s newInstance() would delegate the call to the
cf.newInstance(). It would also register the listener to the FlexEvent.DATA_CHANGE event as shown
below:
The complete code of UIClassFactory is presented in Listing 11.23. The only part of it that remains
uncovered is the onDataChange() handler.
//UIClassFactory.as
package com.theriabook.util
{
import mx.core.IFactory;
import mx.core.ClassFactory;
import mx.events.FlexEvent;
import mx.controls.dataGridClasses.DataGridColumn;
}
else
renderer.setStyle(style, runtimeStyles[style]);
}
renderer.invalidateDisplayList();
}
}
}
}
One chore is remaining. As long as we want to communicate the runtimeStyles to any item ren-
derer, including the ones that are individually set on a per-column basis, we need to route them
through our UIClassFactory. Accordingly we will modify our DataGridColumn and override the
implementation of the DataGridColumn’s itemRenderer setter:
// DataGridColumn.as
package com.theriabook.controls.dataGridClasses{
import com.theriabook.util.UIClassFactory;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.ClassFactory;
import mx.core.IFactory;
>
<fx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”EMP_LNAME” />
<mx:DataGridColumn dataField=”EMP_FNAME” />
<fx:DataGridColumn dataField=”SALARY” textAlign=”right”
formatString=”money”>
<fx:runtimeStyles>
<mx:Object
backgroundColor=”{function(item:Object):String {return
(item.SALARY>50000)?’red’:’green’;}}”
fontWeight=”{computedFontWeight}”
/>
</fx:runtimeStyles>
</fx:DataGridColumn>
</mx:Array>
</fx:columns>
</fx:DataGrid>
</mx:Application>
So far we’ve shown that it’s possible to control runtime styles via anonymous or explicit func-
tions (backgroundColor versus computedFontWeight in the demo application above). You can
take our approach further and completely outsource the dynamic styling to a separate con-
troller object flexibly instantiated via the getDefinitionByName() method. Come to think of
it, you’d completely shield developers from formatting and styling problems of a particular
project!
Let’s leave the reader with this thought and turn our attention from formatting to the editing side
of the DataGrid. Before we go there though, we’d like to take one more detour, introducing a couple
of additional controls: MaskedInput and NumericInput.
The first control of this section – MaskedInput – was created by Peter Ent from Adobe. We’ll be us-
ing it only for illustrative purposes and the code walkthrough of MaskedInput is beyond the scope
of this chapter. MaskedInput is a lightweight mask where you can indicate the maximum number
of positions in the mask and prescribe the type of the characters the user can type. The movement
of the insertion point is controlled by the control. For example, if you set a mask for entering a U.S.
phone number as (###) ###-#### in response to the end user typing 6175551212, the control will
display (617) 555-1212. Alpha keys will be blocked, but the completeness of the phone is up to the
user. The control is an extension of the mx.controls.TextInput and its text returns the “mask-free”
data input, i.e., 6175551212 in our use case. The main controlling property of MaskedInput is the
inputMask, which can consist of any characters except:
Like all other components in this chapter, we’ve added a MaskedInput to theriabook.swc and reg-
istered it in the component manifest file theriabook-manifest.xml. The only modifications we’ve
done to the original MaskedInput: changed the original packaging of the MaskedInput to com.
theriabook.controls and overrode the implementation of the TextInput data setter to accommodate
its use in the DataGrid:
The second mask that we present in this section is NumericInput. It doesn’t control the insertion
point so that typing and pasting isn’t restricted. However, it blocks any typing or pasting that con-
tains invalid characters. Here’s the first iteration of the NumericInput code:
// NumericInput.as
package com.theriabook.controls
{
import mx.controls.TextInput;
import flash.events.Event;
event.preventDefault();
That’s all it takes to bulletproof your input fields from undesired characters. Two more small patch-
es before we leave the NumericInput, though.
In the course of marshalling the Java data across the wire, chances are your numeric data will come
as Number.NaN, a direct counterpart of Java Double.NaN or Float.NaN. In general, unless you use
special DTOs with embedded null indicators, this is the natural way to marshal numeric nulls; no
one would appreciate the lettering NaN staring at the user instead of the empty cell. So, following
the established pattern, we’re going expand our NumericInput with a property value, then have it
produce the appropriate text required for presentation. Hence the following addition to Numer-
icInput code:
In the code fragment above we intervened in the setter for data property in case the NumericInput
is embedded in the DataGrid as a renderer. There we modify the value and let the value, in turn,
modify the text.
In the value getter we return the original content: null, undefined, or Number.NaN provided the
user hasn’t entered anything. Otherwise, we use a regular expression to convert the text to Number
globally, eliminating the spaces and thousand separators first:
_value = Number(text.replace(/,/g,””));
If you’re delivering your application to Brasil, you could create a similar or smaller file in the Flex
SDK/ 2/frameworks/locale/pr_BR folder, where you’d redefine decimalSeparator as “,” and thou-
sandsSeparator as “.”. Supposedly you’d keep the original name11 – validators.properties. Then you’d
modify compiler options for theriabook.swc to specify the pr_BR locale and rebuild NumericInput
after adding the following code:
import mx.resources.ResourceBundle;
. . . .
[ResourceBundle(“validators”)]
private static var rb:ResourceBundle;
Let’s move on to the testing application – NumericInputDemo. When you run it, try to type any-
thing but digits, commas, and dots into the “Number” column. You won’t be able to. Again, please
make no mistake: NumericInput is a lightweight mask and it doesn’t replace the need to validate.
In particular, if you like regular expressions as much as we do, you may base the validation of the
currency field on the mx.vaidators.RegExpValidator, applying the regular expression that’s the best
match for your use case, for instance, something like:
^\$?([1-9]{1}[0-9]{0,2}(\,[0-9]{3})*(\.[0-9]{0,2})?|[1-9]{1}[0-9]{0,}(\.[0-
9]{0,2})?|0(\.[0-9]{0,2})?|(\.[0-9]{1,2})?)
We leave it up to the reader to try. Another feature to notice while running the demo app is how
NaN, null, and undefined values are preserved in the absence of a meaningful input in the corre-
sponding cells:
The code of the testing application is shown below. The helper class NumberScope.as is presented
in Listing 11.28:
When you run it, try to type anything but digits, comma and dot into the
<?xml version=”1.0” encoding=”utf-8”?>
<!--NumericInputDemo.mxml -->
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”
xmlns:fx=”http://www.theriabook.com/2006”
layout=”vertical”
creationComplete=”onCreationComplete();”>
<mx:Script>
<![CDATA[
import mx.collections.*;
[Bindable]
private var collection:ArrayCollection;
private function onCreationComplete():void {
collection = new ArrayCollection ([
new NumberScope(124000.00),
new NumberScope(Number.NaN),
new NumberScope(null),
new NumberScope(undefined)
]);
}
]]>
</mx:Script>
// NumericInput.as
package com.theriabook.controls
{
import mx.controls.TextInput;
import flash.events.Event;
import mx.controls.List;
{
import mx.controls.listClasses.BaseListData;
import mx.events.FlexEvent;
import mx.controls.dataGridClasses.DataGridListData;
if (illegalCharacterFound) {
event.preventDefault();
}
}
}
}
As the reader is probably sensing by now, we are about to automate the programming of editors
with the same technique we applied for formatting. Namely, we’ll take the burden off developers’
shoulders and make DataGrid accountable for picking up and initializing proper item editors.
If you recall, mapping label functions, albeit anonymous ones, had been delegated to a separate
class, FormattingManager. Quite similarly, we are about to introduce an additional class Editing-
Manager, with a single method setFormat() so that our custom DataGridColumn will be calling it
right after it invokes the similar method of the FormattingManager:
// DataGridColumn.as
package com.theriabook.controls.dataGridClasses{
import com.theriabook.util.UIClassFactory;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.ClassFactory;
import mx.core.IFactory;
Its method setFormated has to assign the value of the itemEditor property for the column. The deci-
sion of which itemEditor to choose should be based entirely on the formatString. As you can see, the
setFormat() method carries all the required information in its signature, and column and formatting
information as method parameters. Before we go coding, let’s recap that itemEditor is a property of
type IFactory. When you set its value in MXML, the compiler automatically creates an instance of
ClassFactory, a class that implements the IFactory interface based on your class as “generator.” Our
approach is different and we’ll be creating the ClassFactory12 explicitly.
Here’s an example of creating the ClassFactory for the column with the “shortdate” format. We
create the ClassFactory based on the DateField and set its properties with an anonymous object
so that, ultimately, each instance of the manufactured DateField will have its formatString set to
“MM/DD/YY.” Not only do we assign the itemEditor to the DataGridColumn, we also specify the
editorDataField (DataGrid assumes the text property otherwise):
case “shortdate”:
cf = new ClassFactory(DateField);
cf.properties = { formatString : “MM/DD/YY”};
dgc.editorDataField=”selectedDate”;
dgc.itemEditor = cf;
break;
Like the “zip,” “phone,” and “ssn” formats, all of which conform nicely to MaskedInput, we encap-
sulate the assignment of itemEditor inside the helper function setMaskedEditor():
var cf:ClassFactory;
cf = new ClassFactory(MaskedInput);
cf.properties = {inputMask : mask};
dgc.itemEditor = cf;
}
The full code for EditingManager is presented in Listing 11.31. Note that, like FormattingManager,
we programmed the default case to handle the non-listed formatString with a “#” character in it as
an unknown mask:
// EditingManager.as
package com.theriabook.controls.dataGridClasses
{
import mx.core.ClassFactory;
import mx.controls.TextInput;
import com.theriabook.controls.MaskedInput;
import com.theriabook.controls.NumericInput;
import mx.controls.DateField;
cf = new ClassFactory(NumericInput);
dgc.itemEditor = cf;
break;
case “shortdate”:
cf = new ClassFactory(DateField);
cf.properties = { formatString : “MM/DD/YY”};
dgc.editorDataField=”selectedDate”;
dgc.itemEditor = cf;
break;
case “zip”:
setMaskedEditor(dgc, “#####-####”);
break;
case “phone”:
setMaskedEditor(dgc, “(###) ###-####”);
break;
default:
if (fs.indexOf(“#”)!=-1) {
setMaskedEditor(dgc, fs);
};
}
}
}
}
>
<fx:columns>
<mx:Array>
No application code to populate the DataGrid, no coding to display, no coding to edit. Just indicate
the format of the column and off you go. And, keep in mind our quest for DataGrid automation isn’t
over yet! Meanwhile, if you run the application it will resemble Figure 11.15:
The properties of each column could be derived from some external respository, for instance – a
database. But if we plan to dynamically assign properties like itemRenderer, we need to“train” our
UIClassFactory to dynamically create the generator object given its class name.
Let’s modify the constructor to allow String arguments in addition to ClassFactory ones. We will
loosen the strict definition of the argument type from ClassFactory to Object. In case of the String,
the constructor will attempt to load the correposnding class definition dynamically13 and then cre-
ate the matching ClassFactory:
} else {
throw new Error(“Invalid argument for UIClassFactory constructor”);
}
}
As soon as you think “definition by name,” you have to ask yourself: “Is the class definition acces-
sible?” If the answer is positive, it means you are confident about the way you build and load your
SWFs. To force SWF to contain an application-specific class, you can simply declare a variable of
the class. We don’t find this appropriate for libraries, hence the need for the library initialization
sections that we explained in Chapter 9. Following the pattern established in Chapter10, we’ll cre-
ate theriabook.mxml, theriabook_code.as and build.xml files in the root of the theriabook project.
Below is Listing 11.33 of theriabook_code.as. The other two files we will omit for brevity’s sake (you
can find them on the accompanying DVD):
//theriabook_code.as
package {
import mx.core.SimpleApplication;
import com.theriabook.containers.*;
import com.theriabook.controls.*;
import com.theriabook.controls.dataGridClasses.*;
import com.theriabook.formatters.*;
import com.theriabook.util.UIClassFactory;
}
}
Using build.xml we will run Ant to build the theriabook.swf. As per the DVD version of the code,
the Flex application folder for this chapter has been named AdvancedDataGrid and build.xml cre-
ates theriabook.swf in C:/fds/jrun4/servers/default/theriabook/AdvancedDataGrid. Accordingly, in
the AdvancedDataGrid project, we will to go to Properties->FlexBuildPath-> LibraryPath and turn
the Link Type for all SWC entries to RSL/AutoExtract(YES). Then we will remove the reference to
theriabook project as “SWC Folder”, adding instead a reference to theriabook.swc as a file. We will
set the Link Type of theriabook.swc to RSL/AutoExtract (NO), since we have already produced the
SWF during the Ant step.
Now we are fully prepared to cut the application code, which is presented in Listing 11.34:
//import com.theriabook.containers.RadioButtonGroupHBox;
//private var linkage:Object={a:com.theriabook.containers.RadioButtonGroupHBox};
{data:”L”,label:”On leave”}
]
}
];
dp=[
{firstName:”Anatole”, lastName:”Tartakovsky”, phone:”7141237890”,
status:”A”},
{firstName:”Victor”, lastName:”Rasputnis”, phone:”3053425470”, status:”L”},
{firstName:”Yakov”, lastName:”Fain”, phone:”2013335748”, status:”A”}
];
var columns :Array = new Array();
for ( var i:int = 0; i < cols.length; i++) {
var dgc:DataGridColumn= new DataGridColumn();
for (var prop:String in cols[i]) {
if (prop==”itemRenderer”) {
dgc.itemRenderer = new UIClassFactory(cols[i][prop]);
dgc.rendererIsEditor=true;
} else {
dgc[prop] = cols[i][prop];
}
}
columns.push(dgc);
}
dg.columns = columns;
}
]]>
</mx:Script>
<fx:DataGrid id=”dg” dataProvider=”{dp}” editable=”true” height=”100%” >
</fx:DataGrid>
</mx:Application>
Please notice two arrays: cols, with metadata for DataGrid columns, and dp, with the dataProvider-
to-be data. Both arrays get hard-coded inside the onCreationComplete() method, but you can eas-
ily imagine how they get loaded, say, from a database.
Right above the onCreationComplete() there are commented-out imports of the RadioButton-
GroupHBox and the linkage variable declaration. These lines, if left to compile, could absolve us
from turning the theriabook.swc into a self-initialized library. But, how can we know in advance
which class definitions are required by the column’s metadata if it gets loaded from the database?
We can’t and, again, we recommend making libraries self-sufficient as a “rule of thumb.”
The last comment to the application concerns the way we’ve assigned DataGridColumn proper-
ties: we clearly sided out itemRenderer to make the corresponding UIClassFactory (had we wanted
to, a similar route would have been taken for itemEditor):
Figure 11.14 depicts the DataGridAutomation running14. We hope it sparks the reader’s interest in
dynamic applications. What could be next here? Well, the structure of the metadata cols, resembles
one-to-one the MXML section of the DataGridColumn definitions. So, we could possibly store the
MXML in the database and interpret it with ActionScript as E4X. Potentially, we could even allow
interactive editing of such MXML, making it a self-modifying program. But this would take us way
beyond the boundaries of this chapter15.
background of the application, but underneath this veneer it’s still a good old DataGrid.
Both DataGrids share the dataProvider – the ArrayCollection based on an array of ColumnRecord
types:
//ColumnRecord.as
package
{
public class ColumnRecord
{
public var columnLabel:String;
public var columnType:String;
public var columnValue:*;
public var expando:Object;
[Bindable]
private var dp:ArrayCollection;
private function init() :void {
dp= new ArrayCollection ([
return rbgb;
case “checkbox”:
var cb:CheckBox = new CheckBox()
cb.offValue = data.expando.offValue;
cb.onValue = data.expando.onValue;
return cb;
case “money”:
return new NumericInput();
case “date”:
Notice the property preventRendererReuse. It’s a property that we are going to introduce to toggle
certain default functionality of the DataGrid on and off. As mentioned earlier, the DataGrid main-
tains a pool of reusable renderers per column. This is done for performance reasons to avoid the
proliferation of renderers for each row of the dataProviders collection. Since our use case – the
property bag – doesn’t assume many hundreds of lines, we’ve turned this functionality off, forcing
the DataGrid to dynamically create a renderer for each line anew.
Next, notice how itemRenderer isn’t assigned a ClassFactory, or even a String, but rather a function
that calculates the generator for the UIClassFactory based on the data. At the end of the day we
rely on the quite simple application function controlPicker(), but the ability to pass Function as an
argument to the UIClassFactory is another implementation task for us to accomplish.
Last, we introduced an additional DataGrid property – rendererData – that captures the last item
the IViewCursor passed through, assigning the data to the renderer.
Now let’s look at the implementation details. We’ll start with UIClassFactory. In the previous sec-
tion we made the UIClassFactory constructor accept the String argument. Here we add a private
variable factoryFunction and modify the constructor again to take the Function in addition to the
ClassFactory and String:
Appropriate provisions have to be made in the newInstance() method. Namely, when it’s time to
manufacture an object via factoryFunction we invoke the function with the call operator() and then
make sure the newly made object has the same properties as other instances do:
obj = factoryFunction();
// Now we have to do what regular ClassFactory does by itself
if (properties != null) {
for (var p:String in properties) {
obj[p] = properties[p];
}
}
} else
obj = wrappedClassFactory.newInstance();
obj.addEventListener(FlexEvent.DATA_CHANGE, onDataChange);
return obj;
}
// UIClassFactory.as
package com.theriabook.util
{
import mx.events.FlexEvent;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.ClassFactory;
import mx.core.IFactory;
} else {
throw new Error(“Invalid argument for UIClassFactory constructor”);
}
if (wrappedClassFactory) {
wrappedClassFactory = new ClassFactory(Object);
}
}
renderer.invalidateDisplayList();
}
}
}
}
Now let’s look at the finalized code for our custom DataGridColumn, Listing 11.38. Notice the defi-
nition of the preventRendererReuse variable, which will be used a bit later by the DataGrid class. We
also modified the itemRenderer setter slightly. Instead of:
we do
to avoid wrapping on top of wrapping, when the passed value is already an UIClassFactory.
//DataGridColumn.as
package com.theriabook.controls.dataGridClasses{
import com.theriabook.util.UIClassFactory;
import mx.controls.dataGridClasses.DataGridColumn;
import mx.core.ClassFactory;
import mx.core.IFactory;
EditingManager.setFormat(this, fd);
}
The last class to be modified in this chapter is the DataGrid itself. We’ll introduce a new read-only
property, rendererData, which gives us the latest value that has been scanned over by the iterator,
a protected member of the mx.controls.listClasses.ListBase:
if (columnMap[item.name]){
var c:Object = columnMap[item.name];
//Commented out 3 lines of original addToFreeItemRenderers
//com.theriabook.controls.DataGrid
package com.theriabook.controls {
import mx.controls.DataGrid;
import com.theriabook.controls.dataGridClasses.DataGridColumn;
import com.theriabook.controls.Label;
import com.theriabook.util.UIClassFactory;
import flash.display.DisplayObject;
import mx.controls.Alert;
import mx.controls.listClasses.IListItemRenderer;
import mx.core.ClassFactory;
import mx.managers.CursorManager;
import mx.rpc.AbstractOperation;
import mx.rpc.events.*;
import mx.rpc.remoting.mxml.RemoteObject;
function DataGrid() {
super();
itemRenderer = new UIClassFactory(new ClassFactory(Label));
}
return data;
}
if (columnMap[item.name]){
var c:Object = columnMap[item.name];
delete columnMap[item.name];
}
item.parent.removeChild(DisplayObject(item));
} else
super.addToFreeItemRenderers(item);
ro = new RemoteObject(destination);
ro.showBusyCursor = true;
ro.concurrency = “last”;
ro.addEventListener(ResultEvent.RESULT, ro_onResult);
ro.addEventListener(FaultEvent.FAULT, ro_onFault);
}
var operation:AbstractOperation = ro.getOperation(method);
operation.arguments = args;
operation.send();
}
private function ro_onFault(evt:FaultEvent):void {
CursorManager.removeBusyCursor();
Summary
This chapter concentrates on the automation of DataGrid programming through what we call the
data-driven approach. Along these lines we’ve extended the concept of destination-aware controls
to the DataGrid, customized controls like CheckBox, created new ones like RadioButtonBox and
NumericMask, and introduced computed styles and computed editors. The turnpoint techniques
introduced in this chapter have been the custom DataGridColumn and UIClassFactory.
If you’ve made it this far, you’ll probably change the way you’ve dealt with DataGrid. Most impor-
tantly, your work with DataGrid will become more productive and enjoyable.
Endnotes
1. As a reminder, all custom controls we hereafter add to theriabook.swc, extending the manifest and check-
ing the appropriate checkboxes under project properties/Flex Library Build Path-/Classes.
2. We omitted replicating the DataGridColumn code here, but please count this as the second version.
3. The content of FormattingManager may be modified on a per-project basis. Alternatively, you can come
up with a strategy that allows dynamic selection and loading the proper FormattingManager.
4. In fact, a quick peek in the generated folder can reveal that inline components references cause genera-
tion of three files.
5. The bigger underlying topic is the role of undefined in the data collection edited via the DataGrid. As a
use case let’s consider the DataGrid exposing combined data from two different arrays, which share all
but a few attribites. The DataGrid will show missing attributes – undefined – as empty cells. Once you
click on such a cell and leave it, DataGrid will attempt to dynamically create the property on the underly-
ing ActionScript object – that alone would fail on the sealed object – and then assign null to it. That might
6. Theoretically, you could go as far as to start assigning item renderers even to the text fields. In that case
there would be no need to declare DataGrid editable as long as your item renderers take care of changes
in the underlying data collection.
7. We could have gone further and upgraded <fx:options> to <fx:dataProvider> like the ButtonBar and Link-
Bar controls.
8. You may want to compare this situation with the HBox use merely for centering the CheckBox, which we
advocated against in the previous section. Back there, using an extra container was a luxury, expensive
as luxury items often are. Here we face the alternative of reusing the container versus developing a new
implementation for the whole set of interfaces: IFlexDisplayObject, ILayoutManagerClient, ISimple-
StyleClient, IUIComponent.
9. We can hear the inquisitive reader wondering about the performance implications of this solution, since
we’ve replaced the ultra-light UITextField with a heavier UIComponent-Label. The answer is that given
that the DataGrid recycles item renderers – by maintaining a pool of them to cover the visible portion of
the column – possible damage is limited by the number of visible rows. You may conduct your own stress
tests, although ours haven’t shown any noticeable difference.
10. As a reminder, to cancel the default event behavior with preventDefault() the event should be cancelable
in the first place. You can check the latter via cancelable property of the event object.
11. That would be a good decision after all, since mx.validators.NumberValidator also looks for this file.
12. Again, all object instances manufactured by a ClassFactory share the same initial values of their
properties: the ClassFactory method newInstance() doesn’t take parameters and all future values
of the properties are preset upfront as attributes of the dedicated properties object on the Class-
Factory itself.
13. The method getDefinitionByName() will throw a ReferenceError in case the class image isn’t found in the
application or RSL SWFs.
14. When it comes to dynamically loaded libraries, during development we recommend Debug as…versus
Run as…to avoid Alerts, one per loaded RSL that come during the application startup. Please be assured
that these Alerts come only on developers’ machines that have a debugging version of the Flash Player
installed; your users are not going to see them.
15. This is exactly what is happening behind the scenes of FlexBI, a reporting/Business Intelligence product
and solution created by FarataSystems. FlexBI allows business users to modify layout, sorting, grouping
and formulas of their reports on the fly and persists these settings in the database; see http://www.myflex.
org for more information.
12
No, this chapter is not about how to use the Flex Builder debugger. In this chapter we’ll discuss the
techniques of logging and debugging mixed Flex/Java projects with or without Flex Builder.
Flex comes with a set of logging facilities and some prebuilt loggers. It also includes a blueprint of
client logging and implementation utilizing tracing, which is built into the debug version of the
Flash Player. We’ll start by covering the standard Flex logging facilities and use cases.
Logging
Typically, you use logging to solve the cases that can not be solved using the debugger. For example,
if you try to validate the code that implements drag-and-drop, the Flex debugger will keep inter-
rupting the program event flow and make debugging impossible.
Another use case for logging would be the need to test code on the communication protocol level,
i.e., you’d like to know what’s happening under the hood during RPC and FDS calls. In the case of
errors, developers often don’t even have error handling code and can not easily identify the prob-
lem.
Also, there may be issues on the server, and they are not necessarily reported in full to the client.
Flex supports both client- and server-side logging, and it allows you to trace client/server messages
both on the client and the server. Let’s take closer look.
• You might want to log the methods being called as well as the data exchange between the cli-
ent and server.
• You’re using the server-side Flex compiler and need to log errors for the developers or support
personnel.
Applications that use Flex Data Services can utilize an extensive set of prebuilt logging features
in the communication and execution packages. You can trace the inner workings of the system
classes by using a detailed hierarchy of loggers. It’s a bit different from Java logging where you
create loggers based on the package/class hierarchy. Adobe uses a logical hierarchy of the loggers
that’s not directly related to the package structure, but you can select the layer with a pattern or
particular end node that will help in logging the types of operations you are interested in. The logi-
cal categories for logging are listed below:
Configuration,
DataService.[* |General | Hibernate | Transaction],
Endpoint.[* | AMF | HTTP | RTMP | Deserialization |General],
Message.*, Message.Command.[* | subscribe | unsubscribe | poll | poll_interval |
client_sync | server_ping | client_ping | cluster_request | login | logout],
Message.General
Message.Data.[* | create | fill get | update | delete | batched | multi_batch |
transacted | page | count | get_or_create | create_and_sequence | get_sequence_id
| association_add | association_remove | fillids | refresh_fill | update_collec-
tion],
Message.RPC , MessageSelector ,
Resource ,
Security
Service.[* | Cluster | HTTP | Message Message.JMS | Remoting]
Brackets represent a choice of a pattern; for example, you can specify the logging category Data-
Service.General. The code snippet below has some samples of using these patterns in the section
filters.
You can log into a system console (Java’s System.out.println) or use regular logging configured with-
in the Web application servlet context (context.log) by specifying the class attribute of the target file
in the configuration. Below are some typical settings in /WEB-INF/flex/services-config.xml:
<logging>
<!-- You may also use class=”flex.messaging.log.ServletLogTarget” -->
<target class=”flex.messaging.log.ConsoleTarget” level=”Error”>
<properties>
<prefix>[Flex] </prefix>
<includeDate>false</includeDate>
<includeTime>true</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>true</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>
The logging-level attribute can have one of the following values: all, debug, info, warn, error, or
none.
You can also control the output of the server-side MXML compiler. You can log messages sent to
the Web application server’s logging mechanism by using the log-compiler-errors property in the
/WEB-INF/flex/flex-webtier-config.xml file. The Web application logger does not log runtime mes-
sages, but only logs server-side compiler messages.
To log compiler errors to a file or console, you must set the value of the tag <production-mode> to
false and <log-compiler-errors> to true.
<production-mode>false</production-mode>
…
<debugging>
<log-compiler-errors>true</log-compiler-errors>
</debugging>
The location, number of backups and log file sizes are specified in the logging
block of the flex-webtier-config.xml file.
<logging>
<level>info</level>
<console><enable>true</enable></console>
<file>
<enable>true</enable><file-name>/WEB-INF/flex/logs/flex.log</file-name>
<maximum-size>200KB</maximum-size>
<maximum-backups>3</maximum-backups>
</file>
</logging>
When switching to production mode, always switch the logging level to info or errors as logging
tends to be expensive since it accesses the file system and performs data serialization. Don’t forget
that verification of the logging levels in the code is target-oriented versus a typical Java package/
class granularity, and this presents additional performance challenges. The same applies to the
logging organization on the client. We will illustrate this in detail in the next section.
Client-Side Logging
There are two commonly used techniques for logging the Flex programs. First, the debugging version
of the player provides a built-in global function trace(). Its output goes to the file flashlog.txt that’s
located in the same folder as mm.cfg file. Please refer to the product documentation to find the name
of the folder in your OS (see http://livedocs.macromedia.com/flex/2/docs/wwhelp/wwhimpl/com-
mon/html/wwhelp.htm?context=LiveDocs_Parts&file=00001528.html). If you don’t file mm.cfg in
this directory, create one with the following content:
ErrorReportingEnable=1
TraceOutputFileEnable=1
TraceOutputFileName=c:\flexLog.txt
MaxWarnings=50.
In mm.cfg, you must set TraceOutputFileEnable to 1, and you can set a custom value for TraceOut-
putFileName. More important, trace() automatically goes to the console panel of the Flex Builder. It’s
a good way to start tracing, similar to System.out.println in Java. The only difference is that the latter
works in both debug and runtime modes, while the function trace() works only in the debug mode.
The second approach is to use the Logging API, which allows developers to control logging based
on two parameters – levels and categories – in a more convenient way. It also allows developers to
create and designate targets – classes responsible for writing the logging messages to some output
media, which can be local resources, server logs/messaging, or even a remote workstation used for
debugging/support.
In the code snippet above, MyCategory is just a logical name that is not linked to any real class name.
This code is quite generic and does not specify where to output messages. Flex includes two standard
targets: TraceTarget and MiniDebugTarget. TraceTarget uses trace to write out the messages and re-
quires you to use a debugging version of the player and to do the trace setup described earlier. MiniDe-
bugTarget uses LocalConnection to transfer messages to other Flash/Flex applications. Here is a sam-
ple of setting TraceTarget with some formatting to include time and level along with the message:
While TraceTarget is good for some cases, it’s important that a developer has the option to output to
other services such as a server log, remote workstations, or OS consoles. Let’s create other targets.
package com.theriabook.logging;
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
Once compiled, deployed, and registered with Flex Remoting, the server-side Java class
ServerFlexLogger is ready to be called from the client-side ActionScript class ServerTar-
get:
package com.theriabook.util.logging {
import mx.logging.LogEvent;
import mx.rpc.remoting.RemoteObject;
import mx.rpc.events.FaultEvent;
import mx.logging.AbstractTarget;
import mx.logging.LogEventLevel;
We had to limit the logging of the messages from the mx.messaging and mx.rpc packages to avoid
getting into an endless loop. The reason is that mx.messaging and mx.rpc packages contain their
own logging messages about internal communication processes that allow application developers
to debug the flow of server communications, and these messages can pile up pretty fast.
package {
import mx.logging.AbstractTarget;
import flash.net.URLRequest;
import flash.net.sendToURL;
import mx.logging.LogEvent;
import mx.logging.ILogger;
import flash.net.URLVariables;
In the application object we need to instantiate SocketTarget with the URL “logging”.
</mx:Application>
We will also need to convert the Java class from Listing 12.1 into a servlet:
package com.theriabook.logging;
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
You might want to include the client’s IP address and the user information in the log in order to
distinguish the output from multiple clients.
package {
import mx.logging.LogEvent;
import mx.logging.AbstractTarget;
import mx.logging.Log;
import flash.events.StatusEvent;
import flash.net.LocalConnection;
import mx.controls.Alert;
import mx.logging.LogEventLevel;
import mx.logging.ILogger;
}
}
}
The class LocalConnectionTarget can be used to deliver logging messages to any client application
that either embeds a Flash component or implements LocalConnection with a native implementa-
tion using low-level programming languages. The code that comes with the book includes a free
native implementation for the Windows platform of a console application that allows you to output
the log to the display monitor, the files, and the Windows native debugging log (see http://www.
microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx).
Listing 12.8 provides sample code to direct the log messages to our panel:
<mx:Script>
<![CDATA[
import flash.net.LocalConnection;
import mx.controls.Alert;
conn.addEventListener(AsyncErrorEvent.ASYNC_ERROR, showError);
} catch (error:ArgumentError) {
Alert.show(“Can’t connect. The connection name is already being used by another SWF” +
error.message);
}
}
The LoggingGrid component (see Listing 12.8) is inherited from the DataGrid:
A logging manager should support the following functionality on the client side:
• Automatically discover and list logging categories, and allow change in the logging level for
each category or package.
• List registered targets/destinations, and set a default logging level and other common param-
eters.
• Provide the client-side persistence of logging settings.
Figure 12.2 shows a sample logger panel that meets all of the above requirements.
Figure 12.3 shows an extension to our LoggingGrid component that provides client-side filtering,
searching, and other custom logging functions.
There are a number of freeware and commercial components that allow you to direct and show
logging data in Eclipse, a Web browser, and a standalone application. You can find a free open
source tracing console called XPanel at the following URL: http://www.faratasystems.com/
?page_id=45.
Debugging
In this section we’ll go through some scenarios of debugging Java server-side code deployed in one
of the Java EE application servers. We’ll discuss two modes:
• Remote Debugging: When you can connect to a running application server through a dedi-
cated port and debug your Java application
• Internal Debugging: When you start your application server inside the Eclipse IDE and then
debug the code according to set breakpoints
Remote Debugging
We’ll illustrate remote debugging, assuming that you’ve installed Flex Data Services with the inte-
grated JRun server, even though you can apply the same techniques with other Java EE application
servers. The plan is to engage the Java Platform Debugger Architecture (JPDA), which allows you to
debug applications (JRun in our case) running in a JVM. Besides running the server, JVM will also
listen to a particular port, and the Flex application that we’d like to debug will attach to this port for
debugging the server-side Java code.
Usually, you start the JRun server by opening the command window and typing the following (it’s
the Windows version):
JRun uses settings from the configuration file jvm.config located in the bin directory of JRun. Our
goal is to start JRun in the debug mode, and to do this we’ll modify the file jvm.config.
After your JRun instance is started in the debug mode, you need to create the Eclipse debug con-
figuration for this remote Java application. Select the menus Run | Debug and right-click the option
Remote Java Application (see Figure 12.4).
In the popup window enter the name of the Eclipse Java project you’d like to debug that contains code
deployed under JRun, as in Figure 12.5. Please note that the port number should match the one specified
in JRun’s file jvm.config. As an example, we are using the Java Order Entry application from Chapter 7.
Figure 12.5 Mapping the Eclipse Java project to JVM’s JPDA port
This is pretty much it. Now you can set your breakpoints in the Java source code, which has to cor-
respond to the code deployed in JRun.
Figures 12.6 and 12.7 show the snapshots of the Eclipse debugger perspective, illustrating break-
points in both ActionScript and Java source code.
If we are able to start the server inside Eclipse, the rest is easy: just set your breakpoints in the
server-side Java code and off you go.
There could be different ways of doing this – in some cases it’s just a matter of configuring your
server’s startup runtime in Eclipse. An alternative way is to find and install the Eclipse plugin for
your Java EE server.
A more generic way is to use an open source Eclipse project called the Web Tools Platform (WTP),
available from the Eclipse Foundation at the following Web site: http://www.eclipse.org/webtools/.
While Eclipse WTP adds various useful tools for the development of Java EE and Web applications,
we’ll just explore how it can help us debug Java code deployed in application servers.
The easiest way to get WTP is to download its all-in-one zip file from http://download.eclipse.org/
webtools/downloads/. It contains the Eclipse IDE with all required plugins. At the time of this writ-
ing, WTP 1.5.x is meant for Eclipse 3.2 and WTP 1.0.x works with Eclipse 3.1.
To install this version of Eclipse with preconfigured WTP, simply unzip the contents of this file on
your disk drive. Reinstall the Flex Builder plugin and start Eclipse, pointing at the workspace with
your Flex projects.
Configuring Tomcat
After installing WTP, you’ll find a new perspective called J2EE. Open it, go to the menu Windows |
Preferences, and you’ll find some new items there – one of which is called Server. Let’s add Tomcat
as our default server by selecting Installed Runtimes under the Server item. After pressing the but-
ton Add you’ll see a popup window listing a number of Java EE servers such as WebLogic or JBoss. If
you don’t see the one you’re looking for (i.e., IBM’s WebSphere), click on the “Don’t see your server
listed? Click Here” link shown in Figure 12.8.
Select Apache Tomcat 5.5, and specify its installation directory as in Figure 12.9.
Create a new Dynamic Web project called Portfolio_Java, where Tomcat is a target (menus File |
New Project | Web | Dynamic Web project).
We’ll ask WTP to create a JavaServer Page file HelloWorld.jsp to pay respect to Hello World and
ensure that we can debug any Java Web application. Just imagine that we are not debugging Hel-
loWorld, but the Order Entry from Chapter 7, or TickerFeed.java from Chapter 5.
Open J2EE perspective and right-click on the WebContent under Portfolio_Java project. Select the
menus New | JSP, enter the name HelloWorld, and the boilerplate JSP code will be created in a sec-
ond.
We’ll just add one line <% out.print(“Hello World!!”); %> between the HTML <body> and </body>
tags and set a breakpoint on this line (see Figure 12.10).
Finally, let’s start HelloWorld.jsp under Tomcat in the debug mode: right-click on HelloWorld.jsp
and select the options Debug As | Debug on Server. These actions will start Tomcat inside Eclipse,
and it’ll open the debugger perspective as soon as it reaches our breakpoint. The screenshot from
Figure 12.11 looks familiar, doesn’t it?
If you just want to start the server without running any Web application, open the server’s view in
the J2EE perspective, right-click on the server, and press the Start button.
In this section we’ve been using Apache Tomcat, but the same debugging techniques work for other
Java EE servers as well.
In this case, install and run the Java application server on your development machine, unzip the
.war file into a separate directory, and deploy it in the exploded form from this directory. Make sure
that the Flex Builder compiler’s options of your project include the option services pointing at the
services-config.xml.
Note: This solution will work if your Flex Builder project type is Flex Data Services.
Summary
It’s hard to overestimate the importance of debugging and logging in distributed Web applica-
tions.
In this chapter we’ve shown different tools and techniques that can help you to prevent or localize
and fix development and production problems in Flex/Java applications.
13
By Ben Stucki
In this chapter we’ll be building a narrated slideshow application in Flex 2 that will use the popular
Flickr (www.flickr.com) Web Services to retrieve the photos. Users will also be able to input a cus-
tom URL as the photo or audio location and have a few extra settings and image effects that can
be applied at runtime. When users are done creating slideshows, the application will provide them
with a URL that others can use to view the result.
This application may be handy for Flickr users who want to share their personal photos with friends
and family in a slideshow format, but it could be used for a number of business purposes as well.
For example, a realty company may want to display photos of a property narrated by the local real-
tor, or a car dealership may want to do the same for its cars. Some businesses may even use the
application to give presentations similar to those Microsoft PowerPoint would provide.
No matter what the end result is, we want users to experience RIAs at their best. We’ll make the ap-
plication so that users spend no more time creating a slideshow than they would spend watching
it. Hopefully, with correct planning, you’ll spend no more time developing it than you would spend
reading this chapter. Fortunately, Flex 2 makes both of these goals possible. Let’s take a look at what
we’ll be building.
Application Overview
The application will have two primary states: design and preview. We’ll start by developing a few
components of the preview portion of the application. It will contain all the functionality needed to
view and navigate a slideshow, including the timing control, audio playback, image effects process-
ing, and a thumbnail preview of each image for navigation. The design state will let users explore
photos from flickr.com, add and remove photos from the slideshow, include audio, and set the tim-
ing and effects for each photo (see Figure 13.1).
Like most RIAs, this application is going to include a number of custom components that are used
together to create a unique experience. These components include the thumbnail scroller shown in
Figure 13.1 as well as the SlideShow component that we’ll be developing in a moment. We’re also go-
ing to cover timer events, working with the HTTPService control and creating rich user interfaces with
ActionScript 3. We’ve got a lot to go over, so let’s get started by designing the SlideShow component.
Notice that I’ve set the horizontalScrollPolicy and verticalScrollPolicy attributes to off on the Can-
vas and have given the Image an ID of image. We’re going to be adding some ActionScript to this
component later, so it’s important that we can modify the image through code without creating
unnecessary scrollbars. I’ve also included some styling attributes with this component to make it
look a little more SlideShow-like. These attributes are available because they are part of the Canvas
component, which SlideShow is inheriting, but they can be overridden when the component is
included in an application.
To test our component we’ll have to create an application. In your application directory, create a
new file named SlideShowPlayer1.mxml. Simply declare your component’s namespace and use the
filename as the MXML element as shown in Listing 13.2.
Compile and run your application and you should see a large blank Canvas (see Figure 13.2) with
the styling attributes you’ve set in the component.
We’re going to add some ActionScript to the application and SlideShow component in a while to get
our images working, but first we need to take a look at how slideshow data is represented.
In this chapter we’re only displaying a single image at a time and using a single audio track to synch
with the images, so the above XML format is all the data we need. However, this format could be
expanded to create a more advanced application.
Now that we’ve got some slideshow data, let’s pull it into the application using an HTTPService
object in MXML and feed the result into our SlideShow component as shown in Listing 13.4.
When our application starts, it will now make a request for test.xml and pass the result to the Slide-
Show’s loadShow method. However, the Slideshow component from Listing 13.1 doesn’t have a load-
Show method yet. We’ll need to add this method by creating the public function in the component
file. There, we can also add the preloading functionality required. We’ll need to include a ProgressBar
MXML component and some variables to hold the loaded content as shown in Listing 13.5.
import mx.collections.ArrayCollection;
import flash.display.Loader;
[Bindable]
private var _xml:XML;
private var photos:ArrayCollection = new ArrayCollection();
private var sound:Sound;
private var iLoaded:uint = 1;
private var isLoaded:Boolean = false;
In the code above we’ve used ActionScript to create a Loader object for each image and store it in an
ArrayCollection. The loadShow event kicks things off by loading the value of the source attribute for
each photo node (represented by the variable photoNode) into a new Loader object and attaching event
listeners for the Progress and Complete events. The Progress event will be broadcast each time a sub-
stantial chunk of data has been downloaded from the file. This lets us update the ProgressBar MXML
component programmatically to display the download progress (provided by the Loader object) to the
user. When the images are done loading, the Complete event triggers the onComplete method, which
loads the audio file in the same manner. Preloading makes audio and image syncing much simpler.
Since we know the audio and images will begin playing at the same time and that new images will
display immediately when requested, we can simply represent syncing by assigning a time dura-
tion to each photo. When all the audio and images are loaded, we display a LinkButton Play to the
user. The play functionality isn’t implemented yet, but you can compile and run this application to
test the loading and progress bar functionality (see Figure 13.3).
Figure 13.3 Running SlideShow2: loading images and the progress bar
We’ve also included a function to stop the slideshow and display the play button again once the
slideshow has finished. This will let users replay the slideshow after their first viewing, but there’s
still no way to navigate from slide to slide while you’re watching.
After adding the code from Listing 13.6 to the SlideShow component, we need to add the call to the
playShow() method in the SlideShowPlayer.mxml. For example:
}
else {
this.contents.x += momentum;
}
this.filters = new Array(new BlurFilter(Math.abs(momentum)/2-3, 0));
}
]]>
</mx:Script>
<mx:HBox id=”contents” clipContent=”true” width=”100%” height=”100%”
verticalAlign=”middle” />
</mx:Canvas>
In this code the display objects are kept in a single container named contents so that they
can be moved in unison. The set method for the dataProvider is used to clear any existing
children in the contents object and create a new instance of the itemRenderer for each item
in the dataProvider. This way, the component provides similar functionality to Flex’s TileList
component, but it has a significantly different user interface. The Scroller tiles each gener-
ates an item in a horizontal row and provides automatic scrolling based on mouse position.
This rich interactive behavior is defined inside the onEnterFrame method (which is a listener
for the ENTER_FRAME event). It moves the contents’ position based on the position of the
mouse relative to the center (width/2) of the component. The constants SENSITIVITY and
FRICTION can be used to adjust the component’s mouse sensitivity and speed degradation,
respectively. It’s ideal for our thumbnail display since space is limited. We’re going to add it to
the SlideShow component and bind it to the data we already have by adding some MXML to
our SlideShow component as shown in the code snippet in Listing 13.8 (see the complete code
of the SlideShow in Listing 13.11).
<lib:Scroller dataProvider=”{_xml.photo}”
itemRenderer=”com.theriabook.controls.SlideThumb”
width=”100%” height=”85” bottom=”0” />
Notice that in Listing 13.8 we’ve referenced com.theriabook.controls.SlideThumb as the item ren-
derer. The SlideThumb component simply displays an Image inside a Canvas control. When the
Scroller generates this component it will assign each instance the correct xml node using the data
property. We just need to bind the Image’s source attribute (see Listing 13.3) to data.@source as in
Listing 13.9 and our custom itemRenderer will load the image as expected.
<?xml version=”1.0”?>
<mx:Canvas xmlns:mx=”http://www.adobe.com/2006/mxml” width=”75” height=”75”
buttonMode=”true” horizontalScrollPolicy=”off” verticalScrollPolicy=”off” horizontalCen-
ter=”0” verticalCenter=”0” >
<mx:Image id=”image” source=”{data.@source}” width=”75” height=”75” horizontalCen-
ter=”0” verticalCenter=”0” />
</mx:Canvas>
We can also include rich interactive behavior by adding code to the SlideThumb’s enterFrame event,
which measures the distance from this image to the mouse position and uses the value to set the image’s
width, height, and alpha transparency between a hard-coded maximum and minimum value. Insert the
code from Listing 13.10 in the SlideThumb component and use the initialized event to invoke the init
function. This will give each thumbnail fluid resizing behavior based on mouse position.
<mx:Script>
<![CDATA[
private function init():void {
this.addEventListener(Event.ENTER_FRAME, onEnterFrame);
}
All of the components for the SlideShowPlayer have been created, but we still need
to add code that will navigate to any given slide based on the user’s thumbnail selec-
tion.
Let’s create a gotoSlide method in SlideShow.xml and use the Scroller’s change event to pass
it the correct slide index. The method will need to loop through each node in the XML and
sum the duration where the slide at the given index begins. It will then reset the sound to
play, starting at the correct time, and set the current photoIndex and nextPhotoTime to dis-
play the selected photo immediately. The full code for the SlideShow component is given in
Listing 13.11.
[Bindable]
private var _xml:XML;
private var photos:ArrayCollection = new ArrayCollection();
private var sound:Sound;
private var iLoaded:uint = 1;
private var isLoaded:Boolean = false;
private var timer:Timer = new Timer(1000,0);
private var photoIndex:int = 0;
private var nextPhotoTime:int = 1;
Progress);
photo.contentLoaderInfo.addEventListener(Event.COMPLETE, onComplete);
photos.addItem(photo);
}
progress.label=”Loading Image “+iLoaded+” of “+photos.length+”.”;
}
} else {
progress.visible = false;
play.visible = true;
isLoaded = true;
}
}
]]>
</mx:Script>
In this example the query string parameter we’re looking for is named slideshow. To specify your own
slideshow, simply set slideshow equal to a URL that points to a valid slideshow XML file. The full code
for the SlideshowPlayer is given in Listing 13.12, and the resulting SWF is shown in Figure 13.5.
<mx:HTTPService id=”service”
url=”{Application.application.parameters.slideshow}”
resultFormat=”e4x” result=”show.loadShow( XML(event.result) );” />
</mx:ControlBar>
</mx:Panel>
</mx:Application>
In Listing 13.13, we’ve created a Panel area to search and select images based on a given tag. It
includes a TileList to hold the images and a ControlBar with text input for search terms. Now we
need a method for retrieving images based on the user input given. The variable service (see List-
ing 13.14) represents a Web Service of the popular Web portal flickr.com that lets people store and
share their photos.
Note that you’ll need to replace the term your_api_key with your own API key obtained from Flickr.
You can request one from the Flickr API site I mentioned earlier.
When a request with this URL is sent to Flickr, we can expect an XML file in return. A sample re-
sponse is shown in Listing 13.15.
We’ll need to create an itemRenderer for the TileList that uses the XML data received from Flickr to
retrieve and display images. Let’s create a new MXML component named FlickrThumb:
Now that all the necessary components are in place we can bind the appropriate HTTPService
result to the TileList in our SlideShowCreator application by setting its dataProvider property to
“{service.lastResult.rsp.photos.photo}”.
The “rsp.photos.photo” portion of this code is referencing the actual XML response from Flickr.
Let’s also set the itemRenderer as FlickrThumb and the search button’s click event to invoke the
HTTPService object’s send method. Run the SlideSlowCreator application to test our Flickr integra-
tion and search through images to your heart’s content. The progam will output the screen (with-
out photos) as in Figure 13.6.
<mx:Script>
<![CDATA[
[Bindable]
public var xml:XML = <slideshow><audio source=”” /></slideshow>;
[Bindable]
public var selected:XML = <slideshow><photo duration=”” source=””/>
</slideshow>;
]]>
</mx:Script>
Once again, we’ve used E4X in this code to store and manipulate XML data. If this was a larger or
more complex application it might have been necessary to create business objects instead, but
since the slideshow data is ultimately represented as XML, this may be a better option.
Now we’ve got all the methods needed to create a slideshow. We just need to fill in some of the
user interface required. Inside the Panel we’ll create a VBox containing an Image control and a
Form with input for the photo source and duration. This should include a TextInput control called
imgSource and a NumericStepper control named imgDuration. We can bind the Image control to
“selected.photo.@source” to be sure it always shows the selected image. We’ve already referenced
the NumericStepper imgDuration (just a text field with up and down arrows) in the code above so
that it updates correctly. We’ll also need to invoke the selectSlide method inside of the TileList’s
change event and the addSelectedSlide and removeSelectedSlide methods inside of button click
events as shown in Listing 13.18.
Now that we’ve got some of the interface in place, users can add and remove photos to and from
the slideshow XML object, but there’s still no feedback to show users the current list of slides. Fortu-
nately, we’ve already created a Scroller component and Thumb component that can be reused and
bound to the slideshow XML. Simply add the Scroller component we created earlier underneath
the Panel and bind it to the XML object as shown in Listing 13.19.
Notice that we’ve also set the Scroller’s change event to invoke the selectSlide method. This is the
only interactivity we need to define. Flex’s rich data binding will take care of updating the list when
items are added or removed. Run your application and be sure that everything is in working order.
You should be able to browse photos from Flickr, select photos to preview, adjust settings, and add
photos to the slideshow list. You should also be able to select photos from the slideshow list and
remove them. The last thing we need to include is the capability to add audio from a URL. Insert the
code from Listing 13.20 into the ControlBar component already in the application.
In Listing 13.20 we’ve provided a TextInput control for the user to enter a URL and a button whose
click event sets the appropriate value in our slideshow XML. Also note that we have surrounded
these input fields with a VBox container that has a horizontalAlign value of right. This is provided
so that the controls align themselves on the opposite side of the Flickr search controls.
For example, enter New York in the Tags text field and press the button Search Flickr. The Slide-
ShowCreator will display the thumbs with the images of the photos of New York. Select the image
that you’d like to include in your slideshow, and you’ll see the URL of the source file. Enter required
duration. Press the button Add Photo and repeat this procedure for other photos.
Now that we’ve developed a way for users to create a slideshow, let’s include a way for them to pre-
view it in the SlideShowCreator application.
<mx:states>
<mx:State name=”preview” enterState=”preview.loadShow( xml );”
exitState=”preview.stopShow();”>
<mx:SetProperty target=”{creator}” name=”visible” value=”false”/>
<mx:SetProperty target=”{scroller}” name=”visible” value=”false”/>
<mx:AddChild>
<lib:SlideShow id=”preview” bottom=”10” left=”10” right=”10” top=”50” />
</mx:AddChild>
</mx:State>
</mx:states>
In this section of the code we’ve defined a new state named preview. In the preview state we’re
setting the Panel and Scroller controls to be hidden and creating a new SlideShow component on
stage. We’ve also set the enterState and exitState events to play and stop the slideshow, respectively.
Now all we need to do is provide the user with a way to navigate to the appropriate application
state. We’ve left some room at the top of our application for an ApplicationControlBar and we’re
going to use it to provide links to our two application states as shown in Listing 13.22.
In the click event of the LinkButton for our Design view we’ve set the application view state back
to the default view by assigning currentState equal to a blank string. Run the application to create
a new slideshow and preview it using our SlideShow component. If you have any trouble running
your application, reference the full SlideShowCreator.mxml source shown in Listing 13.23.
]]>
</mx:Script>
<mx:HTTPService id=”service” url=”http://www.flickr.com/services/rest/?method=flickr.
photos.search&api_key=fa5d101b8564317c248aa429302468ee&text={tags.text}” />
<mx:ApplicationControlBar top=”5” left=”5” right=”5”>
<mx:LinkButton label=”Design” click=”currentState=’’;” />
<mx:LinkButton label=”Preview” click=”currentState=’preview’;” />
</mx:ApplicationControlBar>
<mx:Panel layout=”absolute” title=”SlideShow Creator” id=”creator” left=”10”
right=”10” bottom=”100” top=”50”>
<mx:TileList id=”gallery” change=”selectSlide(‘http://static.flickr.com/’ + event.
currentTarget.selectedItem.server + ‘/’ + event.currentTarget.selectedItem.id + ‘_’ +
event.currentTarget.selectedItem.secret + ‘_o.jpg’, 10);” dataProvider=”{service.las-
tResult.rsp.photos.photo}” itemRenderer=”FlickrThumb” right=”310” bottom=”5” top=”5”
left=”5”/>
<mx:VBox top=”5” width=”300” bottom=”5” horizontalAlign=”center”
verticalAlign=”bottom” right=”5”>
<mx:Image id=”image” source=”{selected.photo.@source}” width=”200”
height=”200” />
<mx:Form width=”100%”>
<mx:FormItem label=”Source” horizontalAlign=”left”>
<mx:TextInput id=”imgSource”
text=”{selected.photo.@source}” width=”175”/>
</mx:FormItem>
<mx:FormItem label=”Duration”>
<mx:NumericStepper id=”imgDuration” value=”10”
minimum=”1” maximum=”300” />
</mx:FormItem>
</mx:Form>
<mx:HBox width=”100%” horizontalAlign=”right”>
<mx:Button label=”Remove Photo”
click=”removeSelectedSlide();” />
<mx:Button label=”Add Photo” click=”addSelectedSlide();” />
</mx:HBox>
</mx:VBox>
<mx:ControlBar horizontalAlign=”left” verticalAlign=”middle”>
<mx:Label text=”Tags”/>
<mx:TextInput id=”tags”/>
<mx:Button label=”Search Flickr” id=”search”
click=”service.send();” />
<mx:HBox width=”100%” horizontalAlign=”right”
verticalAlign=”middle”>
<mx:Label text=”Audio URL”/>
<mx:TextInput id=”soundURL”/>
<mx:Button label=”Add Audio” click=”xml.audio.@source =
soundURL.text;” />
</mx:HBox>
</mx:ControlBar>
</mx:Panel>
<lib:Scroller id=”scroller” dataProvider=”{xml.photo}” change=”selectSlide( event.
currentTarget.selectedItem.@source, event.currentTarget.selectedItem.@duration );”
itemRenderer=” com.theriabook.controls.SlideThumb “ bottom=”10” left=”10” right=”10”
height=”85”/>
</mx:Application>
When our application is running in preview mode, the SlideShow component should automatically load
and let users interact with it just as they would in the SlideShowPlayer application. See Figure 13.7.
When all slides are selected and an MP3 audio file is ready, click on preview and enjoy the show!
Summary
In this chapter we’ve developed an application that can be used to create and preview custom
slideshows using the Flickr API. Hopefully we’ve gotten you well on your way to creating a very rich
and useful application in Flex with relatively little effort. We’ve also had another chance to review
several important Flex 2 topics including:
Flex 2 makes desktop-like applications a reality for the Web. We hope you can expand on the ideas
presented in this chapter and create your own media applications targeted for the Web.
14
Check out the Google Finance application at http://finance.google.com/finance. Just enter a stock
symbol (e.g., ADBE) and enjoy working with a highly interactive line chart representing the stock
performance over a selected period of time.
This line chart is rendered by the Flash Player and it reacts to your mouse movements, displaying
the date and time under the mouse cursor; it has a zoom feature; and you can change the time pe-
riod by dragging the timeline above the chart. This Flash chart is smart enough to interact with the
rest of the non-Flash Web page components. Click on one of these little flags and the correspond-
ing news item is highlighted on the right. Interactive charts will give your end users a lot more
control than static ones, and will make them happy.
In this chapter, we’ll show you how you can program similarly interactive charts by creating
your own and extending standard Flex Charting components. We assume the reader is familiar
with the basics of Flex Charting. To get a feeling for what Flex Charting is about, check out the
following URL that demos various samples of charts in action and shows the MXML source code
for each: http://flexapps.macromedia.com/flex15/chartexplorer/explorer.mxml?versionCheck
ed=true.
To simplify digesting this material, we’ll build the following five applications adding, complexity
as we go:
• A program that draws a rectangular area right within the line chart component
• A line chart with a hundred data points
• A line chart with two data series and a movable vertical line
• The line chart described above with a tool tip displaying data point values from two series
• All of the above plus a chart zooming feature
While these applications won’t have all the functionality Google Finance offers, it’ll definitely give
you a little push in the right direction.
In our first example, we’ll try to override the standard painting of a chart component. Let’s start
with a simple example that will only use ActionScript. Suppose you want to implement limits
– each limit representing some rectangular region on the chart filled with some color. This can be
useful in highlighting some business-specific range of values. For example, if a stock price drops
below some resistance value, the line chart should be displayed in a red area. We’ll create two AS3
classes:
Please note that in this example, we’re painting this area right on the same graphic object. Later in
this chapter we’ll use a different technique (programmatic skins) and create additional objects to
be put on the chart.
To begin with, let’s create a CartesianLimit class that will hold all the values required to paint the
limits area:
Package com.theriabooks.limits {
import mx.graphics.IFill;
import mx.graphics.SolidColor;
import mx.graphics.IStroke;
import mx.charts.chartClasses.CartesianChart;
import flash.geom.Point;
import flash.geom.Rectangle;
if(lineStyle != null)
lineStyle.apply(chart.graphics);
else
chart.graphics.lineStyle();
if(fillStyle != null)
fillStyle.begin(chart.graphics, new Rectangle(x,y,width,height));
chart.graphics.drawRect(x,y,width,height);
if(fillStyle != null)
fillStyle.end(chart.graphics);
}
}
}
This class lets you store the information about the region coordinates, fill, and the line style used
to render this region. The method paint() here computes the coordinates of the rectangle based
on the provided minimum and maximum values and paints the area according to the fill and line
style. This is not a callback as Java programmers might assume; we’ll call it from the class Extended-
CartesianChart. This method has one argument of the CartesianChart type, which is a base Flex
class of all standard two-dimensional rectangular charts.
The user-defined ActionScript classes can be used as MXML tags as in Listing 14.4.
Object-oriented purists may not like the fact that we didn’t define the properties (minX, maxX, et
al) of the private CartesianLimit class with public getters and setters. If we went that route, we’d
have to clutter our code with a bunch of the following statements (one per each private property):
[Inspectable]
private var _minX: Object;
But if these getters and setters don’t include any additional processing, but are just passing the data
from the outside world to private variables and back, we can get away without getters and setters.
You don’t have to abide by the JavaBean specification to make your code visible to tools like Flex
Builder.
To help Flex Builder provide code hints, you can mark the private properties of the ActionScript
class with a metatag [Inspectable]. For public properties this wouldn’t be required. Flex Builder’s
MXML editor can offer you code hints as shown below:
Figure 14.2 Flex Builder code hinting for the user-defined properties
To create our custom chart, we need to extend the CartesianChart class (a base class for all rect-
angular 2D charts), and override its callback method updateDisplayList. Flex calls the updateDis-
playList() method when the component is added to a container using the addChild() method, and
when the component’s invalidate DisplayList() method is called. Don’t miss the fact that the meth-
od updateList() first calls its peer from the superclass to provide the default drawing of the chart,
and then paints the limits area on top of it.
package com.theriabook.limits {
import mx.charts.chartClasses.CartesianChart;
ns1=”com.theriabooks.limits.*”>
<mx:Script>
[Bindable]
public var results:Object = [
{Expense: “Taxes”, Amount: 2000},
{Expense: “Rent”, Amount: 1500},
{Expense: “Bills”, Amount: 100},
{Expense: “Car”, Amount: 450},
{Expense: “Gas”, Amount: 100},
{Expense: “Food”, Amount: 200}
];
</mx:Script>
<ns1:series>
<mx:Array>
<mx:LineSeries form=”curve” yField=”Amount” name=”Apple” >
</mx:LineSeries>
</mx:Array>
</ns1:series>
<ns1:limits>
<mx:Array>
<ns1:CartesianLimit minX=”Rent” maxX=”Food” minY=”400” maxY=”800”/>
</mx:Array>
</ns1:limits>
</ns1:ExtendedCartesianChart>
</mx:Application>
We put the tag <mx:Array> inside the <ns1:limits> just to make the code more generic as the ap-
plication may need more than one <ns1:CartesianLimit> area.
Run the application and it’ll display the chart with a red rectangle:
<mx:Script>
<![CDATA[
private function createData(count:uint) : Array {
var date: Date = new Date(2006,0); // starting from the new year day
[Bindable]
private var dataSet:Array = createData(100);
]]>
</mx:Script>
</mx:Application>
Listing 14.5 The line chart with 100 data points: LineChart100.mxml
This code will produce a line chart that may look like this:
Unfortunately, as we start moving the cursor over the chart, we recognize that there’s an issue – the
tool tip is shown only when we put our cursor over the actual data point (shown as a little circle).
Even with 100 points it makes extracting the data from the chart difficult. And what if we want to
plot multiple series and compare values at the same date?
• ExtendedLineChart: This class extends the LineChart and is responsible for drawing the line
chart
• VLineLayer: This class extends the ProgrammaticSkin class and its purpose is to draw the
vertical line on top of the ExtendableLine Chart.
Originally, Flex skinning was created to change the look-and-feel of the visual parts of the same
component easily (for example, a popular media player WinAmp offers hundreds of skins). But this
time we’ll use the skinning capabilities of Flex just to draw the line on top of the chart. We aren’t
planning to change the skin of the thin vertical line, but rather use this technique to put an object
on top of the chart and control it (we’re going to move this line along the horizontal axis).
Drawing a line is a fairly simple task – we’ll use a new VlineLayer class inherited from the Program-
maticSkin class. This class will draw the line (it’ll play the role of a skin) and add it as a child to our
chart.
package com.theriabook.charts.line1{
import mx.skins.ProgrammaticSkin;
import flash.geom.Rectangle;
super.updateDisplayList(unscaledWidth, unscaledHeight);
graphics.clear();
Flex designers declared the CartesianChart’s property dataRegion that defines the coordinates of
the actual data rectangle as protected. Since we need this information to be accessible from the
outside of this inheritance hierarchy, we’ve defined in our subclass a viewBounds public property
that will return the value of the dataRegion to any class that may need it:
And the complete code for the ExtendedLineChart will look like:
package com.theriabook.charts.line1{
import mx.charts.LineChart;
import flash.events.MouseEvent;
import flash.geom.Rectangle;
if(skin == null)
addChild(skin = new VLineLayer());
}
Let’s modify our MXML application from Listing 14.5 to support a two-line series:
[Bindable]
private var dataSet:Array = createData(100);
]]>
</mx:Script>
<ns1:ExtendedLineChart x=”127” y=”72” width=”400” height=”300” id=”linechart1”
dataProvider=”{dataSet}” showDataTips=”false”>
<ns1:seriesFilters>
<mx:Array/>
</ns1:seriesFilters>
<ns1:horizontalAxis>
<mx:DateTimeAxis dataUnits=”days” parseFunction=”parseDate”/>
</ns1:horizontalAxis>
<ns1:series>
<mx:LineSeries displayName=”ABCD” xField=”Date” yField=”ABCD”>
<mx:lineStroke>
<mx:Stroke weight=”1” color=”0x00ff” />
</mx:lineStroke>
</mx:LineSeries>
<mx:LineSeries displayName=”XYZT” xField=”Date” yField=”XYZT”>
<mx:lineStroke>
<mx:Stroke weight=”1” color=”0xff0000” />
</mx:lineStroke>
</mx:LineSeries>
</ns1:series>
<ns1:fill>
<mx:SolidColor color=”0xFFFFFF” />
</ns1:fill>
</ns1:ExtendedLineChart>
</mx:Application>
Run this program and you’ll see a chart that looks like Figure 14.5.
This class draws a movable vertical line, but we also need a tool tip that can show the data of mul-
tiple series based on the position of the vertical line. The standard tool tip window can only show
the information about one series, so we’ll create a new class to implement it (we’ll omit some prop-
erties declarations to make the code more readable):
textField.background = false;
textField.x=2;
textField.y=2;
textField.selectable = false;
addChild(textField);
}
We’ll display the text in the tool tip using a text contol. To do this, we override the createChildren
method of the UIComponent, which sets no background, margins, makes it non-editable, and
adds the text as a child component.
In the measure callback we’ll add a couple of pixels margin around the text.
The next step is to implement a function that can take an x-coordinate and return the information
about the nearest data point for each series. FlexCharts support two functions for converting data
points into the actual screen coordinates and vice versa – localToData and dataToLocal. But local-
ToData requires both x and y coordinates, and we don’t know the y coordinate of the point at the
current x since all we know is the x coordinate of the vertical line. The solution is to create a list of
all actual coordinates for all the data points and then use it to determine the closest data points at
a given x coordinate. Our assumptions are:
Now we can implement a simple PointCache class to “remember” the closest data points at each
x coordinate. The method getPointIndexByX will return the index of the data point inside the data
series.
}
return row.length-1;
}
It’s relatively easy to modify this class to support an arbitrary order of points by sorting the points
based on the x coordinate.
Finally, we can put together a new ExtendedLineChart class. Since we want to show in the tool tip
window the date, the name, and the value for the element on this date (the x coordinate) for all se-
ries, we’ll have to implement a custom tool tip getToolTipText formating function that can extract
the information from all the series and present it nicely:
if(index>=0) {
_dataTip.visible = true;
_dataTip.text = getToolTipText(index);
_dataTip.width = _dataTip.measuredWidth;
_dataTip.height= _dataTip.measuredHeight;
super.invalidateProperties();
}
super.invalidateSize();
}
}
Once you run the application, you can see the chart shown in Figure 14.6 with the tool tip contain-
ing the information on two data points that represent the line series for ABCD and XYZT, located
close to the vertical line. It doesn’t really matter now if your mouse pointer is located by the data
point: the vertical line (aka skin ) position guarantees that the proper data will be displayed.
Figure 14.6 A tool tip with the data about two series: ABCD and XYZT
First, we’ll implement a very simple zoom function in the ExtendedLineChart class, which will in-
crease or decrease the range of the x axis by some predefined value. Note that when we change the
axis’s range, we also have to reset the point cache.
The function zoom() ensures that the axis range won’t go outside the underlying data values and
will always be at least MIN_RANGE days.
Now we can simply add two buttons to our MXML file to zoom the chart in and out. Usually you’d
provide a more sophisticated mechanism for zooming the chart, but we’ll keep this example simple
for demonstration purposes.
XYZT: 75+Math.random()*50} ;
retval[0].ABCD = 0;
retval[retval.length-1].ABCD=0;
return retval;
}
[Bindable]
private var dataSet:Array = createData(100);
]]>
</mx:Script>
<mx:VBox x=”33” y=”24” height=”445” width=”606”>
<ns1:ExtendedLineChart width=”600” height=”400” id=”myChart”
dataProvider=”{dataSet}” showDataTips=”false” >
<ns1:seriesFilters>
<mx:Array/>
</ns1:seriesFilters>
<ns1:horizontalAxis>
<mx:DateTimeAxis dataUnits=”days” parseFunction=”parseDate”/>
</ns1:horizontalAxis>
<ns1:series>
<mx:LineSeries displayName=”ABCD” xField=”Date” yField=”ABCD”>
<mx:lineStroke>
<mx:Stroke weight=”1” color=”0x00ff” />
</mx:lineStroke>
</mx:LineSeries>
<mx:LineSeries displayName=”XYZT” xField=”Date” yField=”XYZT”>
<mx:lineStroke>
<mx:Stroke weight=”1” color=”0xff0000” />
</mx:lineStroke>
</mx:LineSeries>
</ns1:series>
<ns1:fill>
<mx:SolidColor color=”0xFFFFFF” />
</ns1:fill>
</ns1:ExtendedLineChart>
<mx:HBox width=”100%”>
<mx:Button label=”Zoom In” id=”zoomIn” fontWeight=”bold” click=”myChart.zoom(-2)”/>
<mx:Button label=”Zoom Out” id=”zoomOut” fontWeight=”bold” click=”myChart.zoom(2)”/>
</mx:HBox>
</mx:VBox>
</mx:Application>
Press the Zoom In button several times, and the Line chart will change as shown below. The zoom-
ing ration is controlled by the value you’re passing to the zoom() function under the zoom but-
tons.
After you zoom in to the chart, you can’t see the entire time interval. For example, you don’t see the
January data on Figure 14.8. Hence, we need to implement horizontal scrolling so the user can drag
the mouse to the left or right.
For this scrolling we’ll introduce the member variables _ancorX and _ancorY in the Extended-
LineChart class that will store the last mouse position and define the mouse down and mouse up
event handlers that will toggle the isDragging flag.
Our new onMouseMove event handler will compute the required change based on the new and old
mouse location and adjust the axis’s minimum and maximum accordingly. The final version of the
ExtendedLineChart class is shown in Listing 14.14.
addEventListener(MouseEvent.MOUSE_DOWN, onMouseDown);
addEventListener(MouseEvent.MOUSE_UP, onMouseUp);
addEventListener(MouseEvent.MOUSE_MOVE,onMouseMove);
}
if(newmin.getTime()<min.getTime()) {
newmax.setTime(newmax.getTime()+min.getTime()-newmin.getTime());
newmin = min;
} else
if(newmax.getTime()>max.getTime()) {
newmin.setTime(newmin.getTime()+max.getTime()-newmax.getTime());
newmax = max;
}
_ancorX = mouseX;
_ancorY = mouseY;
axis.minimum = newmin;
axis.maximum = newmax;
_cache.reset();
this.invalidateDisplayList();
}
_layer.width = width;
_layer.height = height;
var index: int = _cache.getPointIndexByX(mouseX);
_dataTip.visible = index>=0 ;
if(_dataTip.visible) {
_dataTip.text = getToolTipText(index);
_dataTip.width = _dataTip.measuredWidth;
_dataTip.height= _dataTip.measuredHeight;
_dataTip.x = mouseX+2;
_dataTip.y = mouseY-_dataTip.height;
}
}
Summary
In this chapter we gradually built an application that should give you a good start in developing
your own application that can look as good or even better than Google Finance. We’ve hard-coded
the symbols of imaginary stocks ABCD and XYZT in our MXML application to keep the reader fo-
cused on the charting aspects of Flex, but if you’ve read this far, it shouldn’t be too difficult to add
some external data feed that will serve as the provider for this chart, as shown in Chapter 5. We’d like
to thank the folks at GreenPoint, Inc., (http://gpoint.com/) for their valuable input to this chapter.
15
This subject of this chapter assumes a broad use of technologies besides the ones provided by
Adobe, let alone Adobe Flex. Whenever you integrate two systems you need intimate familiarity
with both. Obviously we had to pick one external application that the reader will be familiar with so
that, besides the educational value, our solutions would have immediate practical use. We picked
Microsoft Excel.
Hence the composition of our chapter includes references to LocalConnection and External API
intervened with JavaScript, VBA, and XSLT to name just a few. The ride might feel hard, but it is
worth it: by the end of the chapter we’ll have presented a series of generic solutions that you can
use off-the-shelf.
All examples are thoroughly commented, although we permitted ourselves less detail on the Mi-
crosoft subjects.
Using Excel as a counter-party example, we’ll address the needs of Flex applications to commu-
nicate with the standalone native applications running on a user’s computer. We’ll also show the
integration of Flex and a spreadsheet in a single HTML page. The Flex-to-Flex communications, ir-
respective of the mode the Flex applications are running in (embedded inside an ActiveX container
or run by a standalone Flash Player), will get on our radar as well.
First, developers got access to a bunch of methods like FSCommand, CallFrame, CallLabel, and
SetVariable. These methods, exposed by a Flash ActiveX plug-in, allow one-way control of the Flash
from a hosting container.
Macromedia Flash 6.0 added SharedObject to a set of available ActionScript classes. The Shared
Object class is used to read and store limited amounts of data on a user’s computer. Besides its
primary function, SharedObject allows a data exchange between two Flash movies running on the
same computer (a second type of communication).
Flash 6.0 also provides a LocalConnection class. LocalConnection objects can communicate only
among SWF files that are running on the same client computer, but they can be running in differ-
ent applications – again, we’re talking about Flash-to-Flash communication. Note that the Local-
Connection API and security model underwent several significant changes with further releases.
Finally, release 8.0 adds ExternalInterface to the developers’ arsenal. The External API enables
straightforward two-way communication between ActionScript and the host application, i.e., you
can call ActionScript functions from the Flash Player container and invoke container functions
from ActionScript as well.
In this chapter we’ll discuss only communications using ExternalInterface and LocalConnection.
Even though the FSCommand & Co. methods are fully supported by the current Flash Player (9.0
when this was written), it’s recommended to avoid them for integrating applications. The External
API is more straightforward, flexible, and generally applicable.
import flash.external.ExternalInterface;
…
var retVal:Object = ExternalInterface.call( “javaScriptFunction”, arg1, arg2, …,
argN );
This will call a JavaScript function named “javaScriptFunction” declared somewhere on the HTML
page with arguments supplied as the rest of the parameters and will get the result of the function
execution as a retVal variable. You can use a wide range of types for arguments and the return value:
strings, numbers, Boolean values, instances of Date class, Object, Array, and any combination thereof
like Array of Objects or Object with Array properties. User-defined types are not supported.
If you’re just starting Flex application development, everything should look so natural to you that it
doesn’t even deserve further explanation. However, if you’re a seasoned Flash developer, you may
notice a number of improvements. Unlike FSCommand that accepts one and only one argument of
the String type, you can use any number of parameters with an ExternalInterface.call. Another im-
provement over the “old approach” is that dealing with return values is absolutely transparent: you
just get the value returned by JavaScript function as a result of its operation. In dark ancient days
you’d have to cope with dynamic properties and either Object.watch or onEnterFrame events.
The code snippet above has a serious problem: if you accidentally run your SWF in a hosting appli-
cation that has no External API support (like a standalone Flash Player), you’ll get an error message.
When you have to develop a Flex application that works in different containers and not all of them
support the External API, you definitely need a way to detect the availability of the External API. To
do this, it’s necessary to check a static property available to the ExternalInterface class:
import flash.external.ExternalInterface;
…
if ( ExternalInterface.available )
ExternalInterface.call( “javaScriptFunctionName”, arg1, arg2, …, argN );
import flash.external.ExternalInterface;
…
if ( ExternalInterface.available )
ExternalInterface.addCallback( “myFunction”, myCallback );
The first parameter to ExternalInterface.addCallback is the name of the function as it will be visible
to JavaScript. The second parameter is the function closure to invoke. Notice that you may expose
your ActionScript function to JavaScript under a different name, but for the sake of clarity, using
the same name is recommended.
import flash.external.ExternalInterface;
import mx.controls.Alert;
…
if ( ExternalInterface.available )
ExternalInterface.addCallback( “myFunction”, function():void{ Alert.
show(“Called fromJavaScript”); } );
When you pass an instance method closure as an argument, the callback is directed at the method
of a particular object instance, so you can access other instance methods or properties of this ob-
ject. The set of supported arguments’ types is exactly the same as for arguments passed with Ex-
ternalInterface.call.
Typically, callback functions are registered when an application is created, i.e., in the creationCom-
plete event handler’s chain. However, you can register a callback at any time during the application
lifecycle, or even replace one callback with another if necessary. However, there’s no method to re-
move a callback completely. As a workaround, replace already registered callbacks with a function
that doesn’t do anything.
Believe it or not, this is all you have to know about the External API to start using it. The only im-
portant point left uncovered is the security aspect. When you’re accessing a Flex function from
JavaScript running on an HTML page, or when you call a JavaScript function from Flex, stringent
security restrictions are applied. According to the default security policy both HTML and SWF files
must originate from the same domain. In most cases this requirement is quite easy to follow.
If you want to relax the restrictions associated with the ExternalInterface.call method, then you
have to tweak the allowScriptAccess parameter of the HTML <OBJECT> tag or the attribute with
same name in the HTML <EMBED> tag. Changing this setting from the sameDomain default value
to liberate always lets you execute JavaScript functions regardless of whether the JavaScript source
is in the same domain as Flex swf. If you set the aforementioned property to never, you effectively
cause any ExternalInterface.call invocation to fail with a security error.
To relax the security policy that’s applied to JavaScript calling a Flex function, you must use one of
the ActionScript methods, Security.allowDomain or Security.allowInsecureDomain. Supply the list
of domain names you want to grant access to as parameters:
Security.allowDomain(“www.host-a.com”, “www.host-b.net”);
Or use the wildcard “*” to grant access to the JavaScript code loaded from any host:
Security.allowDomain(“*”);
The latest option is to edit your global Flash Player Security Settings and add certain domains to trusted
sites. You must do this if you run this chapter’s examples from your local file system. To do this visit the
Global Security Settings panel at http://www.macromedia.com/support/documentation/en/flash-
player/help/settings_manager04.html and add directory with examples to the list of trusted sites.
We’re done with the theory so let’s proceed with a small working example. What we need is just a
simple Flex application and a small HTML page.
counter++;
var retVal:Object = ExternalInterface.call(“jsFunction”,
input.text, counter, new Date(), counter % 2 == 0);
We start with an onCreationComplete event handler. Here we first check whether the External API is
available and, if so, register an callActionScript instance method closure under the name “asFunc-
tion” so JavaScript code can invoke this method like:
flexObject.asFunction(“String argument”);
Now take a look at the callActionScript method itself. As long as we use an instance method closure,
we can refer to other instance variables or methods. In the example above we just assign the given
text to the TextInput control.
The second method is used to invoke a jsFunction JavaScript function from a Flex applica-
tion in response to the button click. Again, we start with an External API availability check.
You may choose a different strategy for your application and just disable the button after
the initial check. We’re passing several parameters of different types to the JavaScript func-
tion: the number of invocations as Number, user-entered text as String, current timestamp
as Date, and even/odd invocation flag as Boolean. Finally, the method handlers return a
value from the JavaScript function. If it returns a String then we update the text of TextIn-
put control.
Next, we have to create an HTML file that embeds the Flex SWF:
<html lang=”en”>
<!-- File ./html-template/FxJavaScript.template.html -->
<!-- Flex / JavaScript communications example -->
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” />
<title>Basic External API Example</title>
<style type=”text/css”>
#fxJavaScript { width: 15em; height: 80px; }
#html_controls {
width: 15em; margin-top: 1em; padding: 1em;
color: white; border: solid 1px white;
font-family: Arial
}
body>#html_controls {
width: 13em;
}
body {
background-color: #869CA7;
}
</style>
<script language=”JavaScript”>
function jsFunction(string, number, date, boolean) {
alert(
function callActionScript () {
var fxControl = document.fxJavaScript || window.fxJavaScript;
var value = document.getElementById(“txtMessage”).value;
fxControl.asFunction( value );
}
</script>
</head>
<body scroll=”no”>
<object classid=”clsid:D27CDB6E-AE6D-11cf-96B8-444553540000”
id=”fxJavaScript”
codebase=”http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab”>
<param name=”movie” value=”FxJavaScript.swf” />
<param name=”quality” value=”high” />
<param name=”bgcolor” value=”#869CA7” />
<param name=”allowScriptAccess” value=”sameDomain” />
<embed src=”FxJavaScript.swf”
name=”fxJavaScript”
id=”fxJavaScript”
align=”middle”
bgcolor=”#869CA7”
quality=”high”
play=”true”
loop=”false”
quality=”high”
allowScriptAccess=”sameDomain”
type=”application/x-shockwave-flash”
pluginspage=”http://www.adobe.com/go/getflashplayer”>
</embed>
</object>
<div id=”html_controls”>
Send message to Flex<br/>
<input type=”text” id=”txtMessage” /><button
onclick=”callActionScript ()”>Send</button>
</div>
</body>
</html>
Listing 15.2 The HTML page for the sample External API application
To save the book space, we’ve removed the boilerplate code generated by Flex Builder that handles
automatic Flash plug-in installation, disabled JavaScript, and browser history navigation. So to run
this example you must have Flash Player 9 installed and JavaScript enabled.
The HTML file embeds the Flex application via both the <OBJECT> and <EMBED> tags to support a
wide range of browsers and provide a minimal set of controls to invoke an ActionScript function from
JavaScript. The most interesting part is a pair of JavaScript functions defined in the <SCRIPT> tag.
The first one is a jsFunction that’s invoked from our Flex application. This function just dumps
supplied parameters using the built-in window.alert method and returns the string parameter
to ActionScript transformed into upper case. While executing this example, you may see that the
JavaScript function receives parameters of the same type (String, Number, Date, Boolean) as on the
ActionScript side.
Note that the name of this function must exactly match the first parameter of the ExternalInter-
face.call (Listing 15.1) and must be defined in the global scope1. If you mistype the name either
in the Flex application or in the HTML, the External API silently returns an undefined value to
ActionScript without any errors! If you supply more parameters to the ExternalInterface.call, then
the JavaScript function expects the rest of them will be ignored. If the argument list is shorter than
expected, the remaining ones will have undefined values.
The second function – callActionScript – shows how easy it is to invoke an ActionScript function
exposed via the External API:
fxControl.asFunction( value );
The only tricky part here is to get a reference to fxControl (Flex ActiveX or a plug-in). We used
common JavaScript “or” shorthand to get this reference either from the window object (Internet
Explorer) or from the document (Gecko-based browsers or Safari):
When we invoke asFunction the content of the TextInput control inside the Flex application is up-
dated accordingly.
Unlike JavaScript, ActionScript has optional strong typing. In fact, the Flex Builder compiler uses
strong typing by default. So unless the function closure passed to ExternalInterface.addCallback
allows a variable number of arguments, supplying more or less arguments than expected will re-
sult in an error. To test this, you can modify the fxControl.asFunction(...) from Listing 15.2 to pass
either no arguments at all or, say, two arguments – either scenario will cause an error. Supplying
arguments of a non-expected type forces the implicit type conversion on the ActionScript side. If
the type conversion fails, you’ll see an error again. But wait, if it succeeds, it’s even worse: there’s a
good chance of falling into the trap of hard-to-find bugs.
For example, consider an ActionScript callback that defines Number and String parameters. How-
ever, JavaScript code passes them in the wrong order: first String, then Number. This call will suc-
ceed with the first parameter containing the result of String-to-Number conversion (zero, if the
String contains non-numeric characters) and the second parameter presenting Number as String
(Number.toString()), but the final result will hardly be correct.
Interesting enough, all built-in JavaScript global functions as well as methods of the window object
are also available to the ExternalInterface. In other words, you can use methods like alert, confirm,
navigate, open, and many others directly from Flex applications. For example:
if ( !confirmed ) return;
ExternalInterface.call(“open”,
“http://myhost/about.html”, “_blank” );
};
Bear in mind, however, that many JavaScript programmers say eval is B.A.D. – Broken As Designed.
The ratio of flexibility versus readability of code using eval is also disputable; the performance lost
is proven by practice: JavaScript will have to switch back to interpreter mode when executing a
statement passed to eval.
Now we’ll consider a more complex example of integration with external applications. The solution
involves two ActiveX objects embedded in an HTML page with instant as well as on-demand data
synchronization between the objects.
One of these ActiveX objects is the Flash Player control, executing a Flex application. The second
ActiveX is a spreadsheet from Microsoft Office Web Components (OWC). You may think of the
spreadsheet as a miniature Microsoft Excel application running inside the HTML page. We hope
you find our choice of the external application quite natural; data entry or analytical applications
with no Excel integration are hard to find. Be it saving data in native Excel format or CSV, accepting
data entered in Excel, or dynamically creating Excel charts based on the database queries – we see
it everywhere.
Later in this chapter we’ll show the integration of Flex with a real Microsoft Office Excel applica-
tion, but for now Spreadsheet ActiveX will do just fine, given the large set of common functionality
between Excel and the OWC Spreadsheet.
Before diving into coding, let’s briefly outline the design of the complete solution.
First, we need a Flex application to play with. We’ll build a simple Master/Detail screen with Da-
taGrid and Form exposing the basic set of data entry operations: Create-Read-Update-Delete,
commonly referred to as CRUD. Every operation will be notifying the hosting environment about
the data changes using the ExternalInterface.call method.
Second, we need a Spreadsheet ActiveX control embedded in the same HTML page. As with any
third-party ActiveX component we can script it using methods of a Dispatch interface also known
as an automation interface. Thankfully, Spreadsheet’s objects have a rich API with all the necessary
methods to read/write data and change tracking events.
Finally, we need some mediator that orchestrates communications between both parties. This task
is carried out by a set of JavaScript functions/event handlers inside the HTML page.
As far as ActiveX components are used, the example can run only under Internet Explorer on the
Microsoft Windows platform (any modern version like Windows 2000 or Windows XP). See Figure
15.2 to get an impression of what the final result looks like.
After the page is loaded and the initial data for the Flex application is available, the user can edit the
records using either the Flex application or a Spreadsheet OWC control. Any changes like altering
the cell value in the Spreadsheet or inserting/deleting records in the Flex application are immedi-
ately synchronized between two controls. Moreover, the “undo” functionality is fully supported: if
the user modifies a record in the Flex application, it can revert changes in the Spreadsheet OWC
and both controls will be updated accordingly.
[Bindable]
private var employees:ArrayCollection = new ArrayCollection();
[Bindable]
public var bhiOptions:Array = [{label: “No”, data:false}, {label:”Yes”, data:
true}];
}
private function deleteRow():void {
var idx:int = dataGrid.selectedIndex;
if (idx >= 0) {
employees.removeItemAt(idx);
if ( !employees.length ) {
frmName.text = frmPhone.text = “”;
frmBirthday.selectedDate = new Date;
frmYos.value = 1; frmSalary.value = 0;
}
else
dataGrid.selectedItem = employees.getItemAt(Math.min(idx, employees.length
- 1));
fxRowsRemoved(idx, 1);
}
}
}
private function loadData():void {
applyResult([
employee(“Yakov Fain”, d(“1960/04/18”), “732-456-4432”,
yos(“1999/05/20”), true, 95000.0),
employee(“Anatole Tartakovsky”, d(“1962/03/03”), “561-860-2376”,
yos(“1991/03/01”), true, 85000.0),
employee(“Victor Rasputnis”, d(“1963/02/06”), “718-445-7622”,
yos(“1993/07/02”), true, 85900.0),
employee(“Melissa Espinoza”, d(“1950/12/14”), “508-555-2319”,
yos(“1996/04/18”), true, 36490.0),
employee(“Kathleen Poitras”, d(“1966/09/29”), “617-555-3920”,
yos(“1999/05/29”), false, 46200.0),
employee(“Joseph Barker”, d(“1980/02/14”), “617-555-8021”,
yos(“2001/09/10”), false, 27290.0),
employee(“Shih Lin”, d(“1980/12/12”), “617-555-5921”,
yos(“2001/11/11”), false, 33890.0),
employee(“Barbara Blaikie”, d(“1954/11/14”), “617-555-9345”,
yos(“2001/11/20”), true, 54900.0)
]);
}
dataProvider=”{bhiOptions}”/>
</mx:FormItem>
<mx:FormItem label=”Salary”>
<mx:NumericStepper id=”frmSalary” value=”{dataGrid.selectedItem.salary}”
maxChars=”10” minimum=”0” maximum=”999999”/>
</mx:FormItem>
<mx:FormItem>
<mx:HBox>
<mx:Button label=”Update” click=”updateRow()”/>
<mx:Button label=”Add” click=”addRow()”/>
<mx:Button label=”Delete” click=”deleteRow()”/>
</mx:HBox>
</mx:FormItem>
</mx:Form>
</mx:VBox>
</mx:Application>
Rather than going through a compete code walkthrough, let’s just focus on the particular key meth-
ods. The first one, fxMetadata, notifies the hosting container about the metadata used. As long as
we strive to keep the JavaScript on the HTML page as generic as possible, neither hard-coded nor
“well-known” names are valid options. fxMetadata notification enables the JavaScript code to be
used with a wide range of Flex applications. The metadata format used in our example is sufficient
to describe the order of fields, user-friendly field names, and types of fields. The last feature is very
important. Both Microsoft Excel and Microsoft Spreadsheet OWC support type-specific formating
options, and we plan to exploit this functionality.
Next comes the trio of methods fxRowsInserted, fxRowsUpdated, and fxRowsRemoved. As their
names suggest, these are data change notifications to the hosting container. Note that the no-
tification for the complete data (re)load is fxRowsUpdated with the Boolean flag reset equals
true. All data notifications use the offset parameter to define the positions where changes take
place.
In this example we match the records in the Flex application and the rows in the Spreadsheet OWC
by position, i.e., a record in the Flex application corresponds to a row in the Spreadsheet if they
both have the same index. Other types of “equality” are possible as well, for example, matching a
data record and the Spreadsheet row by key attributes. However, anything more complex than a
simple index would require lengthy code examples that won’t fit in a book chapter.
Finally, we have a pair of xlImportRows and xlResend methods as ActionScript callbacks exposed
via the ExternalInterface.addCallback. The purpose of the first is fairly obvious: this is data change
notification in the opposite direction from the Spreadsheet OWC to the Flex application. The sec-
ond method deals with possible timing issues related to loading the SWF file by the Flash Player
control. If HTML JavaScript was unable to get the pair of initial fxMetadata/fxRowsUpdated notifi-
cations, it can query the Flex application to resend them.
<html lang=”en”>
<!-- File ./html-template/FxSpreadsheet.template.html -->
<!-- Flex / Spreadsheet OWC communications example -->
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” />
<title>Flex <-> Spreadsheet OWC example</title>
<style type=”text/css”>
body { overflow: hidden; background: #869CA7 }
#fxGrid { float:left; width: 50%; height: 100%; margin-right: 1em; }
#xlBox { width: 99%; height: 100% }
#xlOWC { width: 100%; height: 100%; border: 1px solid rgb(183,186,188) }
* { font-family: Verdana, Arial; font-size: 10pt; color: white }
</style>
<script language=”JavaScript” type=”text/javascript”>
/* CODE TO DETECT CURRENT BROWSER / VERSION */
var fxMetadata, fxRowsUpdated, fxRowsInserted, fxRowsRemoved;
fxMetadata = fxRowsUpdated = fxRowsInserted = fxRowsRemoved = function() {};
/* MAIN JAVASCRIPT CODE */
</script>
</head>
<body scroll=”no”>
<object classid=”clsid:D27CDB6E-AE6D-11cf-96B8-444553540000”
id=”fxGrid” width=”100%” height=”100%”
codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab”>
<param name=”movie” value=”FxSpreadsheet.swf” />
<param name=”quality” value=”high” />
<param name=”bgcolor” value=”#869ca7” />
<param name=”allowScriptAccess” value=”sameDomain” />
<embed src=”FxSpreadsheet.swf” name=”fxGrid” quality=”high” bgcolor=”#869ca7”
width=”100%” height=”100%” align=”middle”
play=”true”
loop=”false”
quality=”high”
allowScriptAccess=”sameDomain”
type=”application/x-shockwave-flash”
pluginspage=”http://www.macromedia.com/go/getflashplayer”>
</embed>
</object>
<div id=”xlBox”>
<!-- CODE TO WRITE SPREADSHEET ACTIVEX -->
</div>
</body>
</html>
Listing 15.4 The draft of an HTML page for OWC integration sample
Now we have to include the Spreadsheet OWC control in the HTML page. This control is available
only as Microsoft Windows ActiveX, which leaves users of other platforms and browsers out in the
cold. In any event, we feel obligated to relieve these users of JavaScript errors or browser crashes.
Concrete fallback strategies may vary, but in the simplest form we have it here, it’s just a message
about the unsupported environment. More complex JavaScript may first analyze the browser and
OS and then suggest more specific steps.
Here’s the first block of JavaScript code that detects the version of the browser and OS. It’s based on
a conditional compilation, manifested by an @cc_on statement, an IE-specific feature. As long as
the logic based on @cc_on is nested inside the /**/ comments, all other browsers simply treat it as
a comment, nothing more:
As a net result, the variable ie_win32 gets sets to 1 if and only if the script is running under Micro-
soft Internet Explorer 5+ on Windows 95/NT 4.0 or higher. Browsers other than Microsoft Internet
Explorer 5+ see the assignment as commented-out code. If the browser isn’t IE our page will display
the “complaint” and do nothing (see Listing 15.6 below):
Once IE is confirmed, our JavaScript must be robust enough to detect the availability of the Micro-
soft Office Web Components and to select the most recent version2. Currently, there are four ver-
sions of Microsoft Office Web Components: Office 2000, XP, XP SP3, and 2003 as shown, along with
the corresponding CLSID in Table 15.1.
Microsoft OWC Version (Build) Microsoft Office Version CLSID of Spreadsheet OWC
And whether you’re surprised with this abundance of versions or not, you have to understand and
accept it to make your code run on all OWC-enabled systems.
The first version of Office Web Components released to the public was OWC 9. To say that it was
released along with Microsoft Office 2000 would be an understatement because ordering the Office
2000 CD was the only way to get it. Aside from this questionable distribution model, the OWC9 API
has been anything but practical. For example, a Spreadsheet component from that release lacks
content change notification events, so essentially when used with OWC9 our example will be a
one-way road from Flex to OWC.
The second big release was OWC coming with Microsoft Office XP (2002). The API was seriously
reworked to match the object hierarchy and functionality of the corresponding Office applications.
With this single release Microsoft contrived to make several important changes:
• It changed the CLSID of all Office Web Components after the release of Service Pack 3, see
Table 15.1.
• It enhanced OWC licensing. Originally, to use OWC 10 Components in editable mode (as with
version 9), you needed a Microsoft Office product or license file installed on your PC. The new
licensing model introduced the notion of a “shared license” for business entities that have a spe-
cial agreement with Microsoft. This opened the door for using OWC Components in an interac-
tive mode within organizations’ intranets even when a specific client computer has no Microsoft
Office product or license file installed. For a full description refer to Microsoft’s Knowledge Base
article #555094 (http://support.microsoft.com/?scid=kb;en-us;555094&spid=2488&sid=714).
• The recent version 11 of Office Web Components has no dramatic changes comparable to
previous versions. However, the API has been extended according to the enhancements in Mi-
crosoft Office 2003 (mostly XML-related stuff) and the set of CLSIDs used was changed again.
Now that we’ve completed this version-hell walkthrough, we’re ready to write the JavaScript code
that attempts to embed the most recent version of the Spreadsheet OWC Component or, alterna-
tively, degrades the HTML page when no OWC is available, the IE security settings prohibit running
ActiveX, or a combination of the browser/OS isn’t supported:
var clsidPrefix;
var versionInfo = “<unknown>”;
LOOP_VERSIONS:
for (var i = versions.length - 1; i >=0; i--) {
var owc = null;
var ver = versions[i];
var progid = “OWC” + ver + “.Spreadsheet” + (ver ? “.” + ver : “”);
try { owc = new ActiveXObject(progid) } catch(e) {}
if (owc) {
versionInfo = (owc.majorVersion < 10 ? “0” : “”) + owc.version;
if (!ver) ver = parseInt(versionInfo);
for (var i = version_ids.length - 1; i >= 0; i--) {
var lastVersion = version_ids [i];
var guess = version_clsids[lastVersion];
if ( versionInfo >= lastVersion ) {
clsidPrefix = guess;
break LOOP_VERSIONS;
}
}
}
}
if ( clsidPrefix )
document.write(
‘<object id=”xlOWC” classid=”CLSID:’ + clsidPrefix + ‘-0000-0000-C000-
000000000046” ‘ +
‘title=”Microsoft Office Web Component / Excel Spreadsheet v’ + versionInfo +
‘”>’ +
wrong_env + ‘</object>’
);
else
document.write(
“<p>Unable to resolve Spreadsheet component CLSID for “ +
“Microsoft Office Web Components (OWC) version “ + versionInfo + “</p>”
);
})();
</script><noscript>
<p>Unable to detect OWC version: JavaScipt disabled.<br/>
This sample requires Microsoft Internet Explorer browser, running on Windows platform.
Also you need Microsoft Office Web Components (OWC) installed.</p></noscript>
The code traverses a list of available versions in reverse order (from tale to head, from higher ver-
sion to lower) trying to instantiate a Spreadsheet component via the JScript-specific global func-
tion ActiveXObject. If object is created, we get its exact version and check it against the registry of
CLSID prefixes (suffixes are the same for all versions). If a match is found, we write the <OBJECT>
tag in place. If we fail for any reason (the wrong environment, no OWC installed), the problem de-
scription is provided.
Note that the complete scripting part of Listing 15.6 is enveloped in a single anonymous function
call:
(function(){
/* CODE HERE */
})();
Here’s how you can read this: an expression that returns an anonymous function and immediately
executes it. Quite simple but a powerful technique. First, all variables declared in the function are,
naturally, encapsulated in the scope of the function. Therefore global scope isn’t polluted; there’s
no chance to override global variables accidentally with the same names. Second, we may exit from
the function early with a return statement – in traditional “global” script we’d rather use nested
if/else statements.
Once we complete embedding the OWC SpreadSheet and the Flex application shown in the previ-
ous section, we get a page that results in this:
<html lang=”en”>
<!-- File ./html-template/FxSpreadsheet.template.html -->
<!-- Flex / Spreadsheet OWC communications example -->
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” />
<title>Flex <-> Spreadsheet OWC example</title>
<style type=”text/css”>
var missedNotification = false; // Changed to true if Flex loads data quicker then
page initialized
/* JavaScript callbacks invoked from Flex */
var fxMetadata, fxRowsUpdated, fxRowsInserted, fxRowsRemoved;
/* JavaScript callbacks invoked from Excel */
var xlOWCEvents;
(function(){
var MISSED = function(){missedNotification = true; };
fxMetadata = MISSED; /* function(meta) {} */
fxRowsUpdated = MISSED; /* function(offset, content, reset) {} */
fxRowsInserted = MISSED; /* function(offset, content) {}; */
fxRowsRemoved = MISSED; /* function(offset, count) {}; */
window.onload = function() {
var xlOWC = document.getElementById(“xlOWC”)
if (!xlOWC) return; // No OWC component available
setupFxMetadata();
setupFxDataNotifications();
setupXlDataNotifications();
setupXlContextMenu();
Listing 15.7 The final HTML page for the OWC integration sample
The page is being initialized in two phases: when HTML starts loading and after the complete page
content is available (see the window.onload event handler in Listing 15.7). During the first phase
we provide a fallback implementation for both Flex notifications and Spreadhsheet OWC event
handlers (packaged as xlOWCEvents object methods). You may be surprised to see that both groups
of methods contain no real functionality. Let’s assure the reader that the content of these methods
is going to be dynamically reassigned later. For now, we keep them at bay so that no harm is done
if they are invoked in the unsupported browser or at the wrong time.
To understand the kind of problems we’re trying to avoid, imagine that our HTML page with an
OWC example is opened in Firefox. The Spreadsheet control is unavailable in this environment,
but the Flex application can run successfully (as long as the Flash plug-in is installed). The very
first notification from Flex would cause a JavaScript error if the corresponding handler attempted
to access a non-existing control. Sure, it’s possible to add the necessary check to every notification
handler. However, this is code duplication.
The second sort of problem we solve with “empty” notification handlers are timing-related. The
SWF file is loaded asynchronously with the rest of the page and the fxMetadata notification is fired
immediately from the onCreationComplete event handler (see Listing 15.3). Hence, the HTML
page may get this notification earlier when the Spreadsheet ActiveX control is inserted and/or fully
initialized. That’s why notification handlers in this phase contain no functionality to update the
Spreadsheet OWC; they all set the flag missedNotification to requery notifications from Flex when
initialization is complete.
The second phase of the page initialization is executed when the window.onload event happens.
It starts by looking for the xlOWC HTML element that we attempted to dynamically instantiate in
Listing 15.6. If no object is returned for this ID, there’s no sense in taking further action – HTML is
running in the unsupported environment. Otherwise initialization continues and the reference to
the second ActiveX control, Flash Player running the Flex application, is stored as well.
Next, the window.onload handler declares several metadata-related variables. Briefly, these vari-
ables describe the structure of the records coming from the Flex application and the associated
rules to convert field values back and forth between Flex and the Spreadsheet (we’ll make full use of
these variables in the fxMetadata notification handler a bit later). As long as we need a bidirectional
communication channel, two mapping structures are required:
• The number-indexed COLUMNS_XL array defines the mapping between the Spreadsheet
column numbers and ActionScript field names. The position in this array corresponds to the
index of the column.
• The associative COLUMNS_FX array defines the mapping between the ActionScript field
name and the column index. The key in this array is the name of field.
The variables COLUMN_COUNT and ROW_COUNT hold the number of available fields (columns)
and records (rows) correspondingly. Strictly speaking, ROW_COUNT relates to the data rather than
to metadata.
To discuss the next variable – xlSheet – we at least need a recap of the Microsoft Excel/Spreadsheet
OWC object model, which we’re going to provide right here in a “Shakespeare on the eggshell”
format.
The root of the object hierarchy is the Application object. For Spreadsheet OWC it’s the control
itself. Every Application contains a collection of Workbooks, every Workbook, in turn, holds a col-
lection of Worksheets. Many objects in the hierarchy have a notion of “active” sub-elements. Active
means “currently visible to the user and ready to accept the user’s input.” So an Application has an
ActiveWorkbook, and a Workbook has an ActiveSheet. Transitively, Application has an ActiveSheet
property as well.
When a Spreadsheet control is initialized, it pre-creates one active Workbook with three Worksheets;
the first Worksheet is active. It’s the reference to this very worksheet that’s stored as an xlSheet vari-
able during the initialization time.
Remember, there are a number of differences between existing OWC versions. To keep track of the
currently used OWC version we defined the variable xlVersion. The version differences come into
play immediately. In fact, everything we’ve said about the object model is true for the Microsoft Ex-
cel application and Spreadsheet OWC of versions 10/11, but doesn’t stand for Spreadsheet version
9, which uses a completely different API. There are no such things like Workbook, Worksheet, and
the collections thereof in OWC9. The Spreadsheet is a mix of Application with a sole active Work-
book that has one and only one (active) Worksheet. However, the combination of the Microsoft
COM late-binding mechanism, the JavaScript “duck typing,” and the similarities between Spread-
sheet and Worksheet APIs let us treat Spreadsheet as a Worksheet in certain cases: at least OWC9
functionality is enough to implement Flex-to-Spreadsheet communications fully; when it comes
to anything beside this, our script degrades gracefully.
XLConstants provides a shortcut to all constants used in the Spreadsheet OWC methods. In script-
ing languages like JScript or VBScript there’s no way to refer the constants declared in ActiveX-type
libraries by name. Hence, every OWC control exposes a set of constants as its own complex prop-
erty.
Just before returning from the window.onload event handler, when all setup and preparation is
done, a check for lost notifications from the Flex application is done. If there are any, the Flex ap-
plication is asked to resend notifications for both metadata and available data entries (see fxGrid.
xlResend() invocation).
function setupFxMetadata() {
function AS_IS(v) { return v; }
function variantDate2jsDate (v) { return null == v ? null : new Date(v); }
XL_FORMATTERS = {
date: variantDate2jsDate, time: variantDate2jsDate, dateTime:
variantDate2jsDate,
boolean: function(v) { return v == null ? null : !!v; },
string: AS_IS, number: AS_IS
};
fxMetadata = function(meta) {
meta = meta || [];
ROW_COUNT = 0;
fxRowsUpdated(0, [], true);
COLUMNS_FX = {};
COLUMNS_COUNT = meta.length;
COLUMNS_XL = new Array(COLUMNS_COUNT);
var xlHeadings;
if (xlVersion >= 10) {
var xlWnd = xlOWC.activeWindow;
xlWnd.resetHeadings();
xlHeadings = xlWnd.columnHeadings;
}
else {
var FAKE_HEADING = {};
xlHeadings = function(idx) { return FAKE_HEADING; }
}
field.fx = FX_FORMATTERS[field.type];
COLUMNS_FX[field.name] = field;
xlHeadings(i + 1).caption = field.title;
}
}
}
When our JavaScript is notified of metadata changes (the function fxMetadata), it must do several
things. First, it’s necessary to reset all existing variables that are related to the metadata. We also
need to drop the existing content. Otherwise the user will be confused to see a logical mismatch
between column headings and cell content. Afterwards, the handler re-creates JavaScript metadata
variables according to parameters from ActionScript.
We use the active Window instance to overwrite a default text of column headings with user-friend-
ly field titles (compare the Spreadsheet column heading texts in Figures 15.2 and 15.3). Note that
though the Window object is present in both Excel and Spreadsheet OWC 10/11, the column/row
headings functionality is unique to the Spreadsheet component. As you can see from the work-
around applied, Spreadsheet OWC 9 has no such functionality.
The remaining part of the code in Listing 15.8 deals with type formats. Excel is smart enough to
auto-format a cell based on the values entered. So if we transform the original value to the Excel-
friendly form, the necessary formatting will be applied automatically.
Be aware that the primary scripting language of Microsoft Office Applications is Visual Basic. It
could either be VBA inside Office applications or VBScript for Office Web Components. In fact, the
very first Visual Basic customer was the Microsoft Excel team!
Many Visual Basic features may look strange from the JavaScript perspective. One of them, for ex-
ample, is that indexing in Visual Basic starts from 1 (one) whereas in JavaScript or ActionScript it
starts from 0 (zero). So be prepared to see “row + 1” statements here and there in example code.
The second issue is that the presentation of certain types differs between Visual Basic and JScript.
The most problematic one is Date. Visual Basic accepts a date as a variant of the VT_DATE type. Un-
der the hood, it’s a floating-point value, counting days since midnight December 30, 1899. Hours
and minutes are represented as fractional days. In the ECMAScript family of languages like JavaS-
cript, ActionScript, or JScript, a date is represented as an object of the Date type and its internal
representation is the number of milliseconds since January 1, 1970. There’s enough differences to
get upset!
That said, Excel is smart enough to parse the date from a string in several formats3, for example,
“2006-06-04 14:30:30” is recognizable as a date/time value. The set of FX_FORMATTERS for date/
time types uses this feature. The values of other JavaScript types can be safely passed to Excel as is.
While moving the data in the opposite direction, we need to convert VT_DATE to JavaScript. Thank-
fully, it’s just a Date constructor call with VT_DATE as an argument (see the variantDate2jsDate
function in Listing 15.8), a neat undocumented feature of JScript. For fields defined as Boolean we
need to ensure that the value entered in the Spreadsheet is indeed Boolean. To that end we apply
the good old JavaScript “negation of negation” idiom to convert the value entered to the Boolean
type:
You may have noticed that we are updating the metadata field objects that come from ActionScript.
Such updates don’t affect original objects in ActionScript due to the marshaling used by the Exter-
nal API protocol (we’ll discuss this later).
The number of methods to get the Range object in the Excel/Spreadsheet OWC far outweighs the
number of ways to skin a cat. Depending on your needs, it’s possible to construct a Range from a
Worksheet supplying the pair of top/left and bottom/right cells; it’s possible to get a Range by the
name of the cells (for example, “A1:B2”); there’s a notion of an active cell and current selection; the
result of the intersection/union operations on ranges is, obviously, Range as well. For a complete
list see the Excel VBA documentation available with the Office Web Components.
A Range is a very efficient abstraction when it comes to data operations or formatting. If you read a
value from the Range, the value returned is taken from the top-level cell. When you assign an indi-
vidual value to the Range or modify its visual property like FillStyle it affects all cells in the Range.
The code we’re going to present in Listing 15.9 reacts to data changes on the Flex side and
modifies the Spreadsheet accordingly. In essence, it sequentially assigns values to individual
cells. This approach has a serious associated performance penalty. The cost of multiple as-
signments and in general the cost of multiple calls across COM object boundaries is inherent-
ly high. To make things worse, with JScript and VBScript we’re limited to the COM IDispatch
interface.
We’ll address the performance improvements later, when instead of individual value assignments
we’ll use another feature of Range – the support of tabular data assignments such as pasting HTML
content from the clipboard or copying values from ADODB.Recordset. In these cases Range forces
data to be split up into individual values, one per cell.
function setupFxDataNotifications() {
function xlCopyCells(offset, content) {
for (var i = content.length - 1; i >= 0; i--) {
var obj = content[i];
var row = i + 1 + offset;
for (var name in COLUMNS_FX) {
var col = COLUMNS_FX[name];
xlSheet.cells(row, col.idx).value = col.fx(obj[name]);
}
}
}
function xlTransaction(fn) {
xlOWC.enableEvents = false;
xlOWC.beginUndo();
try { fn(); }
finally {
xlOWC.endUndo();
xlOWC.enableEvents = true;
}
}
if ( !count ) return;
Methods xlCopyCells and xlTransaction are used by Flex data change notification handlers. The ra-
tionale behind xlCopyCells is clear. Given a zero-based offset and content as an array of objects, the
method assigns a value of every property to corresponding cells. This is where the FX_COLUMNS
associative array comes in handy. It provides a way to both order properties and get correct format-
ing function to convert values as necessary.
The xlTransaction method is a pure function decorator. First of all, it disables notification events
from Spreadsheet OWC when we’re modifying cells. Otherwise, there’s a risk of either getting into
infinite recursion or issuing an unnecessary update to the Flex application. Second, it lets us enlist
a set of operations for a single undo “command,” or otherwise users might be surprised with the
number of clicks needed to undo the changes on the Spreadsheet side of a single atomic record
insertion/modification/deletion done on the side of the Flex application.
On a side note, beginUndo/endUndo functionality isn’t unique to Spreadsheet OWC. Similar function-
ality exists in Excel. But it’s implemented in a different way as the Application.OnUndo(“MenuText,”
“ProcedureName”) method.
The Flex notification handlers fxRowsUpdated, fxRowsInserted, and fxRowsRemoved are quite
easy to follow. All of them pass processing blocks as function closures to xlTransaction. For the
insertion/deletion of rows we first get the complete row from an existing Range via the xlSheet.
rows(idx) call. Both insert and delete methods have optional parameters that define how to shift
the remaining cells. However, if Range is a complete column/row we can safely skip this parameter.
Note how we use “key notation” inside fxRowsRemoved to avoid using dot notation against the
delete, which is a JavaScript keyword.
So far we’ve enabled the Spreadsheet population with data from the Flex application. Users can
edit data in Flex and changes are automatically propagated to Spreadsheet.
function setupXlDataNotifications() {
xlOWCEvents.sheetChange = function(sheet, range) {
if (!ROW_COUNT || (xlSheet != sheet)) return;
xlOWC.enableEvents = false;
try {
var r1 = range.row;
var c1 = range.column;
var rc = range.rows.count;
var cc = range.columns.count;
if (r1 > ROW_COUNT || c1 > COLUMNS_COUNT) return;
The xlOWCEvents.sheetChange method gets two parameters from the corresponding event: the
reference to the Worksheet where the event occurred and the range of affected cells. Potentially,
this range can be large enough to freeze the program forever. Imagine a use case where a user se-
lects several columns and presses the Delete key. The Range parameter for such an event contains
2^16 rows. Clearly, processing all of them would take an unacceptable amount of time. So the first
thing the event handler above does is restrict the processing area to some reasonable region. In
our case it’s an intersection of the parameter range with (1,1) : (ROW_COUNT, COLUMN_COUNT)
area. After getting correct boundaries the only thing left is to construct the payload for the Flex
xlImportRows method.
Let’s stress that the above method supports fine-grained change notifications. If the user updates
a value only in one cell, then exactly one property of a single object will be updated. If the user
selects a range of cells and updates them at once (as a rule via copying clipboard data or deleting
values), then the update package will contain only the rows affected with every row containing
only affected properties. The xlImportRows method on the Flex side knows about this feature and
behaves accordingly.
The definition of the xlOWCEvents.sheetChange method on its own, however, isn’t sufficient. This
is where the following strange script block comes into play:
This is an MSIE-specific way to attach event handlers. A script block must contain a FOR attribute
that specifies an ID of the source HTML element and EVENT attribute that describes an event sig-
nature. Variable names used inside an event signature may be used in a script block to access event
parameters. If the browser can’t find an HTML control with the ID provided, or a control doesn’t
expose the event with the name specified in the signature, then the script block is simply ignored.
So a Spreadsheet OWC 9 that has no SheetChange event will be safely taken out of the game with
no additional coding.
It’s worth mentioning that certain browsers have no clue what FOR and EVENT attributes are for
(no pun indeed). But once they see a script block, they just execute it. Do you recall that initially
(see Listing 15.7) we created xlOWCEvents with “empty” methods? Now you know what we did it for
– to prevent users of non-Microsoft browsers from JavaScript errors during page loading.
Another important thing: a separate FOR/EVENT script block is the only valid way to assign an
event handler to an ActiveX control. If you try to do the same thing via a DOM Level 0 event-han-
dling mechanism like ay of those below:
you end up with a new property of the Function type in an OBJECT HTML element (a so-called
“expando” property) instead of an event handler. If you try an MSIE variation of the DOM Level 2
mechanism:
you can attach an event handler, but it will cause Spreadsheet OWC/Internet Explorer to crash
sooner or later. Try to attach an empty event handler to the SheetChange event this way and edit
8-15 cells. You’ll be forwarded to Microsoft’s support center by a gentle quality feedback agent. It’s
hard to say for sure, but attachEvent seems to have issues with certain ActiveX threading models.
The remaining block enhances our example with a custom Spreadsheet menu, the ability to save
Spreadsheet content to the local file system, and several other miscellaneous functions:
function setupXlContextMenu() {
function copy_vb_array(variant) {
var vba = new VBArray(variant);
var low = vba.lbound(1), high = vba.ubound(1);
var res = new Array(high - low + 1);
for (var i = low, idx = 0; i <= high; i++) {
var itm = vba.getItem(i);
res[idx++] = typeof itm == ‘unknown’ ? copy_vb_array(itm) : itm ;
}
return res;
function clone_array(src) {
var size = src.length;
var copy = new Array(size);
for (var i = 0; i < size; i++) {
var itm = src[i];
copy[i] = itm && itm.prototype == Array ? clone_array(itm) : itm;
}
return copy;
}
var customCommands = {
cmdSaveXls: function(){saveFile(XLConstants.ssExportXMLSpreadsheet)},
cmdSaveHtml: function(){saveFile(XLConstants.ssExportHTML )},
cmdSendData: function() {
var region = xlSheet.cells(1, 1).currentRegion;
if (!region) return;
var size = region.row - 1 + region.rows.count;
var items = new Array(size);
for (var i = 0; i < size; i++) {
var row = i + 1; var item = {};
for (var j = 0; j < COLUMNS_COUNT; j++) {
var col = j + 1;
var prop = COLUMNS_XL[j];
item[prop] = COLUMNS_FX[prop].xl( xlSheet.cells(row,col).value );
}
items[i] = item;
}
fxGrid.xlImportRows(0, items, true);
ROW_COUNT = items.length;
} ,
cmdClearFormats: function(){xlOWC.selection.clearFormats()},
cmdClearValues: function(){xlOWC.selection.clearContents()},
cmdClear: function() {
xlOWC.beginUndo();
try {
var r = xlOWC.selection;
r.clearFormats();
r.clearContents();
}
finally { xlOWC.endUndo(); }
}
};
var cmClearSubMenu = [
[“&All”, “cmdClear”], [“&Formats”, “cmdClearFormats”], [“&Values”,
“cmdClearValues”]
];
// Place “Clear” within other edit commands
ctxMenu.splice(5, 0, [“Clea&r”, cmClearSubMenu]);
// At the very end of menu add Save / Send to Flex
ctxMenu.push(
null /* separator */, [“Save...”, “cmdSaveXls”], [“Save as HTML...”,
“cmdSaveHtml”],
null /* separator */, [“Send data to FlexGrid”, “cmdSendData”]
);
To add our own context menu commands we need to handle at least two events: BeforeContext-
Menu and CommandBeforeExecute. BeforeContextMenu alters or replaces the default menu sup-
plied by a parameter, while CommandBeforeExecute will help us perform a concrete action when
the user selects the menu item.
Note that the menu parameter of BeforeContextMenu comes as a special ByRef type introduced
by Spreadsheet OWC to support in/out parameters (unlike Visual Basic neither the JScript nor VB-
Script support parameter is passed by reference). Variables of ByRef type have a single property
– value.
Altering the context menu is really a tricky part. When you read the menu’s value you get a Visual
Basic Array (VT_ARRAY). Every item of this array is either a [Text, CommandIdentifier] pair or a
[Text, Submenu] pair to accommodate the arbitrary nesting of submenus. In a sense you are getting
an array of arrays. Before you can do anything else you have to convert the original menu to the
JavaScript Array – see the recursive copy_vb_array function that does the trick. Handling recursion
here is quite easy given that the JavaScript typeof fairly reports “unknown” (and undocumented,
one might add) for VT_ARRAY.
Next we can extend the menu with its own items using convenient JavaScript Array methods like
splice and push. There are two options for command identifiers: integer codes and strings. Integer
codes are reserved by the Spreadsheet OWC so you can only use the ones defined in XLConstants
to override the behavior of the existing commands or add existing commands if they’re not avail-
able by default. String identifiers are at your disposal to implement custom commands. To insert
separator, use null as the menu item.
Remember we converted menu’s value from the VB array to the JavaScript array for modifications?
Funny enough, there’s no need to convert the modified array back to a VB array before assign-
ing it to a menu.value. There’s another “subtle” problem specific to OWC 10. If a corresponding
JavaScript array length has been changed after creation (as a result of assigning an element with
the index higher then or equal to the length, invoking push or splice on an array, etc.), the menu is
reported as “invalid!” The only workaround is to deep clone the already-built array, supplying the
exact length to the constructor at every step.
up via the registry of custom commands and executes one, if found. In this case we have to cancel
the default menu processing.
There are three commands of particular interest (see object customCommands in Listing 15.11).
Two of them – cmdSaveXls and cmdSaveHtml – save the content of the Spreadsheet OWC Compo-
nent in a corresponding Excel XML and HTML format. Saving a file to the local file system is subject
to security restrictions. So be prepared. These functions may or may not work on a particular client
computer depending on its security settings.
The third command, cmdSendData, sends a complete data set back to the Flex application. In the
current implementation this is the only way to add rows directly in the Spreadsheet while the xlOW-
CEvents.sheetChange event handler ignores any sheet content beyond ROW_COUNT. The xlSheet.
cells(1, 1).currentRegion lets us get a continuous region from the first cell to anything bounded by
an empty row and empty column. Values from this region are packed as parameters to fxGrid.xlIm-
portRows() the same way it was done in xlOWCEvent.sheetChange() (see Listing 15.10).
Note that we don’t disable Spreadsheet events when executing “Clear” commands unlike the xl-
Transaction for Flex data notifications (see Listing 15.9). Now when a SheetChange event is fired as
a result of a “Clear” command execution, the Flex application content will be cleared as well.
We’re done. Looking back at Listings 15.3 and 15.7 through 15.11, you may have the feeling that this
was all rather complex. However, the complexity is entirely associated with the enormous Spread-
sheet OWC API, VB/JScript type conversions, plain OWC bugs, and undocumented JScript features.
On the bright side, all the code related to the Flex External API was straightforward and easy to
follow.
While being complex, OWC Spreadsheet/Flex integration presents a nice option for hybrid HTML/
Flex solutions. On this note we’d like to mention another OWC control – PivotTable, which offers
functionality unmatched in Flex. Integration with PivotTable, however, is beyond the scope of this
chapter.
Listing 15.12 presents a slightly modified version of the Flex application used in our previous ex-
ample. We removed code related to External notifications and, for simplicity, dropped the fxMeta-
data() function in favor of a static constant array or metadata. What we’ve added here is a “Copy to
clipboard” button with the action handler:
[Bindable]
private var employees:ArrayCollection = new ArrayCollection();
[Bindable]
public var bhiOptions:Array = [{label: “No”, data:false}, {label:”Yes”, data:
true}];
var html:XML =
<html
xmlns:x=”urn:schemas-microsoft-com:office:excel”
xmlns:o=”urn:schemas-microsoft-com:office:office”>
<body><table></table></body>
</html>;
var table:XML = html.body[0].table[0];
for (var cursor:IViewCursor = employees.createCursor(); !cursor.afterLast;
cursor.moveNext() ) {
var el:Object = cursor.current;
var row:XML = <tr/>;
for (var idx:int = 0, cnt:int = META.length; idx < cnt; idx++) {
var prop:Object = META[idx];
var name:String = prop.name;
System.setClipboard( html );
if (ExternalInterface.available) {
var retVal:Object = ExternalInterface.call( “fxCopyContent” );
if (retVal) Alert.show(retVal.message + “: “ + retVal.rows + “x” + retVal.
cols);
}
: “”;
}
The Flex application above puts HTML with employee data on the clipboard. Run the application,
invoke “Copy to clipboard,” open any text editor, and “paste.” You’ll see formatted HTML source,
generated by our Flex application, as shown in Figure 15.5.
Of all the options, such as fixed width, CSV, and tab separated, we’ve resorted to HTML for a reason.
You may notice that we generated a bit of unusual HTML. Some HTML elements and attributes
mention an Office Excel namespace. If you recall our Spreadsheet OWC integration example, you
can draw parallels with the handling of certain data types. To prove your guess you should open
Excel and paste the clipboard content there. Bingo! The cells are populated from the HTML table.
Note that this feature is unique to Excel. Neither Word nor Frontpage does the same. Excel is liberal
enough with the type of clipboard data: even when the type is plain text, Excel tries to figure out
whether the content is HTML.
To take advantage of type-specific Excel formating, we repeated the trick with date type. To force
True/False formating of Boolean values, however, we had to explicitly define Excel-specific attri-
butes on the TD element.
Figure 15.6 presents the embedding results. The same Flex application FxClipboard is running as ActiveX
inside the Excel worksheet FxClipboard.xls. Whenever you modify the data in a Flex application, the up-
dates are instantly propagated to the cells of the worksheet. This intimacy between an embedded Flex
application and Excel will come in handy later when we establish Flex-to-Flex talk via LocalConnection.
For now, there’s work ahead. We need to build communication accommodating FxClipboard.xls.
Straight ahead. Although it’s possible to activate the “View/Toolbars/Control Toolbox” toolbar in
Excel and then insert “Shockwave Flash Object” from the set of additional ActiveX controls, we
choose the more challenging option of embedding a Flash Player ActiveX control dynamically. Ob-
viously, we need a bit of VBA code here.
The code in Listing 15.13 opts to VBA early binding, i.e., uses variables of concrete types from the
ActiveX type library rather than a generic Object type. Accordingly, it’s necessary to add the type
library reference to all used libraries. We need to add just an explicit reference to “Shockwave Flash
Object” while references to Office and Excel libraries always add automatically on the first use of a
VBA editor for a given Workbook.
Microsoft users learned the danger of VBA macros loaded from untrustworthy sources the hard
way. So, by default Excel has a very pessimistic security policy: “Don’t execute macros at all.” This is
way too restrictive for our example though, so to execute it you’d have to lower the security settings
to at least medium, see Figure 15.7. (Medium requires confirmation of the macros every time the
document is opened.)
When all prerequisites are met, go to the VBA editor (F11) and add the following to the Workbook
module:
‘ File ./FxClipboard.xls
‘ Object module ThisWorkbook
Private fxProxy As FlexProxy
Private Sub Workbook_Open()
Set fxProxy = New FlexProxy
fxProxy.Initialize 1, “fxObject”
End Sub
We’ve just declared an event handler for a workbook Open event. The event handler instantiates a
helper FlexProxy class that does all the work. Now use the Insert/Class module to add a class mod-
ule, rename it FlexProxy, and add the following from Listing 15.14:
‘ File ./FxClipboard.xls
‘ Class module FlexProxy
Option Explicit
Private WithEvents pSheet As Excel.Worksheet
With oleObject
Call .BringToFront
Call .Activate
End With
With pFlexObject
.Loop = False
.Menu = True
.Playing = False
.EmbedMovie = False
.AllowNetworking = “all”
.AllowScriptAccess = “always”
If Not found Then
.LoadMovie 0, “../bin/FxClipboard.swf”
End If
End With
Call PositionOleControl
End Sub
pFlexObject.SetReturnValue _
“<object>” & _
“<property id=’message’><string>” & “Data copied to Excel” & “</
string></property>” & _
“<property id=’rows’><number>” & rows & “</number></property>” & _
“<property id=’cols’><number>” & cols & “</number></property>” & _
“</object>”
Else
End If
ExitSub:
Application.EnableEvents = True
End Sub
Call pSheet.Cells.Clear
‘-------------------------------
Target.PasteSpecial xlPasteAll
‘-------------------------------
Call pSheet.Activate
Dim newSelection As Range
Call newSelection.CurrentRegion.Columns.AutoFit
Call newSelection.Select
Call PositionOleControl
pOleControl.Left = 10
If allCells Is Nothing Then
pOleControl.Top = 10
Else
pOleControl.Top = allCells.Top + allCells.Height + 10
End If
The public Initialize method is the main initialization routine for FlexProxy. In VBA it’s impossible
to use a parameterized constructor, so we’ve moved all the setup code here. We check the avail-
ability of a Flash Player control by iterating over the OLEObjects collection that holds every ActiveX
object available on the worksheet. If a control isn’t found, we create and add this object to the
collection using the OLEObjects.Add method. Visual Basic supports both named and positional
parameters. A lot of OLEObjects.Add arguments are irrelevant in our use case. The only important
one is the ClassType that defines the ProgID of the ActiveX object to embed; all the rest define the
control position. Accordingly, we resort to named parameters as the simplest option.
When reopening the workbook with the embedded Flash Player, a corresponding SWF movie (com-
piled from FxClipboard.mxml, see Listing 15.2) starts playing automatically, so it’s necessary to call
LoadMovie explicitly in case we just added the Flash Player control. The path to FxClipboard.swf is
relative to the Excel document. Adjust it as necessary (see Listing 15.14, method Initialize).
The next method, pFlexObject_FlashCall, is of particular interest. It deals with handling notifica-
tions of the External API, but this time in a desktop application.
The FlexProxy class module defines an instance variable pFlexObject type of ShockwaveFlashOb-
jects.Shockwave.Flash. The variable is declared using a “With Events” statement that enables
attaching event handlers to the object. The event handler must be a procedure with the name
VariableName_EventName. This procedure’s signature must match the order and types of event
parameters. In the case of the Flex External API there’s only the Request parameter of the String
type. But, in fact, it’s a serialized form of a complex XML document. The format of this document
deserves a close look and we dedicate the following section to it.
There are two parts to the XML format used by the External API: the first part is used to represent
function calls and the second one defines the formatting of individual values. The second part is
used to marshal function parameters and return values.
The root node is the <invoke> node. It has two attributes: name, containing the name of the func-
tion to call, and returntype, which has to be the XML for the ActiveX container other than the HTML
page5. If the function call has parameters, the <invoke> node contains the <arguments> child node
with individual parameter values formatted, as we’ll explain a bit later. Our trivial non-parameter
notification Request looks like this:
Now you can see the naïve approach used to check the method name in the pFlexObject_FlashCall
from Listing 15.14:
If the request prologue looks like a fxCopyContent notification, the event handler delegates the pro-
cessing to the UpdateRows method that just pastes the content of the clipboard into the worksheet
starting with the cell (1,1).
To set a return value from an ActiveX container you must use the SetReturnValue method on a
Flash object. This method can be invoked only in the CallFunction event handler. If an invocation
of the SetReturnValue is omitted, ActionScript receives undefined as a return value from the Exter-
anlInterface.call. Otherwise the ActionScript object parsed from the XML is returned. For example,
we reply with a message about the successful operation and the number of rows/columns copied.
The encoded XML form of the return value is the following:
<object>
<property id=”message”><string>Data copied to Excel</string></property>
<property id=”rows”><number>8</number></property>
<property id=”cols”><number>6</number></property>
“</object>”
On the ActionScript side this is transformed to an Object with the fields message, rows, and cols.
To illustrate support for all Action Script classes both as <arguments> in the CallFunction method/
FlashCall event and as a result returned with the SetReturnValue, the complete formating scheme,
shown in Table 15.2, includes data type information in addition to the actual values:
Null <null/>
Boolean true <true/>
Boolean false <false/>
Number, int, uint <number>3.14</number>
<number>-255</number>
String <string>Hello, Flex!</string>
Date <date>1151614800000</date> The encoded value is the number of mil-
liseconds since January 1, 1970, the same
result as Date.getTime() or Date.valueOf()
Array <array> Elements can be any supported type; mixed
<property id=”0”> types are supported and arbitrary nesting
<string>”ABC”</string> is allowed. The <property> node defines
</property> individual elements, and the ID attribute is
<property id=”1”> the numeric, zero-based index.
<string>”XYZ”</string>
</property>
<property id=”2”>
<number>128</number>
</property>
...
</array>
Object <object> Individual properties are defined in the
<property id=”name”> <property> element; the ID attribute is the
<string>Alex Whitney</ property name (a string).
string>
</property>
<property id=”salary”>
<number>72000</number>
</property>
...
</object>
Custom object <null> or <object></object> Either a null or empty object. Any proper-
ties of the custom objects are lost.
The set of supported types is rich enough to serialize the structure of almost any complexity and
nesting except with two limitations. The first one is the lack of support for custom objects. The sec-
ond serious restriction of the External API is that it doesn’t handle recursive structures correctly, or
strictly speaking, it doesn’t track visited objects during marshaling at all:
When the following ActionScript snippet is invoked, the External API XML serializer falls into infi-
nite recursion that ends up with a StackOverflow exception.
Be aware that serialization to/from XML has its own associated cost in non-linear dependency so
passing large objects via the External API can seriously slow your application down. As a general
rule, always analyze what exactly is necessary on either side of the ExternalInterface invocation
and avoid sending a complete graph of the objects if only a subset of the data is sufficient.
LocalConnection 101
LocalConnection has been available since Flash 6.0. There’s a saying that it takes two to lie: one to
lie and one to listen. The same rule applies to LocalConnection: you need one SWF file that sends
notifications and another one that listens to the notifications.
The first SWF file is commonly called the sending SWF file; it’s the application that invokes the
method on the other application. The sending SWF file must create a LocalConnection object and
call the send() method. The second SWF file is called the receiving SWF file; it’s the application
whose method gets invoked. The receiving SWF must create another LocalConnection object and
call the connect() method.
security errors */ }
A corresponding receiving application in its connect() call matches the name used in the
send()above and provides the implementation for the remoteFunction and any other functions in-
voked by sending applications:
receivingLC.client = this;
receivingLC.connect( “MyConnection” );
...
Importantly, only one serving application is allowed per connection. In other words, only one ap-
plication may successfully call LocalConnection.connect() with the given connection name at a
time. If you attempt to connect() with the same name from the second LocalConnection, an Argu-
mentError will be thrown.
The core driver of LocalConnection is defined via the client property. This property should reference
the object that implements methods remotely called via send(), so in the code above we set it to this
reference, pointing to receiving the application itself. If the receiving application doesn’t implement
the “sent for” method (the method isn’t present, the function name is misspelled, the number or
types of method parameters doesn’t match expectations of the send()), a runtime AsyncError will
be thrown. Note that it’s the receiving application that will be getting the exception. Don’t attempt
to catch the AsyncError with a regular try/catch block; since the remote function is invoked asyn-
chronously, you may only assign a listener for the AsyncErrorEvent and follow up with the custom
error-handling strategy.
The remote function in the code snippet above is declared void. This is not accidental; in fact, it’s
a major limitation of LocalConnection: all communications are one-way; you may not get a reply
from a receiving application like you would with the External API.
You may have noticed that we supplied listeners for Status and SecurityError events for the send-
ing LocalConnection. Both events are fired as a result of the send() method. Status reports carries
well the status of LocalConnection for every invocation of the send() – either status or error – see
the property level of the event. For instance, you may get an error event when no listening applica-
tion is running. A SecurityError event is raised when send() attempts to cross the security sandbox
boundaries.
In the simplest case when both applications originate from the same domain, LocalConnection
communications are enabled with no additional effort. This happens, in particular, when you use
just the name of the application without specifying a domain name.
The more complex case is when applications are loaded from different domains. Assuming both
sending and receiving applications know the names in advance, the following must be done for
LocalConnection communication:
1. A receiving application must enable the sending domain with an explicit receivingLC.
allowDomain(“sender.domain.com”) or an indiscriminate receivingLC.allowDomain(*). Make
no mistake, allowDomain is called on the LocalConnection object, not to be confused with
Security.allowDomain(“domain”)!
2. A receiving application must connect() using a “plain” connection name: receivingLC.
connect(“MyConnection”);
3. A sending application must use a connection name qualified with the domain prefix: send-
ingLC.send(“sender.domain.com:MyConnection”, “remoteFunction”, args).
Instead of typing the full domain name prefix, you can use a connection name that starts with an
underscore like “_MyConnection” on both sides. Either way, the receiving application must allow a
domain with an allowDomain() call.
If you don’t specify an explicit domain prefix, or if you use a name beginning with “_”, LocalCon-
nection adds the default prefix of the SWF origin domain to the name of the connection for both
the send() and connect().This enables strict, yet flexibly configurable security and helps avoid name
clashes between SWF files coming from different vendors (and, hence, from different domains).
You may think of a qualified connection name as a name defined in a certain namespace. Note
that you can’t define the explicit domain prefix with the connect() method of the receiving connec-
tion. To understand how security and the namespacing mechanism work together, let’s consider
examples of the three security options above.
In the simplest case, assume that both the sending and receiving SWF files are loaded from the
www.theriabook.com site. The actual name of the connection in both cases is the “theriabook.com:
MyConnection” and hence the matching receiving connection for LocalConnection.send will be
found once the unqualified connection name is converted to the qualified one.
Now, imagine that the sending application is loaded from www.other-domain.com. In this case
a default qualified name of the sending connection is “other-domain.com:MyConnection” and
there’s no matching receiving connection. However, once you do receivingLC.allowDomain(“other-
domain.com”) the LocalConnection API creates some internal matcher that connects the “theri-
abook.com:MyConnection” name and “other-domain.com:MyConnectionName,” allowing other-
domain.com.
Finally, if a connection name starts with an underscore, no domain prefixes are added on either
side. So the matching connection can be found by default. However, the receiving security man-
ager prevents incoming calls originating from other domains. So, again it’s necessary to explicitly
allow the sender’s domain or, subject to your discretion, allow all with receivingConnection.allow-
Domains(“*”).
There’s another LocalConnection API limitation that’s worth mentioning. The amount of data you
can pass with LocalConnection.send is limited to 40KB in serialized form. If you exceed this limit,
you’ll get an ArgumentError exception. The only way to overcome this limitation is to send chunks
of data. Sadly, the serialization format isn’t documented, so it’s hard to imagine another algorithm
to calculate the size of the chunk except by trial and error.
Typically, the receiving LocalConnection is automatically destroyed when its reference variable is
garbage-collected. If the receiving LocalConnection is declared an application variable, the con-
nection is destroyed when the SWF file is unloaded. You can also programmatically close the con-
nection using an explicit close() call. Once the connection is closed, you may reconnect with the
same connection name from any Flex application, including the original one.
Table 15.3 summarizes the functionality available for LocalConnection running in both sending
and receiving modes:
As previously discussed, we need a Flex agent to interface with Excel via the External API. The code
for the corresponding application – FxExcelAgent – is presented in Listing 15.15.
According to our plan, FxExcelAgent and a regular Flex application communicate with each other
using the LocalConnection API. Actually, since LocalConnection provides only one-way commu-
nication, we need two connections to enable data exchange in both directions: outConnection,
dedicated to forwarding External API calls to a Flex application, and inConnection, promoting re-
ceived notifications to Excel.
The initialization of the agent starts with an External API availability check. The existence of the
External API is mandatory for FlexAgent; if it’s unavailable the agent is useless and no further ini-
tialization is done.
The core function of the agent is in forwarding External API calls to the data application via outCon-
nection, and promoting notifications received by inConnection to Excel with the External API. The
only External API call that has no corresponding LocalConnection invocation is the fxQueryChan-
nel() method. The method is used by FxAgent to construct the names of outbound/inbound Local-
Connections. To keep the agent generic, we avoided hard-coded names. Instead, the agent queries
the hosting Excel document to return the channel ID – the unique name of the bidirectional com-
munication link composed by two LocalConnection objects. To compose names of outbound and
inbound connections we add _Agent2App and _App2Agent suffixes to this ID correspondingly. If a
channel ID starts with an underscore, then “global” connection names are created. In this case the
outConnection object is modified to allow connections from any domain.
This approach is generic and configurable. You can switch which Flex application the Excel work-
book connects to by altering just one workbook property. Further, you can compose other Excel
documents using the workbook created in this example as a template: simply use the Excel com-
mand “New from existing workbook…” instead of “New blank workbook.” Again, the only configu-
ration effort for the “derived” workbook is to modify the channel ID.
After setting up connections, the agent forces the Flex application to resubmit both metadata and
data. This resolves the race condition case when a Flex application has been started before an Excel
document with embedded Flex agent is opened. It’s similar to the xlResend callback in the Spread-
sheet OWC example.
Each and every step is logged into the List control. This helps to understand the order of events
and what’s going on “under the hood.” Figure 15.8 shows a FxExcelAgent running inside an Excel
spreadsheet:
[Bindable]
private var messages:ArrayCollection = new ArrayCollection;
private var inConnection:LocalConnection;
private var outConnection:LocalConnection;
private var outConnectionName:String;
ExternalInterface.addCallback(“xlImportRows”, xlImportRows);
}
}
return channel;
}
message(ERROR, ex.message);
}
if (!isConnected) txtStatus.text = “Disabled: fail to establish local
connection”;
return isConnected;
}
ExternalInterface.call(“fxMetadata”, metadata);
}
messages.itemUpdated(item);
lstMessages.selectedIndex = 0;
}
/* Image resources */
[Embed(source=”assets/icons/wait.png”)]
private static const icoWait:String;
[Embed(source=”assets/icons/ok.png”)]
private static const icoOK:String;
[Embed(source=”assets/icons/info.png”)]
private static const icoInfo:String;
[Embed(source=”assets/icons/warn.png”)]
private static const icoWarn:String;
[Embed(source=”assets/icons/error.png”)]
private static const icoError:String;
[Embed(source=”assets/icons/metadata.png”)]
private static const icoMeta:String;
[Embed(source=”assets/icons/insert.png”)]
private static const icoInsert:String;
[Embed(source=”assets/icons/update.png”)]
private static const icoUpdate:String;
[Embed(source=”assets/icons/reload.png”)]
private static const icoReload:String;
[Embed(source=”assets/icons/remove.png”)]
private static const icoRemove:String;
Remember that FxExcelAgent is designed to run embedded inside Excel. We’ll be looking at what
needs to be done for that once we’re through with the Flex-to-Flex LocalConnection discussion.
[Bindable]
private var employees:ArrayCollection = new ArrayCollection();
[Bindable]
public var bhiOptions:Array = [{label: “No”, data:false}, {label:”Yes”, data:
true}];
if (employees.length)
dataGrid.selectedIndex = 0;
}
else
cells.forEach( function(el:Object,idx:int,array:Array):void {
var pos:int = idx + offset;
var employee:Object = employees.getItemAt(pos);
for (var name:String in el)
employee[name] = el[name];
employees.setItemAt(employee, pos);
});
}
if ( !employees.length ) {
frmName.text = frmPhone.text = “”;
frmBirthday.selectedDate = new Date;
frmYos.value = 1; frmSalary.value = 0;
}
else
dataGrid.selectedItem = employees.getItemAt(Math.min(idx, employees.
length - 1));
fxRowsRemoved(idx, 1);
}
}
]]>
</mx:Script>
<mx:VBox width=”100%” height=”100%”>
<mx:DataGrid id=”dataGrid” width=”100%” height=”100%” dataProvider=”{employees}”
editable=”false” sortableColumns=”false”>
<mx:columns>
<mx:Array>
<mx:DataGridColumn dataField=”name” headerText=”Name”/>
<mx:DataGridColumn labelFunction=”formatDate” headerText=”Birthday”/>
selectedIndex=”{dataGrid.selectedItem.healthInsurance}”
dataProvider=”{bhiOptions}”/>
</mx:FormItem>
<mx:FormItem label=”Salary”>
<mx:NumericStepper id=”frmSalary” value=”{dataGrid.selectedItem.salary}”
maxChars=”10” minimum=”0” maximum=”999999”/>
</mx:FormItem>
<mx:FormItem>
<mx:HBox>
<mx:Button label=”Update” click=”updateRow()”/>
<mx:Button label=”Add” click=”addRow()”/>
<mx:Button label=”Delete” click=”deleteRow()”/>
</mx:HBox>
</mx:FormItem>
</mx:Form>
</mx:VBox>
</mx:Application>
To start over, create a new Excel document. The VBA code uses early binding, so it’s necessary to
add references to the required type libraries. Besides the standard Excel libraries added by default,
you need to add references to Shockwave Flash, Microsoft ActiveX Data Objects (ADO), and Micro-
soft XML 3.0 or higher. As you will soon see, handling the Flex External API in an ActiveX container
is all about XML processing.
Figure 15.9 Adding required typelib references for Excel VBA code
Next, define the workbook’s custom property FxChannel: select menu File/Properties to open the
Properties dialog, switch to tab Custom, and add the property FxChannel of type String. Set it to
_FlexExcelDemo. This property defines the ID of the channel that must be returned in response to
the fxQueryChannel notification sent from the Flex agent. The Flex application from Listing 15.16
hard-codes names for listening and sending connections; these names assume the channel with
ID _FlexExcelDemo. If you deviate from _FlexExcelDemo, then adjust LISTEN_AGENT and UP-
DATE_AGENT in FxExcelSample.mxml. As a convenience, you can get to the workbook properties
by right-clicking menu on the workbook file:
Now we’re ready to add the necessary Excel VBA modules. Two of them are already familiar to you;
we need the ThisWorkbook object module to instantiate the FlexProxy instance in response to the
Workbook_Open event and the FlexProxy class module that inserts the Shockwave Flash object
and handles the External API notifications. The latest one is a new XmlUtils module that exposes
convenient utility functions to work with XML/XSLT.
‘ File ./FxExcelAdodbRecordset.xls
‘ Object module ThisWorkbook
Private fxProxy As FlexProxy
Private Sub Workbook_Open()
Dim Property As Object
Dim fxChannel As String
For Each Property In CustomDocumentProperties
If Property.Name = “FxChannel” Then
fxChannel = Property.Value
End If
Next Property
As you can see, the Workbook_Open event handler checks for the presence of the custom FxChan-
nel document property that we just added. Once the check is successfully passed, it creates a Flex-
Proxy instance and delegates all the work to this object – as in the Excel example.
‘ File ./FxExcelAdodbRecordset.xls
‘ Class module FlexProxy
Option Explicit
With oleObject
Call .BringToFront
Call .Activate
End With
With pFlexObject
.Loop = False
.Menu = True
.Playing = False
.EmbedMovie = False
.AllowNetworking = “all”
.AllowScriptAccess = “always”
If Not found Then
.LoadMovie 0, “../bin/FxExcelAgent.swf”
End If
End With
Call PositionOleControl
End Sub
method = xmlRequest.selectSingleNode(“/invoke/@name”).Text
If pXmlLayout Is Nothing And method <> “fxMetadata” And method <> “fxQueryChannel”
Then
MsgBox “Protocol exception: call to method “”” & method & “”” before metadata
available”, _
vbCritical + vbOKOnly, “Fx Protocol Error”
GoTo ExitSub
End If
Select Case method
Case “fxQueryChannel”:
pFlexObject.SetReturnValue “<string>” + pChannelID + “</string>”
Case “fxMetadata”:
InitMetadata xmlRequest
pFlexObject.SetReturnValue “<null/>”
Case “fxRowsInserted”:
UpdateRows xmlRequest, True
pFlexObject.SetReturnValue “<null/>”
Case “fxRowsUpdated”:
UpdateRows xmlRequest, False
pFlexObject.SetReturnValue “<null/>”
Case “fxRowsRemoved”:
RemoveRows xmlRequest
pFlexObject.SetReturnValue “<null/>”
End Select
ExitSub:
Set xmlRequest = Nothing
Application.EnableEvents = True
End Sub
If isInsert Then
row = row + 1
Dim rows As range
Set rows = pSheet.rows(row)
Dim i As Integer
For i = 1 To count
Call rows.Insert
Next i
Set Target = pSheet.Cells(row, 1)
pTotalRows = pTotalRows + count
Else
If Not xmlRequest.selectSingleNode(“/invoke/arguments/true”) Is Nothing Then
reset = True
pTotalRows = count
Call pSheet.Cells.Clear
End If
Set Target = pSheet.Cells(row, 1)
End If
PopulateRange Target, newContent
Call pSheet.Activate
Dim newSelection As range
If reset Then
Set newSelection = pSheet.UsedRange
Else
Set newSelection = pSheet.range(Target, pSheet.Cells(row + count - 1,
pFieldsCount))
End If
Set Target = Nothing
Call newSelection.CurrentRegion.Columns.AutoFit
Call newSelection.Select
Call PositionOleControl
Call pSheet.Activate
If Not pSheet.UsedRange Is Nothing Then
Dim newSelection As range
Set newSelection = pSheet.range(pSheet.Cells(row, 1), pSheet.Cells(row,
pFieldsCount))
Call newSelection.Select
End If
Call PositionOleControl
End Sub
pOleControl.Top = 10
If allCells Is Nothing Then
pOleControl.Left = 10
Else
pOleControl.Left = allCells.Left + allCells.Width + 10
End If
Target.CopyFromRecordset rsContent
Call rsContent.Close
Set rsContent = Nothing
End Sub
The Module FlexProxy should look familiar to you. It’s an extended version of the module we used
for passing data to Excel via the clipboard (see Listing 15.14).
The Initialize() method is almost the same. The only difference is the name of the swf plus an ad-
ditional channelID parameter that’s saved to the instance variable.
The pFlexObject_FlashCall method got more complex: it handles several events now. Using a help-
er function, which we’ll discuss shortly, it parses an XML request to determine the name of the
invoked method. Then, depending on the method name, processing is dispatched to the appropri-
ate function.
Processing the fxQueryChannel request is trivial: code just returns a value previously saved as a
pChannelID instance variable.
Fortunately, we know better than that. Recall that in the Spreadsheet OWC example we mentioned
more efficient ways to copy tabular data into a range of cells. The first option possible with Excel is
to put content on the Windows Clipboard and then apply it with the Range.PasteSpecial() method.
Although it would be a logical continuation of our example with System.setClipboard(text), it has
serious drawbacks in an automated scenario. Come to think of it, we’re hijacking the system clip-
board: whatever the user puts on the clipboard gets wiped out by our automation code. Is there
anything to replace the clipboard?
Well, instead of populating the Excel range from the clipboard we can use the Microsoft ADODB.
Recordset paired with the Range.CopyFromRecordset(adodbRecordset) method. The wonderful thing
about ADODB.Recordset is its ability to load and save records in XML format. We’ll take this route.
In sum, we have a classic task for XSL transformation: get an XML DOM document as input (the
request parameter of the FlashCall event) and produce an XML DOM document as output (the
content of ADODB.Recordset). The only issue here is that there are two input XML documents:
metadata and the data change notification. To overcome this problem we’ll add a metadata docu-
ment element as a child to the root of the data change request document.
After performing the XSL transformation, we pass the generated content to the PopulateRange()
method. This method creates the ADODB.Recordset with the generated content and then calls
Range.CopyFromRecordset() to populate the range.
The last method of the FlexProxy module – fxRemoveRows() – doesn’t deserve much attention here
since it closely resembles the corresponding method from the Spreadsheet OWC example.
Now it’s time to look at the custom XmlUtils module (Listing 15.19). It exposes three public func-
tions:
• CreateXmlDocument: Creates the instance of the XML DOM document object by the string
source provided
• TransformFlexMetadata: Transforms the content of the metadata notification to the XML
format used by the FlexProxy class
• TransformFlexContent: Turns the content of the data change notification into the ADODB.
Recordset format
‘ File ./ FxExcelAdodbRecordset.xls
‘ Module XmlUtils
Option Explicit
Private xslDataTemplate As MSXML2.xslTemplate
Private xslMetaTemplate As MSXML2.xslTemplate
Note that TransformFlexMetadata() and TransformFlexContent() use XSL templates. The XSL tem-
plate allows the reuse of the Data Transformation Model (DTM) instead of creating and loading it
every time a transformation is performed. Importantly, to use the template the source document
has to be created as a FreeThreadedDOMDocument. The initialization of the XSL templates is done
on-demand in the InitXmlUtils() procedure.
The XSL stylesheets that the templates are based on are stored in the cells on the second worksheet
(we renamed it “Helper,” see Figure 15.11): cell “A1” contains the XSL source for transforming data
content, cell “B1” is used to hold the metadata XSL template. If you’re using different names or
indexes, adjust the InitXmlUtils() procedure correspondingly.
The XSL template for transforming metadata is relatively simple. Here we strip out unnecessary
elements from the original Flex External API XML format and produce the document that has the
root <layout> element with nested <field> definitions.
xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”
exclude-result-prefixes=”xsl”>
<xsl:output method=”xml” encoding=”utf-16” omit-xml-declaration=”no”/>
<xsl:template match=”/invoke/arguments/array”>
<layout><xsl:apply-templates select=”property/object” /></layout>
</xsl:template>
<xsl:template match=”object”>
<field><xsl:apply-templates select=”property”/></field>
</xsl:template>
<xsl:template match=”property”>
<xsl:attribute name=”{@id}”><xsl:apply-templates/></xsl:attribute>
</xsl:template>
As an illustration, consider the xMetadata request coming from the FxExcelSample application:
</property>
</array>
</arguments>
</invoke>
The transformation of this document with the above XSL results in the following XML:
By the way, it’s this very document that is used by the InitMetadata() method of FlexProxy. In partic-
ular, we’ve used selectNodes(“/layout/field”).Length to determine the number of fields (columns).
<xsl:template match=”/invoke”>
<xml>
<xsl:apply-templates select=”layout”/>
<xsl:apply-templates select=”arguments/array”/>
</xml>
</xsl:template>
<xsl:template match=”layout”>
<s:Schema id=”RowsetSchema”>
<s:ElementType name=”row” content=”eltOnly” rs:CommandTimeout=”0” rs:
updatable=”false”
rs:ReshapeName=”FxRowset”>
<xsl:apply-templates select=”field”/>
<s:extends type=”rs:rowbase”/>
</s:ElementType>
</s:Schema>
</xsl:template>
<xsl:template match=”field”>
<s:AttributeType name=”{@name}” rs:number=”{position()}” rs:
writeunknown=”true”
rs:basecatalog=”FxRowsetCatalog”
rs:basetable=”FxRowsetTable” rs:basecolumn=”{@name}”>
<s:datatype dt:type=”{@type}” rs:maxLength=”255” rs:long=”false” rs:
maybenull=”true”/>
</s:AttributeType>
</xsl:template>
<xsl:template match=”array”>
<rs:data><xsl:apply-templates select=”property/object”/></rs:data>
</xsl:template>
<xsl:template match=”object”>
<xsl:variable name=”row”>
<z:row><xsl:apply-templates select=”property”/></z:row>
</xsl:variable>
<xsl:copy-of select=”$row”/>
</xsl:template>
<xsl:template match=”property”>
<xsl:attribute name=”{@id}”><xsl:apply-templates/></xsl:attribute>
</xsl:template>
<xsl:template match=”true”>true</xsl:template>
<xsl:template match=”false”>false</xsl:template>
The ADODB.Recordset format requires recordset schema meta-information. Having rich metadata
available as a <layout> element is a trifling task – we merely transform the <field> elements of the
original document into the <rs:AttributeType> of the rowset schema.
To transform data entries the template first finds the /invoke/arguments/array node and produces
<rs:Data>. From there the template cascades to generate rows for every array element.
Next, for every object property the XSL template creates a corresponding attribute in the <z:row/>
element, applying the necessary type formatting. XSLT is a functional language, and here its nature
simply shines: we just declare rules for processing special types and leave it up to the transforma-
tion to automatically pick up a rule depending on the property type!
You can draw parallels with the examples already seen: strings and numbers go as is, Boolean type
requires extra effort to convert a node name to node text, and any Date-based type is a problem!
Through all the examples we have used several sub-types of date: date-only, time, and timestamp
(or full date). However, in ActionScript all we have is Date, and in the External API it’s encoded as
a <date> element with the number of milliseconds since “epoch.” To format the date values, we
resort to an excellent feature of XSLT 2.0 – the extension functions mechanism. You have to declare
your own namespace (urn:ecma-script:jscript) and implement functions in this namespace in a
vendor-specific way. The Microsoft-specific way is an attractive one: you declare a script block in
JScript and specify that global functions in this block implement an extension function in a certain
namespace. Simple and elegant. Conveniently, we just reuse the formatting functions from the
Spreadsheet OWC example.
You may notice that the transformation doesn’t add a z:row element directly to the result XML tree,
but does create a variable first and then outputs the variable. This trick is necessary to create an
empty XML element, i.e., <z:row/> instead of an element with no content <z:row></z:row>. Other-
wise ADODB.Recordset fails to read anything except the very first row7.
We’re done preparing. Let’s party! To run the example you have to have the FxExcelSample ap-
plication running and the FxExcelAdodbRecordset.xls workbook open – in any order. Figure 15.12
shows the Flex application partially overlapping the workbook. You can modify the Flex data and
the Excel workbook will be updated instantly. As you can tell, we purposely let the FxExcelAgent
hang in the visible portion of the workbook for purposes of illustration.
We sincerely hope that Adobe will have this bug fixed by the time you read these lines. In List-
ing 15.22 you can find the code necessary for the Worksheet_Change event handler that traverses
modified cells and constructs the request XML in the External API format. In fact, the code in List-
ing 15.22 closely resembles the corresponding event handler in the Spreadsheet OWC example; the
only difference is that XML elements are created instead of JavaScript objects. The code should be
added to the FlexProxy class module.
‘Offset parameter
Dim paramOffset As MSXML2.IXMLDOMElement
Set paramOffset = xmlRequest.selectSingleNode(“/invoke/arguments/number”)
paramOffset.appendChild xmlRequest.createTextNode(Target.row - 1)
asProp.appendChild value
asObj.appendChild asProp
Next col
asIdx.appendChild asObj
asArray.appendChild asIdx
Next row
‘MsgBox xmlRequest.XML
pFlexObject.CallFunction xmlRequest.XML
ExitSub:
Application.EnableEvents = True
End Sub
What if the bug still persists and you need bidirectional communications? Well, one option is to
replace the asynchronous call to CallFunction with polling. Briefly, it could be implemented as
described below:
• The Worksheet_Change event handler should be modified to create an object that describes
the modification in the External API format (refer to Table 15.2 for details). Instead of <in-
vocation> you must create <object> as a root element and then add both asArray and offset
as <property> sub-nodes; assign the result to a new FlexProxy instance field, for example,
pLastChange of type MSXML2.DOMDocument. Obviously, the CallFunction invocation must
be removed from the code.
• The pFlexObject_FlashCall method (see Listing 15.18) should be modified to handle addition-
al notification, say, fxQueryChanges. In response to this notification, XML content previously
saved to the pLastChange field must be returned with the ShockwaveFlash.SetReturnValue;
field cleared afterwards.
Another issue you might find annoying is that when closing the spreadsheet, the user is prompted
to save the workbook even when a single cell hasn’t been altered. The cause is the automation code
that updates cells immediately after opening the workbook (if the Flex data source application is
running). Actually, there’s no single recipe here: every possible option should be validated against
the particular use case. For some applications you can invoke the Workbook.Save method to persist
changes automatically; for others it’s possible to set the Workbook.Saved property to True and skip
confirmations along with saving; for the rest the only valid option is to leave the behavior as is.
Summary
This chapter took you through the jungles of Flash technologies such as the External API and Local-
Connection as well as through the maze of Microsoft old-timers like ADODB and OWC. We’ve been
Frankly, it’s only the length of this chapter that prevents us from diving into C++ DLLs or showing
you integrating with Excel Pivot tables.
Tough? Well, you didn’t think system integrators earn their money for nothing, did you? But let’s
look at the end result. We presented you with a set of generic, parameterized, reusable solutions:
• Two-way integration of Flex and the Office Windows Component (OWC) Spreadsheet embed-
ded in the same HTML page. As a reminder, we only left out Pivot Table integration because of
space limitations.
• The interactive export of Flex content to an Excel application via the clipboard.
• A live-link between a standalone Flex application and an Excel worksheet (the latter has to be
templated by our sample one).
If you find that we’ve paid too much attention to our code, our response is – guilty as charged. But
we’ve transferred every line of our solution to you, so that you can take them to users with no black
holes.
Endnotes
1. Experiments show that this is not the only option with the current ExternalInterface implementation.
You can invoke a method of the JavaScript object from ActionScript in the form of ExternalInterface.
call(“jsObjectA.jsObjectB.methodOfB”, arg1, arg2, …, argN). Apparently ExternalInterface invokes JavaS-
cript code via the eval function rather than via Function.apply. However, this is an undocumented feature
and its behavior may be changed in future releases.
2. It’s technically possible to have several versions of Microsoft Office Web Components side by side. A typi-
cal cause of this is upgrading Microsoft Office.
3. Spreadsheet OWC would be simply genius if it had explicit support for the JavaScript Date type. The cur-
rent version converts Date to a UTC string before the assignment and applies string formating to the cell
afterwards.
4. As noted, the Spreadsheet OWC 9 API is very limited. Most important, there are no events to track content
changes. So the rest of the code is applicable to Spreadsheet OWC 10/11 only.
5. “JavaScript” is used internally by CallFunction for the HTML container return type. This forces the result
to be a JSON-formated string that’s applicable to the eval call.
6. Frequently, Microsoft is a standard on its own. W3C defines the importNode method on the Document
interface that must be called to get a copy of the XML node from the other document before adding it.
7. W3C’s XML Specification Edition 3 clarifies this issue: if an element is declared in DTD as EMPTY, then
the <tag/> form SHOULD be used (see http://www.w3.org/TR/REC-xml/#dt-empty). So the behavior of
the ADODB.Recordset XML parser is partly correct. To be absolutely correct it’s necessary to report that
the XML document doesn’t pass DTD/Schema validation rather than return partly parsed content.
INDEX
418-424, 426-428, 430, 431, 433, 436-439, 442, 444, BeforeContextMenu 641
447, 448, 450, 452, 453, 456, 457, 459, 462, 464-467, Boolean 38, 39, 67, 101, 104, 130, 136, 138, 145, 231,
473, 475, 477, 485, 486, 489- 491, 497, 498, 257, 267, 269, 271, 279, 282, 296, 305, 306, 315,
500-505, 508, 516, 521, 522, 526, 527, 528, 530, 532, 316, 319, 336, 338, 342, 349, 350, 357, 360, 369,
534, 535, 537, 539, 540, 541, 544-548, 550, 559-563, 394, 396, 443, 457, 488, 493, 511, 514, 529, 548,
565, 566, 567, 569, 570, 574, 578, 579, 580, 585, 556, 596, 605, 609, 610, 611, 612, 615, 617, 618,
591, 595, 601, 604-607, 609-615, 620, 621, 626, 620, 633, 646, 649, 652, 657, 663, 664, 665, 666,
628-630, 633, 635, 636, 642, 643, 648, 649, 650, 654, 669, 671, 672, 677, 679, 689
655, 658, 659, 660, 661, 662, 663, 664, 668, 674, bubbling 139, 140, 141, 144, 145, 150, 151
675, 685, 689, 690, 693, 694 build.xml 25, 26, 243, 245, 246, 247, 248, 413,
applicationDomain 401, 403, 404, 424, 425 414, 417, 418, 419, 423, 500, 501, 541
application domain 362, 401, 413, 421 ButtonBar 29, 33, 63, 172, 516
application domains 45, 362, 401, 431 ByRef 640, 641
application project 402, 416, 448 bytecode 4, 5, 6, 20, 34, 37
argument 41, 69, 91, 112, 144, 171, 207, 217, 332,
334, 346, 372, 379, 499, 500, 508, 510, 577, 605, C
606, 609, 612, 633, 655 callback 36, 318, 370, 445, 577, 578, 587, 606, 607,
ArgumentError 531, 659, 661, 664, 669 612, 662
ArrayCollection 134, 138, 209, 210, 253, 255, 257, CallFrame 604
259, 262, 277, 280, 281, 283, 284, 315, 321, 322, CallLabel 604
324, 330, 331, 338, 339, 372, 491, 504, 505, 548, Canvas 29, 33, 63, 128, 134, 135, 171, 172, 173, 175,
549, 556, 615, 616, 617, 643, 646, 663, 668, 669, 671 176, 178, 187, 188, 200, 202, 272, 273, 276, 277,
asdoc 21 545, 546, 548, 549, 552, 554, 555, 556, 559
Asynchronous Completion Token (ACT) 377 capture 139, 140, 144, 145
as casting 329, 362 Cell 633
attachEvent 638 ChangeObject 212, 217, 218, 219, 220, 233, 234, 235,
autoCommit 208, 209, 210 236, 237, 240, 241, 266, 267, 268, 269, 270, 271,
autocomplete 312, 339, 340, 341, 342, 343, 346, 272, 274, 278, 280, 281, 282
347, 349 change event 133, 186, 187, 340, 341, 343, 470, 556,
automation xxi, 439, 498, 503, 515, 614, 649, 682, 693 564, 565
automation interface 614 Charting xii, 5, 167, 574, 575
autoSyncEnabled 208, 209, 210 ChartItemEvent 188
Auto extract 404, 407, 408, 420, 428, 429 CheckBox xv, 29, 33, 65, 128, 131, 134, 388, 389, 390,
AVM 37, 110, 138 391, 393, 395, 457, 458, 459, 460, 461, 462, 463,
464, 465, 466, 467, 468, 500, 505, 506, 515, 516
B Checkboxed Tree 386
backgroundAlpha 479 CheckBoxes 442, 463
backgroundColor 24, 128, 130, 134, 148, 151, 209, child domain 401, 430
428, 433, 436, 479, 480, 486, 545, 556, 560, 580 ClassFactory 459, 481, 482, 483, 484, 494, 495, 496,
BatchGateway 289, 291, 292, 293, 294, 300 497, 499, 508, 509, 510, 511, 512, 513, 516
BatchMember xiv, 288, 290, 292, 293, 295, 296 classpath 30, 162, 189, 197, 244, 246
batchRegisteredCollections() 294, 295, 304, 306 class definitions 105, 362, 401, 403, 463, 502
BatchService xiv, 293, 294, 295, 297, 304, 305, clipboard 634, 637, 643, 648, 649, 656, 681, 682, 694
306, 308 closure 41, 86, 87, 88, 89, 90, 91, 451, 606, 609, 612
CollectionEvent 259, 260, 262, 269, 270, 308, 464, CSS 12, 44, 70, 324, 413
470, 472 CSSStyleDeclaration 359, 360, 447
com.theriabook.collections.DataCollection 254, 295, CurrencyFormatter 127, 128, 135, 451, 452, 453, 455
302, 304, 305 currentDomain 401, 402, 403, 410, 420, 424, 425
com.theriabook.controls.CheckBox 458, 459, 460, Custom events 147
461, 462, 466, 467, 500, 505
com.theriabook.controls.dataGridClasses. 500 D
com.theriabook.controls.dataGridClasses. DAOException 216, 217, 220, 223, 225, 226, 228, 234,
DataGridColumn 448, 496, 500, 501, 512, 513, 514 235, 240, 241, 286, 326, 327, 344
com.theriabook.controls.Label 481, 500, 505, 513 DAOFlex xiii, 207, 211, 212, 215, 216, 221, 222, 223,
com.theriabook.DAOFlex.DAOException 216, 223 224, 229, 230, 232, 233, 242, 243, 244, 245, 246,
com.theriabook.datasource 210, 211, 213, 214, 221, 247, 248, 249, 265, 299, 308
223, 224, 226, 227, 232, 253, 260, 261, 263, 264, DAOFlex-runtime.properties 244
265, 277, 284, 299, 300, 305 DAOFlex code generator: 247
com.theriabook.remoting.BatchGateway 292, 300 Data-Driven Programming xvi, 498
com.theriabook.remoting.BatchMember 292, 293, DataCollection 254, 285, 287, 288, 294, 295, 296, 302,
295 304, 305, 306, 366, 381, 382
ComboBoxes 332, 442 dataDescriptor xiv, 369, 371, 373, 380, 384
CommandBeforeExecute 641 dataField xiv, 116, 119, 124, 128, 135, 159, 166, 169,
commitProperties() 315, 316, 317, 320, 337, 350, 173, 176, 182, 183, 184, 200, 210, 254, 259, 273,
458, 465 275, 276, 277, 301, 303, 313, 314, 318, 319, 320,
commitRequired 279, 280, 282, 284, 297, 305, 306 321, 324, 331, 332, 335, 336, 337, 348, 349, 353,
compc 47, 402, 405, 448 354, 356, 357, 360, 423, 444, 445, 446, 447, 450,
compilation errors 24 452, 453, 456, 458 -467, 470, 472, 476, 477, 478,
compiler options 24, 490 479, 480, 485, 487, 489, 492, 493, 498, 501, 507,
component manifest file 447, 487 531, 532, 619, 647, 673
concurrency 161, 166, 169, 173, 175, 180, 182, 185, DataGrid xii, xv, xvi, 33, 94, 116, 117, 119, 120, 122,
256, 258, 296, 329, 331, 334, 338, 348, 352, 377, 124, 125, 127, 128, 130, 133, 135, 159, 166, 168,
381, 382, 383, 443, 514 169, 171, 172, 173, 176, 181, 182, 184, 187, 188,
consumer 3, 192, 199, 201, 202 200, 206, 207, 209, 210, 254, 259, 273, 275, 276,
ControlBar 33, 209, 210, 260, 272, 276, 284, 297, 301, 277, 300, 301, 302, 303, 322, 385, 401, 422, 423,
302, 303, 560, 561, 564, 565, 569 426, 427, 441, 442, 443, 444, 445, 447, 448, 449,
createChildren() 46, 345, 351, 388, 390, 393, 395, 584, 450, 451, 452, 453, 455, 456, 457, 458, 459, 460,
586, 591, 600 461, 463, 464, 465, 466, 467, 469, 470, 471, 472,
createItem() 212 473, 475, 476, 477, 478, 479, 481, 483, 485, 486,
createUpdateEvent() 262, 264 487, 489, 491, 492, 493, 494, 495, 497, 498, 499,
creationComplete 46, 87, 88, 89, 114, 138, 141, 143, 500, 501, 502, 503, 504, 505, 507, 508, 509, 511,
148, 149, 151, 165, 166, 169, 172, 176, 182, 184, 512, 513, 515, 516, 517, 530, 531, 532, 614, 619,
200, 209, 254, 259, 275, 284, 301, 303, 313, 330, 647, 673
332, 335, 336, 370, 379, 382, 404, 435, 443, 445, DataGridColumn xv, 116, 119, 124, 128, 135, 136,
450, 452, 456, 460, 465, 467, 475, 478, 485, 491, 159, 166, 169, 173, 176, 182, 183, 184, 200, 210,
497, 501, 505, 524, 526, 527, 607, 608, 615, 643, 254, 259, 273, 275, 276, 277, 301, 303, 423, 442,
663, 668 444, 445, 446, 447, 448, 449, 450, 451, 452, 453,
crossdomain.xml 117, 181 454, 455, 456, 457, 458, 459, 460, 461, 462, 466,
467, 468, 476, 477, 478, 479, 480, 481, 483, 484, destination 92, 94, 95, 97, 122, 160, 161, 162, 164,
485, 486, 492, 494, 495, 496, 498, 499, 500, 501, 165, 166, 169, 170, 173, 174, 175, 177, 180, 181,
502, 503, 505, 507, 509, 510, 511, 512, 513, 514, 182, 185, 189, 191, 192, 193, 194, 195, 199, 201,
515, 531, 532, 619, 647, 673 206, 207, 208, 209, 211, 212, 213, 214, 245, 246,
DataGridListData 458, 463, 464, 465, 470, 471, 472, 248, 252, 253, 254, 255, 256, 257, 258, 259, 260,
487, 489, 493 266, 277, 281, 283, 284, 287, 288, 291, 292, 293,
dataProvider 116, 119, 122, 124, 125, 127, 128, 130, 294, 295, 296, 299, 300, 306, 312, 325, 326, 329,
133, 134, 135, 159, 166, 168, 169, 171, 172, 173, 331, 332, 333, 334, 335, 336, 338, 339, 343, 346,
176, 178, 181, 182, 184, 185, 188, 200, 201, 209, 348, 349, 350, 351, 352, 353, 354, 356, 357, 360,
210, 254, 255, 259, 273, 274, 275, 278, 300, 301, 362, 366, 378, 381, 382, 383, 387, 413, 442, 443,
302, 303, 312, 313, 314, 315, 316, 317, 318, 319, 444, 445, 450, 452, 456, 460, 465, 467, 475, 478,
320, 321, 323, 324, 331, 335, 337, 338, 340, 341, 485, 497, 514, 515, 525, 526, 527, 529
342, 343, 346, 347, 349, 350, 351, 352, 366, 367, destination-aware collection 254, 259
368, 369, 371, 372, 373, 379, 380, 383, 384, 394, Destination-Aware Collections xiii, 253
422, 426, 427, 444, 462, 464, 465, 470, 472, 477, destination-aware ComboBox 336, 339, 349, 352,
485, 492, 499, 502, 504, 507, 515, 516, 531, 532, 366, 382
553, 554, 559, 562, 564, 565, 568, 569, 579, 581, DHTML 4, 8, 10, 12, 58
585, 589, 590, 591, 592, 593, 594, 598, 600, 619, Dispatch interface 614
620, 647, 648, 668, 673, 674 DisplayList 578
DataService 208, 209, 236, 252, 253, 254, 266, 308, DisplayObject 45, 138, 409, 435, 468, 469, 471, 513,
370, 521 514, 554
Data Access Object (DAO) 207, 376, 378 doCreate() xiii, 238, 240, 241
data adapters 206 doDelete() 235, 238
Data Binding xi, xv, 92, 99, 122, 393 doInsert() 235
data collaboration 206 DOM Level 0 638
data synchronization xxiv, 252, 613 DOM Level 2 638
Date x, 34, 38, 39, 67, 182, 184, 210, 211, 212, 213, doUpdate() 235, 236, 237
214, 215, 216, 221, 222, 224, 226, 229, 231, 233, Drop-In Renderer xv, 457, 467
238, 254, 255, 260, 277, 284, 301, 307, 506, 529, dropdownWidth 324, 331, 332, 335, 336, 348, 353,
531, 532, 580, 581, 585, 586, 592, 593, 594, 597, 356, 357, 360
598, 599, 605, 608, 609, 610, 611, 617, 618, 631, DTD 196, 695
632, 633, 644, 645, 646, 657, 671, 672, 688, 689, 695 durable subscriber 192
debugger xxiii, 5, 8, 21, 66, 67, 68, 427, 520, 534, 536, Dynamic classes 41
540 dynamic linking 404, 409
debugging xxiv, 5, 8, 21, 66, 67, 68, 242, 438, 516, 520,
522, 523, 530, 532, 534, 539, 541 E
decimalSeparator 489, 490 E4X xi, 37, 117, 122, 124, 126, 132, 138, 164, 181, 367,
DefaultDataDescriptor 368, 369 503, 563, 570
DELETE 212, 219, 232, 237, 266, 267, 280, 282 E4X XML 367
deletedCount 267, 268, 269, 270, 271, 272, 276, 279, ECMAScript xxii, 4, 33, 37, 41, 80, 87, 126, 632
280, 282, 284, 302, 303 EditingManager 494, 495, 496, 497, 500, 512
deleteItem() 212 editorDataField 301, 467, 492, 495, 497
deployment 2, 5, 6, 11, 14, 25, 245, 246, 400, 407, 408, EMBED 58, 607, 611, 628
413, 416, 418 event.hitData.item 187, 188, 200
EventDispatcher 45, 85, 138, 139, 263, 264, 295, 305 62, 66, 92, 115, 138, 139, 140, 144, 149, 183, 253,
event listener 34, 90, 138, 139, 149, 334, 373, 382, 481 328, 362, 401, 516, 520, 575, 604, 605, 606, 607,
Excel xvii, 604, 613, 620, 625, 627, 630, 632, 633, 636, 611, 613, 620, 629, 650, 654, 655, 674
639, 642, 643, 649, 650, 651, 652, 653, 654, 656, flex.data.assemblers.AbstractAssembler 212
658, 662, 663, 668, 674, 675, 676, 677, 679, 681, flex.data.ChangeObject 212, 217, 266
682, 689, 690, 694 Flex2Ant 439
executeBatch( 291 flexibility xxiii, 62, 83, 89, 308, 313, 321, 367, 400, 416,
executeTransactionBatch() 291, 292 575, 613
expando 504, 506, 638 Flex Data Services xiii, xxiv, 4, 5, 6, 21, 30, 47, 69, 115,
explodeRadius 168, 169, 173, 176, 200 156, 161, 189, 206, 252, 266, 288, 307, 308, 521,
extendedProperties 459, 460, 461, 462, 466, 484, 534, 541
494, 511 Flex Library project 448
External xvii, 403, 404, 603, 604, 605, 606, 607, 608, Flex Remoting xiii, 206, 252, 253, 266, 285, 287,
609, 611, 612, 613, 615, 617, 619, 621, 623, 625, 307, 525
627, 629, 631, 633, 635, 637, 639, 641, 643, 645, FOR/EVENT 638
647, 649, 651, 653, 654, 655, 657, 658, 659, 661, formatData 453, 454, 455, 456, 457, 459, 485, 495,
662, 663, 665, 667, 668, 669, 671, 673, 674, 675, 496, 511
676, 677, 679, 681, 683, 684, 685, 686, 687, 689, formatString 445, 447, 449, 450, 451, 452, 453, 454,
690, 691, 693, 695 455, 456, 457, 459, 480, 485, 492, 495, 496, 497,
ExternalInterface 47, 430, 605, 606, 607, 608, 611, 498, 501, 511, 590, 597, 599
612, 613, 614, 615, 617, 620, 644, 655, 658, 663, formatters 445, 446, 449, 451, 455, 496, 500
664, 665, 666, 693, 695 formatting 128, 129, 135, 136, 442, 444, 445, 446,
ExternalInterface.call() 655 450, 451, 486, 494, 495, 524, 632, 633, 655, 657, 689
FormattingManager xv, 447, 449, 450, 451, 452, 454,
F 456, 459, 485, 494, 495, 496, 500, 511, 515
Façade xiv, 378, 379 framework.swf 416, 427, 438
FaultEvent 84, 164, 166, 170, 174, 177, 182, 185, 188, frame rate 27, 28, 29, 138
199, 255, 256, 257, 258, 280, 281, 283, 289, 294, FreeThreadedDOMDocument 678, 679, 680, 683, 684
295, 296, 304, 305, 306, 331, 334, 335, 338, 351, FSCommand 604, 605
352, 380, 384, 385, 443, 444, 514, 525 fx:DataGridColumn 447, 448, 450, 453, 454, 456, 458,
FDS xiii, 4, 5, 115, 122, 156, 161, 181, 193, 206, 207, 459, 460, 462, 466, 467, 468, 476, 480, 481, 485,
217, 266, 287, 307, 308, 520 486, 492, 498, 507
fill() 209, 212, 253, 254, 255, 256, 281, 304, 306, 332,
333, 334, 335, 336, 346, 348, 382, 386, 443, 445, G
450, 452, 456, 460, 465, 467, 475, 478, 485, 497 generated 23, 24, 27, 52, 54, 57, 59, 69, 70, 93, 95, 97,
fill-method 213, 215, 221, 224, 226, 228, 232 98, 99, 137, 139, 160, 209, 213, 221, 228, 232, 235,
Filtering xii, 130 245, 246, 248, 249, 299, 355, 402, 410, 411, 412,
flash.display.Loader 401, 424, 425, 548, 556 418, 515, 580, 611, 648, 649, 682
flash.events.EventDispatcher 263, 295, 305 generator class 481
flash.net.navigateToURL 183 GET 178, 182
flashObject.CallFunction 655 getChangedPropertyNames() 218, 236
flashObject.SetReturnValue 655 getChangedValues() 218, 219, 237
Flash Player xxiii, 2, 4, 5, 6, 7, 10, 12, 13, 14, 20, 21, 22, getChildren() 370, 378, 379, 382, 383, 385
23, 24, 27, 31, 32, 33, 34, 37, 42, 45, 46, 47, 56, 57, getDefinitionByName() 486, 516
getItem() 212 integration xix, 4, 6, 13, 14, 58, 193, 428, 562, 604,
getOperation() 334 613, 620, 622, 628, 643, 649, 668, 694
getters 85, 97, 138, 577 interface xxii, xxiv, 11, 12, 106, 107, 108, 109, 110,
global scope 38, 625 111, 112, 138, 139, 262, 263, 264, 266, 367, 368,
Google Finance 574, 575, 601 369, 394, 434, 435, 436, 437, 468, 469, 481, 495,
graphics.beginFill() 479 523, 545, 554, 564, 565, 614, 634, 662, 663, 695
Interfaces xi, 42, 106, 108, 110
H Internet Explorer 7, 28, 29, 612, 614, 622, 624, 625,
HBox 33, 63, 101, 102, 103, 104, 128, 134, 152, 175, 638
177, 178, 200, 201, 210, 323, 324, 325, 331, 336, invalidateDisplayList() 389, 484, 511, 585, 591, 592,
348, 349, 353, 355, 356, 358, 361, 461, 477, 478, 597, 598, 600
516, 554, 564, 565, 568, 569, 594, 620, 648, 674 invalidateProperties() 315, 316, 317, 320, 337, 350,
hierarchical data provider 367 458, 464, 591, 600
HTML xvii, 3, 5, 6, 9, 12, 13, 23, 24, 25, 27, 44, 47, 57, invalidateSize() 392, 587, 591, 600
58, 73, 98, 99, 115, 116, 118, 121, 122, 321, 539, IPropertyChangeNotifier 262
559, 604, 605, 607, 609, 611, 613, 614, 620, 621, isBranch 367, 369
622, 624, 626, 628, 629, 634, 637, 638, 639, 640, isItemModified() 268
642, 643, 648, 649, 655, 682, 694, 695 isItemNew() 268
HTTPService 92, 116, 117, 119, 120, 121, 122, 156, itemClick 187, 188, 200
178, 180, 181, 182, 185, 202, 545, 547, 552, 559, itemEditor 301, 474, 492, 495, 496, 497, 503
561, 562, 565, 568 itemRenderer 183, 184, 273, 275, 276, 323, 324, 325,
331, 336, 348, 349, 353, 354, 355, 356, 357, 358,
I 360, 361, 387, 458, 459, 460, 461, 462, 466, 467,
IDataRenderer 387, 392, 468, 469, 471 468, 474, 476, 477, 478, 479, 480, 481, 484, 494,
IDispatch 634 495, 499, 501, 502, 503, 507, 508, 511, 512, 513,
IDropInListItemRenderer 387, 392, 394, 468, 469, 471 553, 554, 555, 559, 562, 564, 565, 568, 569
IEventDispatcher 139, 262, 263, 264, 425 itemToLabel() 347
IFactory 357, 359, 360, 481, 482, 483, 484, 494, 495, itemUpdated() 262, 465
509, 511, 512, 553 item editor 467, 470
ILogger 523, 524, 525, 526, 527, 529 item renderer 321, 322, 323, 385, 386, 387, 396, 458,
IManaged 262, 263, 264, 265 467, 468, 470, 480, 481, 484, 494, 554
INITIAL_CONTEXT_FACTORY, 189 ITreeDataDescriptor 367, 368, 369, 370
InitialContext 189, 198, 286, 289, 290 IUID 262, 263, 264, 265
inline component 323, 358
inline statements 35 J
INSERT 212, 220, 232, 240, 241, 628, 665, 667 JAR 245, 403
instance 6, 23, 34, 41, 44, 45, 68, 81, 82, 83, 86, 87, 88, java.util.List 213, 221, 266, 299
89, 91, 92, 95, 106, 110, 119, 122, 124, 125, 146, 152, JavaBean 169, 577
172, 189, 209, 242, 252, 255, 257, 263, 268, 288, JavaScript xxi, xxii, 7, 8, 9, 10, 11, 12, 13, 36, 37, 47,
289, 290, 294, 325, 333, 334, 339, 353, 358, 359, 57, 58, 80, 82, 87, 98, 116, 121, 123, 125, 604, 605,
369, 373, 387, 394, 404, 424, 430, 435, 445, 459, 606, 607, 608, 609, 611, 612, 613, 614, 620, 621,
481, 482, 490, 495, 499, 534, 554, 555, 606, 607, 622, 623, 624, 626, 627, 628, 629, 630, 632, 633,
609, 632, 654, 659, 676, 681, 682, 693 636, 637, 638, 641, 655, 690, 694, 695
instance method 606, 609 Java Transaction API (JTA 287
jdbc/theriabook 216, 217, 221, 224, 225, 227, 232, library project 416, 439
235, 246, 249, 299, 326, 327, 344, 376 linkage variable 209, 355, 420, 502
JDBCConnection 216, 217, 223, 225, 226, 227, 228, LinkBar 33, 172, 516
233, 234, 235, 289, 326, 327, 344, 376 LinkButton 183, 184, 385, 549, 550, 559, 567, 568
JDBC data source 326 Link Type 403, 406, 408, 420, 429, 438, 501
JDBC driver 242, 244 listData 394, 395, 396, 458, 463, 464, 465, 468, 469,
JDT 50 470, 472, 473, 476, 482, 483, 487, 489, 493, 510
JIT 4, 14, 81 Loader 33, 401, 424, 425, 548, 549, 550, 551, 556,
JMS xii, xxiv, 6, 13, 156, 158, 189, 190, 191, 193, 194, 557, 558
195, 196, 197, 198, 200, 202, 521 LocalConnection xvi, xvii, 430, 524, 528, 529, 530,
JMS adapters 202 531, 604, 605, 650, 658, 659, 660, 661, 662, 663,
JNDI 189, 190, 194, 197, 198, 229, 244, 291 664, 665, 668, 669, 693
jndi.properties 189, 197 log 46, 66, 71, 225, 226, 520, 521, 522, 523, 524, 525,
JRun 181, 243, 244, 534, 535, 536 528, 530, 531, 532
JScript 622, 625, 630, 632, 633, 634, 641, 643, 688, 689 logger 234, 286, 287, 289, 290, 291, 522, 523, 524, 526,
JSP xi, 73, 115, 116, 117, 118, 134, 539 527, 528, 532
JVM 3, 6, 7, 65, 534, 535 logging 216, 520, 521, 522, 523, 524, 525, 526, 527,
jvm.config 22, 534, 535 528, 529, 530, 532, 533, 534, 541
L M
label 5, 28, 31, 32, 34, 35, 54, 59, 60, 61, 65, 67, 87, 88, Managed xiii, 211, 252, 262, 264, 265
90, 93, 94, 98, 108, 118, 119, 120, 128, 131, 134, MaskedInput 486, 487, 494, 495, 496, 500, 505, 506
138, 140, 141, 143, 147, 151, 152, 170, 171, 172, measure() 392, 395, 587
173, 176, 183, 184, 200, 210, 260, 272, 273, 275, Merge-in 403, 404
276, 277, 284, 297, 301, 302, 303, 312, 313, 314, message xxiv, 21, 36, 71, 87, 91, 119, 121, 126, 127,
315, 316, 318, 319, 320, 337, 347, 349, 351, 366, 128, 130, 131, 132, 133, 134, 136, 137, 161, 190,
367, 368, 369, 370, 371, 373, 379, 380, 383, 384, 191, 192, 193, 194, 195, 196, 199, 201, 258, 281,
388, 390, 391, 392, 395, 409, 427, 428, 429, 430, 283, 331, 335, 338, 352, 409, 444, 515, 524, 525,
431, 433, 434, 435, 436, 437, 446, 449, 461, 462, 526, 527, 528, 529, 531, 532, 606, 610, 622, 644,
463, 465, 467, 469, 473, 474, 476, 477, 485, 494, 653, 656, 663, 664, 665, 666, 667, 669
501, 502, 506, 523, 524, 526, 527, 548, 549, 557, Message-Oriented-Middleware (MOM) 190
559, 560, 564, 565, 567, 568, 569, 594, 595, 608, Message Broker 196
615, 618, 619, 620, 643, 647, 648, 666, 667, 668, messaging-config.xml 193
672, 673, 674 Microsoft Windows 614, 622
labelField 313, 318, 319, 320, 321, 324, 331, 332, MiniDebugTarget 523
336, 337, 347, 348, 349, 353, 354, 356, 366, 367, 368 modifiedCount 267, 268, 269, 270, 271, 272, 276, 279,
labelFunction xv, 123, 124, 128, 135, 138, 168, 169, 280, 281, 282, 283, 284, 302, 303
171, 173, 176, 200, 318, 335, 347, 357, 360, 444, module 433, 434, 438, 651, 654, 676, 681, 682,
445, 446, 447, 449, 452, 456, 494, 619, 647, 673 683, 690
Layouts xi, 33, 61 MP3 547, 569
library xxii, 5, 8, 11, 12, 21, 30, 36, 37, 159, 312, 401, multi-column dropdown list 312
403, 404, 405, 406, 410, 412, 413, 416, 418, 420, mx.controls.Button 141, 143, 392
423, 428, 429, 430, 434, 438, 439, 442, 450, 500, mx.controls.dataGridClasses.DataGridColumn 447,
501, 502, 650 449, 451, 452, 454, 455, 456, 459, 468, 483, 484,
494, 505, 509, 510, 511 483, 484, 485, 486, 487, 489, 493, 494, 495, 496,
mx.controls.listClasses.ListBase: 512 499, 500, 501, 504, 506, 508, 509, 510, 511, 512,
mx.controls.SWFLoader 401 513, 514, 553, 576, 577, 579, 591, 600, 605, 608,
mx.controls.treeClasses.TreeItemRenderer 387 616, 618, 644, 645, 646, 647, 650, 651, 652, 656,
mx.core.ClassFactory 459, 483, 484, 494, 496, 509, 657, 658, 666, 669, 670, 672, 676, 677
511, 513 Object-oriented 105, 577
mx.formatters.SwitchSymbolFormatter 445, 446, Observable 138
449, 451 Observer 138
mx.modules.ModuleLoader 401 Office Web Components (OWC) 613, 624, 625
mx.preloaders.Preloader 402 OLEObjects 652, 654, 677
mx.rpc.AbstractOperation 257, 334, 338, 443, 513 on-demand loading 357, 421
mx.vaidators.RegExpValidator 490 onEnterFrame 553, 554, 555, 605
mxmlc 21, 22, 23, 24, 25, 26, 27, 28, 31, 47, 402, 410, onload 627, 629, 630
413, 418, 429 overshadowing 401
MXML syntax 442
P
N performance 3, 4, 14, 15, 21, 28, 29, 37, 46, 65, 66, 81,
Namespaces x, xi, 29, 112 111, 160, 163, 253, 316, 328, 335, 461, 508, 516,
NaN 95, 488, 489, 490, 491, 493 522, 574, 613, 634
NavBar 172 PieChart 168, 169, 172, 173, 176, 187, 188, 200, 574
newInstance() 40, 481, 482, 483, 499, 508, 509, 510, PivotTable 643
516, 553 POJO 13, 115, 156, 158, 160, 161, 162, 189, 253, 385
Number 38, 39, 42, 83, 84, 85, 86, 89, 94, 96, 97, 105, Polymorphism xi, 106, 110
107, 113, 114, 128, 135, 136, 137, 163, 168, 170, portlet 400, 409, 421
174, 177, 201, 211, 263, 265, 328, 390, 391, 395, POST 116, 119, 178, 527
461, 463, 465, 476, 479, 488, 489, 490, 491, 492, PreparedStatement 216, 218, 219, 220, 224, 225, 227,
493, 549, 553, 557, 576, 578, 583, 584, 586, 587, 236, 237, 240, 241, 326, 327, 344, 376
588, 590, 593, 599, 609, 610, 611, 612, 618, 646, prepareStatement() 240
657, 666, 672 preventDefault() 488, 494, 516
NumericInput 486, 487, 488, 489, 490, 492, 493, 494, preventRendererReuse 507, 511, 512, 514
496, 497, 500, 505, 506 productivity 2, 3, 361, 400, 408, 409, 416
ProgID 624, 654
O properties 27, 41, 44, 58, 60, 64, 80, 82, 85, 86, 95, 96,
Object xi, xiii, xiv, xv, 15, 39, 40, 82, 89, 98, 104, 105, 97, 99, 105, 106, 112, 115, 122, 139, 149, 161, 163,
111, 124, 128, 130, 136, 139, 168, 170, 174, 177, 172, 181, 182, 189, 191, 194, 195, 197, 208, 213,
201, 206, 207, 215, 217, 231, 261, 263, 264, 266, 229, 244, 245, 246, 249, 253, 262, 264, 267, 268,
268, 270, 271, 272, 274, 278, 280, 282, 289, 290, 292, 300, 313, 314, 315, 316, 318, 319, 321, 326,
297, 307, 314, 315, 316, 317, 318, 319, 320, 321, 333, 353, 358, 377, 378, 428, 429, 434, 435, 437,
322, 324, 332, 336, 337, 348, 349, 350, 361, 368, 447, 448, 453, 454, 459, 460, 468, 471, 481, 482,
369, 370, 371, 373, 375, 376, 377, 378, 379, 380, 483, 484, 489, 490, 494, 495, 496, 497, 499, 502,
381, 382, 383, 384, 385, 387, 394, 395, 396, 402, 508, 509, 510, 511, 515, 516, 521, 577, 578, 586,
410, 412, 418, 423, 428, 445, 446, 449, 450, 451, 605, 607, 636, 637, 657, 675, 676
452, 454, 455, 456, 457, 458, 459, 460, 462, 463, propertyChange 96, 97, 263, 269
464, 465, 466, 467, 470, 472, 474, 476, 480, 482, PropertyChangeEvent 260, 261, 262, 263, 264, 267,
338, 340-344, 346, 347, 349, 351, 352, 357-361, 120, 140, 144, 145, 147, 148, 149, 152, 195, 196,
375, 376, 383, 409, 424, 425, 428, 433, 434, 436, 258, 260, 261, 281, 283, 412, 418, 423, 425, 427,
443, 445, 446, 447, 449-451, 452, 454, 455, 456, 430, 500, 520, 521, 522, 523, 526
459, 462, 463, 465, 467, 480, 483, 485, 486, 489, TraceTarget 523, 524
490, 492, 493, 495, 496, 499, 502, 503, 504, transactions xxi, 252, 285, 287
508-511, 514, 524, 525, 527, 528, 529, 531, 532, Transfer Object Assembler 377
563, 567, 581, 585, 587, 589, 590, 594, 599, 600, transitions 65
605, 608-612, 616, 618, 619, 641, 644, 646, 647, TreeItemRenderer xv, 387, 388, 389, 395
652, 653, 655, 657, 663, 664, 666, 667, 669, TreeListData 394, 395, 396
670, 672, 675-679, 681, 683, 692 Tree control 366, 367, 369, 370, 377, 381, 382, 385,
SWC 30, 402, 403, 404, 406, 407, 412, 413, 418, 438, 387, 396
439, 448, 501 typeof 319, 320, 337, 349, 492, 610, 638, 641
Swing 3, 6, 7, 11, 13, 14, 30, 36, 62, 90, 169, 171, 186
sync() 217, 252, 266, 280, 281, 283, 284, 285, 287, 293 U
sync-method 212, 213, 215, 217, 219, 221, 232, 233, UIClassFactory 481, 482, 483, 484, 494, 495, 499, 500,
234, 235 501, 502, 503, 505, 507, 508, 509, 510, 511, 512,
System.setClipboard 643, 644, 681 513, 515
SystemManager 45, 46, 402, 410, 411, 426, 430, 431, UIComponent 46, 359, 387, 392, 433, 468, 477, 516,
435, 437 586, 587
system domain 401 undefined 38, 81, 82, 88, 96, 97, 111, 112, 371, 373,
379, 383, 394, 396, 433, 436, 462, 463, 464, 465,
T 489, 490, 491, 492, 493, 513, 515, 611, 612, 656
TabNavigator 33, 172, 272, 273, 275, 277, 284 undoItem() 268
target 25, 26, 65, 89, 91, 96, 139, 140, 141, 144, 145, UPDATE 218, 232, 233, 234, 236, 237, 240, 266, 267,
186, 229, 232, 290, 362, 401, 413, 414, 418, 439, 271, 464, 470, 472, 666, 668, 669, 671, 675
470, 471, 521, 522, 523, 524, 525, 526, 527, 528, updateDisplayList() 389, 461, 463, 477, 479, 578
529, 532, 539, 566, 567 updateItem() 212
TextInput xiv, 28, 33, 59, 61, 65, 67, 87, 88, 93, 94, 95,
118, 120, 152, 339, 340, 343, 345, 430, 431, 436, V
437, 467, 479, 487, 488, 490, 492, 496, 505, 506, validators.properties 490
560, 561, 564, 565, 568, 569, 608, 609, 612, 619, valueCommit 319, 337, 349, 471, 472
647, 673 variableRowHeight 182, 184, 504, 507
theriabook-manifest.xml 448, 487 VBA 604, 632, 633, 649, 650, 651, 654, 674, 675,
theriabook.swc 448, 450, 479, 487, 490, 501, 502, 515 676, 694
theriabook.swf 500, 501 VBox 30, 31, 32, 33, 35, 63, 128, 135, 186, 200, 433,
thousandsSeparator 489, 490 562, 564, 565, 568, 569, 594, 595, 608, 619, 620,
Thumbnail xvi, 552 647, 648, 668, 673, 674
TileList 33, 554, 560, 561, 562, 564, 568 VBScript 630, 632, 634, 641
Timer 91, 136, 550, 551, 556, 557, 570, 693 VDividedBox 33, 186, 187, 209, 210, 297, 298
Tomcat xvi, 116, 161, 181, 189, 195, 243, 244, 537, Version Control System xi, 73
538, 539, 540, 541 view states 566, 570
topic 63, 158, 189, 190, 191, 192, 193, 194, 196, 197, VT_ARRAY 641
198, 199, 201, 218, 328, 361, 385, 515 VT_DATE 632, 633
trace 21, 28, 38, 40, 41, 66, 67, 68, 81, 82, 84, 86, 105,
W
WEB-INF/classes 162
WEB-INF/lib 162, 213, 244, 246
WebService 370
Web 2.0 xxi, 4, 146
Web Services xvi, 9, 34, 156, 253, 544, 561, 570
wedge 171, 187, 188
wordWrap 108, 182, 183, 184, 507
Workbook 630, 650, 651, 675, 676, 693
WPF ix, 4, 7, 9, 10
WTP xvi, 537, 538, 539, 541
X
XMLHttpRequest 4, 7
XMLList 39, 159, 163, 164, 167, 168, 170, 174, 177,
201, 367, 373
XMLListCollection xii, 126, 130, 131, 134, 138, 164,
181, 185, 367
XPath 164, 223
xsl:apply-templates 223, 234, 685, 686, 687
xsl:call 225, 228, 229, 232, 234, 236, 238, 239, 240
xsl:template 222, 223, 225, 226, 229, 231- 240, 685,
686-688
xsl:value-of 222, 223, 225, 226, 228, 229, 232-240,
685, 687, 688
XSLT 604, 676, 689, 694
Y
Yahoo! Finance 178, 179
Z
ZIP 211, 214, 220, 227, 230, 241, 403
FREE DVD ”I think that Flex for rich Internet client appli-
cations can become a major player. Its easy
Dr. Victor Rasputnis is a
Managing Principal of Farata
$695
cross-platform support removes many pro- Systems. He’s responsible for
grammer headaches, the component model providing architectural design,
offers powerful library reuse, and the result implementation management
produces a very comfortable and appealing and mentoring to companies migrating to
VALUE
interface for the client to use. Because this XML Internet technologies. He holds a PhD
book teaches you how to use Flex along with in computer science from the Moscow
the dominant server-side development tool Institute of Robotics.
(Java), it’s an ideal introduction if you want to
10 SESSIONS learn how to leverage these technologies.” Anatole Tartakovsky is a
- Bruce Eckel, author, Thinking in Java Managing Principal of Farata
Systems. He’s responsible for
“The authors have been key contributors the creation of frameworks
to Flex’s success via their participation in and reusable components.
our beta programs, posts to community fo- Anatole has authored a number of books
rums, public presentations, and blog post- and articles on AJAX, XML, Internet and
ings… There’s a lot to learn, but Yakov, client/server technologies. He holds an
Victor, and Anatole have done an excellent MS in mathematics.
job introducing you to everything you need
to know to build a robust application.”
– Matt Chotin, Adobe, Product Manager The book is aimed squarely at IT devel-
opers. It is not a replacement for the
Yakov Fain is a Mangaging documentation or tutorials that ship with
Principal of F arata Sys- Flex. Instead, this book is a practical course
tems. He’s responsible for that takes you into the world of real-life
the Enterprise Architecture RIA applications. After a brief introduction
Learn how to build the next and emerging technologies. to Flex programming, the authors give you
generation of Web applications Yakov has authored several Java books, a master class on the process of creating
dozens of technical articles, and his blog reusable Flex components; show you how
from the experts.
is hugely popular. Sun Microsystems to create a slideshow and custom charts;
has awarded Yakov with the title Java give you practical advice on building
This DVD also contains the Champion. He leads the Princeton Java large enterprise applications and debug-
files required to run the sample Users Group. Yakov holds a BS and MS in ging techniques; and explain the internal
Applied Math and is an Adobe Certified communication between Flex and external
programs in this book.
Flex Instructor. applications like Microsoft Excel.
$119 US
www.theriabook.com
710 The World’s Leading i-Technology Publisher
RIA WITH ADOBE FLEX AND JAVA