Non-Intrusive Java and Flex Code Generation

I received an email from an experienced Flex/Java developer stating that he likes some of our open source components, but questions the need of automated code generation. His main argument was that they already have a pretty large code base in Java with their own inheritance model and introducing code generators wouldn’t be an easy thing to do. I started typing the answer to that email, but then decided to make a blog out of it.

Those who don’t know our open source Clear Toolkit and its code generator Clear Data Builder (CDB) may refer to its Wiki page. To make it short, it generated CRUD application with fully functional communication between the Flex and Java layers.

Developers in a green field situation can generate the entire project with CDB and use it as a foundation for all development activities. But this time I want to make a statement, that even if you already have an existing Java persistence layer, you still can use the generated Assembler/DAO Java classes and Java/AS3 DTOs. We generate the code for Java service classes supporting automatic data synchronization between our Flex DataCollection and Java service classes.

The DataCollection automatically keeps track of all UI modifications made by the user via ChangeObjects. This piece alone is pretty valuable time saver.

We don’t dictate how you are going to implement the server-side business logic and persistence mechanism. You have EJBs extended from other classes? Fine. It’s none of our business. You want to use JPA based on Hibernate or EclipseLink? It’s up to you. Prefer Java Spring Framework? Select one checkbox in our Eclipse plugin. Want to code most of the Flex UI manually? No problem. But when the user will hit the button Save, call MyDataCollection.sync() and for retrieval – fill(). We are not intrusive.

I personally, don’t like Hibernate and prefer lighter MyBatis data mapping framework. Please go over the step 3 of our Flex/MyBatis tutorial at the Wiki site. On the Java side you write the following:
– Java DTO
– the Java Mapper, a MyBatis thingy that maps DTOs to SQL statements (we use Spring Dependency Injection)
– Java service class

Want to replace calls to the MyBatis layer in the step 3.4 with the calls to your pre-existing session EJBs? Easy. Want to write JDBC for persistence? It’s your call – instead of a Mapper class, invoke your manually written JDBC code in the step 3.4.

Now let’s take a look at the step 4 of the tutorial that deals with the Flex front end. CDB generates for you the entire under-the-hood communication between Flex and Java. No need to create RemoteObject, just call the method fill() that will find your service Java class and will get the data. For persistence, just call the method sync(). Keep in mind that we are talking about BlazeDS, not LCDS.

We also support nested data collections for master-detail scenarios (steps 7 and 8 of the tutorial) and data sync between multiple clients. We eat our own dog food. We’ve used this process in multiple real-world projects of various complexity. It works for us. It’ll work for you too.

Yakov Fain