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 or the selected slice of the pie. 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:

<?xml version="1.0" encoding="utf-8"?>
<!--news2.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns="*" >
     <FinancialNews2 id="fn" security="ADBE"/>
</mx:Application>

The FinancialNews2 tag is spelled out in Listing 2. Another minor modification in Listing 2 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.

Programming Master-Detail Relationships
It's time to start thinking about connecting the portfolio and news data grids, which represent typical master-detail relationships. The user selects one security in the grid or the pie, and the news data grid has to be repopulated with potentially multiple rows representing the latest financial news on selected security. Or, technically speaking, we are planning to convert the line:

<FinancialNews2 id="fn" security="ADBE"/>

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} represents the value of this bindable property (see Listing 3).

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 4), it will produce code that dispatches an event on every change of that property. Then, while compiling our application, Flex will notice that FinancialNews2.security depends on the binding expression. But the expression, in turn, depends on the value 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 resizing 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 corresponding to the selected item (an XML object) in the underlying data provider. That's why, to populate the variable selectedSecurity we can write:

<mx:PieChart id="portfolioPie" itemClick="selectedSecurity=event.hitData.item.Symbol ..."/>

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" in Listing 4. 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.

Finally, to add a visual effect of the selected security in the pie we will explode the clicked wedge a bit more (see Figure 1 and Listing 5).

This concludes our series of Stock Portfolio applications based on Flex remoting.

Adding the JMS Feed to the Stock Portfolio
Now will reuse the POJO that we used to remote to - Portfolio.java see Listing 6 from Part 1 (CFDJ, Vol. 9 issue 5). This time, however, we will invoke it from inside a Java program, which will publish the quotes to a topic available to the Flex application. But first, let's take a look at the Java techniques we will be relying on.

Introduction to the Java Naming and Directory Interface
The Flex applications in the second part of our chapter will be subscribing to the messages published to a certain destination by the JMS-based Java program; hence the Flex Data Services have to be able to find the proper destination. In the Java world, the location of the objects is facilitated by JNDI, which exposes and locates objects via their names. JNDI decouples the physical implementation of the naming services from the client API.

JNDI has one or more contexts, which comprise a naming tree similar to directories/sub-directories 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 ActiveMQ was available under the Apache 2.0 license at www.activemq.org/.)

Let's consider an example that shows how to obtain and use the appropriate naming context.

A client program JndiExample 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.) (see Listing 6).

In this program we assume that the ActiveMQ creates the JNDI tree and binds TopicConnectionFactory 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.