Caché + Java + Flex. Part 2

In the first part of the article, we looked at the combination of Caché + Java. Here you will see the structure of the project directly implementing the combination Caché + Java + Flex, as well as the main tools and their settings used to implement it. It is worth noting that only a general view of the interaction will be presented here, while specific examples will be discussed in the final part. We begin with a description of the modules that make up the project, and gradually move on to the features of their interaction.

Project structure

The project consists of three main modules:

1. flex - there are mxml-classes that describe the structure of the web-interface, additional ActionScript libraries, as well as generated ActionScript-projections of java-classes;
2. biz-logic - includes java -c and -m classes (more details about these classes were described in the first part of the article), a controller class, as well as interface classes responsible for the application logic;
3. web-application is a generated module that stores the generated jar files from the biz-logic module and swf from the flex module. In addition, this module is responsible for the generation of a WAR (Web application ARchive), which is later hosted on a web server.

Next is to say a few words about the tools used. Apache Tomcat version 6.0.35 was used as a web server. As noted in the first part, the Granite DS framework, a comprehensive solution for developing and integrating flex + javaEE RIA applications, is used as the main tool for Java and ActionScript communication. It needs to be connected both in the settings for flex, and biz-logic modules (how to do this will be described later). To automate the assembly of the project, Maven was chosen - a universal tool for assembling Java projects (compiling, creating a jar, creating a distribution package for the program, generating documentation). Maven, by default, creates a separate POM (Project Object Model) file for each of the modules, as well as one common for the entire project. POM files are used to configure the configuration, as well as to connect libraries from repositories (for more information about working with Maven, please read here , as well as working with Maven was discussed in detail in Habré ). We give examples of some of the settings used by us.

Content of POM files

Let us consider in more detail the POM files for each of the project modules. The Granite DS settings and the paths to the java classes whose projections need to be created are written to the flex module POM file. In addition, used libraries are attached here. For example,
The following code is also located in the POM file of the flex module and demonstrates the connection of the Granite libraries from the repository:

 <dependency> <!—  --> <groupId>org.graniteds</groupId> <artifactId>granite-core</artifactId> <!—  --> <version>${graniteds.version}</version> </dependency> 

In the POM file for the biz-logic module, parameters are specified for generating jar files.

In addition, you need to connect the cachedb and cachejdbc libraries to work with Caché (these libraries are provided as jar files along with Ensemble and Caché products. By default, they are located in “… \ dev \ java \ lib \ JDK16 \”).

For the web-application module, the POM file contains the binding of jar files generated earlier in the biz-logic module and options for generating a WAR file such as: the output directory for the generated file, connecting the war compiler libraries (maven-compiler-plugin, maven-war-plugin, maven-dependency-plugin). The options for generating the swf file should also be specified.

The project build order is the following: java-classes are compiled from the biz-logic module, then on their basis using GraniteDS are generated ActionScript-projections that are placed in the flex module. After that, the flex module is compiled and the .swf file is generated using the org.sonatype.flexmojos plugin (provided by Flex). It is placed along with the libraries used on the server by the path specified in the configuration file. Based on the generated .swf and .jar files, as well as the libraries used, a .war file is generated.

After all the settings have been made, you can proceed to a direct examination of the interaction mechanism Flex + Java + Caché.

General view of the interaction mechanism Flex + Java + Caché

Let's start with the fact that all Flex + Java interaction passes through ActionScript projections, among which, besides projections of stored classes (Java-m classes), there are also projection classes of server interfaces that are responsible for the application logic. At the time of launching the web application in the browser (on the client side), during initialization, an object is created that implements the server services interface (in our case, the userService object). Through it will continue to be a bunch of flex + java. To perform any operation on stored objects, the corresponding method in the userService is called. In case of successful passage of certain conditions on the server, the changes will also be made in the Caché database.
')
In addition, for the implementation of the described bundles via Granite DS, the following conditions are necessary.

1. The class must implement the Serializable interface.
2. In projected classes, Granite DS special syntax should be used. For example, for the get () and set () methods of the projected properties, you need to use @ExternalizedProperty tags, and for the most projected class - @ExternalizedBean, as shown in the example below.

 @ExternalizedBean(type=DefaultExternalizer.class) public class mCicl implements Serializable { … @ExternalizedProperty public List<mDiscipline> getListOfDisc() { return listOfDisc; } public void setListOfDisc(List<mDiscipline> listOfDisc) { this.listOfDisc = listOfDisc; } … } 

Do not forget about java-notation. So, for example, when naming a property with a capital letter in a projection, this property will have a private access modifier without get and set methods.

As mentioned above, in the flex module, the interface (@RemoteDestination) of the services (@ Servie) of the server is used, so the biz-logic module must have an appropriate implementation of this interface. For example, for a projected interface class

 @RemoteDestination public interface IUserService { … void delOneDisc(Integer i); … } 

implementation must be spelled out

 @Service public class UserService implements IUserService { … @Override public void delOneDisc(Integer i) { objT.deleteOneDisc(i); } … } 

Summing up this part, we can say that here we have described only the general mechanism of interaction Cache + Java + Flex through interfaces and projections, as well as the settings necessary for them, without focusing on specific examples. Therefore, in the next part of the article, we will focus more on specific practical examples. In particular, we consider the transformation of collections throughout the entire bundle, as well as examples of transferring objects from the database to the browser and back.