With the acquisition of Day, there has been a lot of work within engineering to integrate CRX into the LiveCycle ES technology stack. However, since LiveCycle ES is an extensible platform – as I have been preaching for the last few years 🙂 – there is no need to wait until the next version of the product is available to take advantage of CQ and CRX.
To demonstrate this point, I have build a custom component (DSC) for LiveCycle ES that uses the JCR api. Of course, I used the Component Development Tool posted on labs.adobe.com to create this component.
I built this component with service configuration parameters that enable you to define the CRX server URI and account information. Since this is just a sample, I took a shortcut and enabled hardcoded credentials to connect to CRX. The service has two operations addContent and retrieveContent. The operation properties are very straight forward. All you need to do is specify the CRX path where to save or retrieve the content, file name, etc.
Custom Component Eclipse Project (compiled JAR in the dist folder)
This does not replace the great work that will be coming out in the next release of LiveCycle ES. If you have not registered for the LiveCycle ES prerelease program, you need to check it out. This is a closed beta. to enroll, contact your Adobe sales rep.
After posting the previous article about being able to merge LCA files, another colleague contacted to say “This is great – but we need to generate LCA files from source as part of our build process”. It’s never enough is it? 🙂 Since most of the work was done I figured, why not add this functionality. I learned some interesting things along the way too.
I created a new class (com.adobe.tm.ant.tasks.GenerateAppInfoFile) that extends the Ant MatchingTask. My goal for this task is scan the src folder specified in the build.xml and process any LiveCycle ES applications it finds. Yes, you can create LCAs in batch! The rule is that you create a folder in src for each LC ES application you want to package. each folder MUST follow typical LCA structure. My Ant task will process each folder as a separate application and generate one LCA file per LiveCycle ES app.
Now that I have a little more experience with writing Ant tasks, I realize that it’s better practice to simply have a ant task property that points to the src folder and include the folder processing logic in the Java code [versus my approach in the previous post where I left file processing up to the build.xml author]. You will notice the simplicity in build.xml task definition. However, I feel that it’s up to the build.xml author to choose to support batch LCA file generation. For that reason, I have left the ant-contrib loop.
Here is an interesting tidbit… In the app.info file, each top-level-object (application asset) node contains a child element called properties. When I first had a look at some sample LCA files, I noticed that this node was different than the others. It’s value is clearly a Base64 encoded string. When I decoded the string, imagine my surprise when I realized that the value that was encoded is actually a serialized java.util.Properties object. After doing some investigations with my contacts in engineering, I found out that this was an element that was originally planned to contain LiveCycle ES asset configuration information, but in the end never gets used. It was planned to remove this element in the 2.5 release, but fell off the priority list. The bottom line is that although the properties element must be present with a Base64 encoded serialized java.util.Properies object – even if it’s empty. The reason is that the LCA importer looks for this entry, even if it’s not used, to validate the app.info file. I explain this, because if you look at the Java source code you’ll wonder what I am doing :o).
Binary Distribution: CustomAntTask.0.4_dist.zip
Project Source: CustomAntTask.0.4_src.zip
A couple of colleagues needed a solution where they could take multiple unrelated LiveCycle ES applications already exported as LCA (LiveCycle Archive) files and programmatically merge them into a single LCA file. What’s the use case? Let’s say that you have a source repository of small LiveCycle ES applications that are re-usable. Then, based on a set of requirements, you need to build a new LiveCycle ES application that would include those re-usable smaller apps. Of course, you could just import each application individually into your LiveCycle ES development environment. But that’s not real exciting is it? And what is more exciting than building an Apache Ant build script to do some magic?
I created a build.xml file that will grab all LCA files stored in a src folder(see the build.properties file for configuration) and extract them into a work folder. This is pretty trivial since LCA files are just ZIP files that contain the application assets as well as a file called app.info. This app.info file is the key. It’s an XML file that describes the LiveCycle ES application and what operations should be executed when imported into a LiveCycle ES server. Here comes the tricky part…
To create a “merged” LCA file, I needed to parse each app.info file of the source LCA files, build a new master and inject the individual application descriptors from the source LCA files. Can you imagine my surprise when I realized that there was no existing Ant task that does this?!?! Yeah, right! OK, so I have to create a custom Ant task – great! Turns out, yet another trivial job. It was very easy to create my own custom Ant task and expose it in the build.xml. As a reference, I used this short tutorial. All I had to do at that point is write the Java code to load each app.info file into an XML DOM, extract the necessary nodes, build a new master app.info and import the previously extracted nodes. Piece of cake ;o).
Once I included my new custom Ant task into my build.xml, I just passed in the fileset reference that contained all of the app.info files and voila… I got my first merged app.info file. We just then drop that bad boy into the build folder, copy the asset folders that came with each LCA file in there too; and with one final zip ant task package up the combined LCA file.
Note: I also used the ant-contrib package because I needed a for loop in my build.xml in order to loop through each LCA file.
You must have Apache Ant installed and configured on your machine.
Binary Distribution – Includes build.properties, build.xml, lib folder.
Source – Includes the Java source files for the custom Ant task.
Adobe and Tech Soft 3D announced that Tech Soft 3D will be taking on development and delivery of Adobe’s 3D technologies. This includes LiveCycle PDF Generator 3D and Acrobat Professional Extended. For more information, read the Tech Soft 3D announcement and Kumar Vora’s blog post.
Yesterday, Apple announced that it has lifted restrictions in regards to third-party developer guidelines. I think this is good news for some enterprise developers that are looking to target “iDevices” as clients for their enterprise applications. By using the Adobe’s Packager for iPhone in CS5, developers can deploy their apps via the App Store. As mentioned in the blog post from Adobe Corporate Communications, the strong partnership between Adobe and other device manufacturers to get Flash Player and AIR running on their devices provides enterprise developers with an impressive reach for mobile.
For those of you looking to become an Adobe Certified Expert on flex 4, check out Attest 3.0. Holly Schinsky and David Flatley have released the latest version of their certification study tool. Of course, it’s an AIR application 🙂
A nicely done app that features mini and full exams with random questions.
I plan on running a preconference session this year at MAX to showcase some really cool stuff for enterprise application developers. If you have not signed up for this session, you should have a look at this. It might change you mind 🙂
With the release of CS5 which includes Photoshop, Flash Builder 4 and Catalyst; provides a completely different approach to building enterprise applications. Imagine being able to start from a Photoshop image that represents the application interface. Blow is a screen shot of the login state of the application in Photoshop.
The second step is to import that image into Catalyst and use it to convert the artwork from Photoshop into controls. There is much more to Catalyst. You can define design-time data which enables you to run your prototype to see how it would work. The image below shows Catalyst processing the image from Photoshop. This image shows that a second state has been defined. Many properties like transitions can be easily configured.
Then, once all of the user interaction patterns have been defined, import the project (FXP) into Flash Builder 4. All of the components are available for coding. This is where we will leverage the LiveCycle Service Discover Plugin to hook up the application to LiveCycle ES. This could be any service made available by your LiveCycle ES server. In our case, we are using two simple processes that expose Content Services functionality. The first service retrieves a list of documents in a specific space. The second service enables the application to retrieve a document based on the user’s selection. And while we are at it, apply a Rights Management policy to the document to encrypt it on the way out. In the following image, you can see our project in Flash Builder 4. At the bottom are the LiveCycle ES services.
As you can see, this stuff is really cool and is just a sample of all the stuff we will cover in the preconference session.
Today, a brand new project call Adobe AIR Launchpad has been posted on labs.adobe.com. This utility makes the creation of Flash Builder 4 AIR application projects painless. For those of us that have created AIR applications, we all know the many configuration settings (sometimes confusing) required to have a transparent application with a custom install badge and icons. Not to mention the coding required to center the app on the screen, add native menu support, etc.
This is where the Adobe AIR Launchpad comes in. This small, but very valuable utility (also built on AIR) provides an intuitive and easy to understand visual interface that exposes these low-level options via simple checkboxes. Now THAT is going to save me loads of time. This utility was written by one of the developers that brought us Tour de Flex – Holly Schinsky aka DevGirl. You can read her post about the app on her blog.
But wait… there’s more!
Really? Can it be Marcel?
Yes, it can… Holly and the rest of the team have built enough AIR applications to know that there is a number of recurring things that many AIR apps require. If we look at the Samples section, we see that these application patterns are available for our new application. By selecting one or more of these patterns, the generated project will include the Tour de Flex samples which give you a major kick start in the right direction.
I highly recommend that you get the Adobe AIR Launchpad and give it a try. I am sure you will come to the same conclusion I have – this is going to be a major time saver!
Today, Adobe announced the acquisition of Day software. With this acquisition, Adobe will expand its enterprise software portfolio by adding Web Content Management (WCM). You can read the press release on adobe.com. Also, you can read Rob Tarkoff’s thoughts on our enterprise blog.
If you want to follow one of the most creative and talented guys in the enterprise RIA game, check out Michaël’s new blog RIAgora. I know I will.