One of the coolest aspects of LiveCycle that we introduced in FlashBuilder 4, Adobe LiveCycle ES2 and Adobe LiveCycle DataServices 3.0 was data modeling. That underlying technology allows you to introspect web services, databases and the LiveCycle ES service registry and then have ActionScript code generated for you to connect to all these things, either directly or via Adobe LiveCycle DataServices. That same technology is used by LiveCycle ES Guides and by the new version of the Correspondence Management Solution Accelerator that will be coming out in LiveCycle ES2.5.
We spent a lot of time working on the FlashBuilder and LiveCycle Workbench tooling around the modeling tool, but, as I talk to people about their development workflows it’s becoming more and more obvious that the traditional command line, ANT, and increasingly Maven workflows are just as important as the RAD workflows we focused on.
Surprise, surprise, we didn’t entirely forget about those workflows, but it seems that we didn’t document them very well. So let’s rectify that.
If you have a model file (aka an FML file) you can generate the ActionScript from that using the FiberGen command line tool. There are hints of it in the Data Services JavaDocs but that’s certainly a needle in the haystack.
So how do you use it really ?
You need the following JAR files on your classpath
- collections-generic-4.01.jar
- commons-collections-2.1.1.jar
- commons-logging.jar
- dom4j-1.6.1.jar
- fiber-core.jar
- fiber-tools.jar
- freemarker-2.3.9.jar
If you have a copy of Data Services (3.0 or 3.1) you can find all these files at <LCDS-install-location>/tomcat/webapps/lcds/WEB-INF/lib
If you have a copy of LiveCycle Workbench ES2 then you can find all those files packaged up inside
<LCES-workbench-install-location>/workbench/plugins/com.adobe.model.core_1.0.0.v20091006254255.jar
You’ll have to unjar that file into another directory and then add that directory, as well as the third party jars extracted into that directory to your classpath. The fiber-core.jar and fiber-tools.jar are all exploded as separate .class files in that jar so don’t bother looking for them.
Invoke FiberGen: java fiber.gen.tools.FiberGen.
If you do that without any parameters it will kindly respond back with what your options are. The version of FiberGen that shipped with LiveCycle ES2 and LiveCycle Data Services 3.0 has the following syntax
FiberGen [-v] [-o outputdir] [-e entity ..] [-s service ..] [-c class] <model file>
The switches are:
- -e entity The name of an entity to generate code for. Can be given more than once to specify more than one entity. -o outputdir The output directory for generated code. Defaults to the current directory.
- -s service The name of a service to generate code for. Can be given more than once to specify more than one service.
- -v Verbose output. Extra informational messages are printed to the standard output.
- model file The name of the Fiber Markup Language (FML) file to load as the model.
You can customize how the code is generated by specifying the -c option, but we’ll leave talking about that to next time. For completeness
- -c class The name of the generation class. This class must implement one of the six generator interfaces: ModelGenerator, EntityGenerator, ServiceGenerator, ModelGeneratorTask, EntityGeneratorTask or ServiceGeneratorTask. If you don’t specify -e or -s then the generator class used is fiber.gen.as.ASModelGeneratorTask, which generates ActionScript Value objects and service objects from the model. If any entity names are specified via -e, the generation class defaults to fiber.gen.as.ASValueObjectGenerator. If any service names are specified via -s, the generation class defaults to fiber.gen.as.ASServiceWrapperGenerator.
We enhanced FiberGen as part of adding more code generation options in LiveCycle Data Services 3.1. If you have that version of FiberGen then it adds these switches
- -as Generate ActionScript. This is the default.
- -java Generate Java. This can generate the Java source code for all the entities in your model, as JPA Annotated beans, as well as an Assembler. You can then customize all that code and then deploy it to the LiveCycle DataServices server. This also looks like something that merits a blog entry all of its own.
There’s a lot of documentation on the data modeling capabilities, the code that gets generated and how you can use it as part of the product documentation.
This gives you a taste for how you can get some of of the benefits of Adobe’s model driven development into your workflow. If you have any questions or comments, feel free to post them here or you can write me at mabutler at adobe.com
Thanks to Tom Jordahl for a lot of the content above.
