We know that flex/flash as a technology is something we wish to move away in preference for HTML5. While HTML5 itself doesn't seem to be quite there with what it promised, but it is definitely going strong. And with Adobe itself saying that HTML5 is the future, newer projects are not using Flex/Flash. There are however, a sizeable population of existing projects which use Flex and can benefit from using the nice tools already available. One of them is the GraniteDS. While we generally use BlazeDS as the remoting mechanism, when it comes to helping out the developers with cross-language quirks, GraniteDS is quite helpful. With our typical application stack, we have (and want to continue to have) the bulk of the business logic in the 3-tier JEE app with a Flex UI talking to via a remoting message broker with Spring thrown in to be able to access remote services nicely. The trouble comes in when we talk beyond primitives being passed back and forth. I am by no means a Flex expert, but it was a pain to hand-roll the AS classes that mirrored the Java classes that were need on the Flex UI for rendering purposes. Here is where GraniteDS with its maven codegen plugin stepped in. You can model this as a maven dependency for your UI module and have the packaged swc included. Let's work it out with an example:
Say you have a domain objects called SpecialObject and User and now you have to display the combination of these in a UI. You create a view object called UserSpecialObjectView which is crafted by your viewing service call. This needs to be passed over to the Flex side (without having to handroll it again in AS and without having to worry about changes to the dependent Java classes). We define our module which is supposed to create the AS view objects (called graniteds-tester-vo in our example). In the pom we reuse the configuration given in the documentation, and ask it to generate AS classes for all Java classes in the said package and it creates a nice swc that can be included in the UI module.
One of my colleages, had asked as to how the plugin handles customizations that may be needed for the generated classes. The plugin creates two classes for each class that it encounters - a base class and an extension. The base is something that is out-of-bounds for modifications (in target/generated-sources) and any changes to it are anyway overwritten with each build. The extension is what is available for customizations and with the configuration in the example, goes and sits in src/main/flex and should be checked in. The funny thing here is that the code in src/main/flex depends on target/generated-sources. If seen in Eclipse, this might show up as a warning/error, but the Maven command line is able to handle this correctly because maven recognizes that generation of sources is a valid phase in the build lifecycle. It is only because the M2Eclipse maven plugin in eclipse is unable to handle this is the reason why this shows up as an error/warning. However, if you do a build from command line once, the stuff shows up correctly in Eclipse also.
References:
Say you have a domain objects called SpecialObject and User and now you have to display the combination of these in a UI. You create a view object called UserSpecialObjectView which is crafted by your viewing service call. This needs to be passed over to the Flex side (without having to handroll it again in AS and without having to worry about changes to the dependent Java classes). We define our module which is supposed to create the AS view objects (called graniteds-tester-vo in our example). In the pom we reuse the configuration given in the documentation, and ask it to generate AS classes for all Java classes in the said package and it creates a nice swc that can be included in the UI module.
One of my colleages, had asked as to how the plugin handles customizations that may be needed for the generated classes. The plugin creates two classes for each class that it encounters - a base class and an extension. The base is something that is out-of-bounds for modifications (in target/generated-sources) and any changes to it are anyway overwritten with each build. The extension is what is available for customizations and with the configuration in the example, goes and sits in src/main/flex and should be checked in. The funny thing here is that the code in src/main/flex depends on target/generated-sources. If seen in Eclipse, this might show up as a warning/error, but the Maven command line is able to handle this correctly because maven recognizes that generation of sources is a valid phase in the build lifecycle. It is only because the M2Eclipse maven plugin in eclipse is unable to handle this is the reason why this shows up as an error/warning. However, if you do a build from command line once, the stuff shows up correctly in Eclipse also.
References:
No comments:
Post a Comment