Just wanted to post this here in case anyone else was getting frustrated by the use of iExternalizable from the gas3 system from GraniteDS. Just save the template as a .gsp file and update your GraniteDS nature to point the Entity template to your file (note: don't get confused by their docs, when you edit the location just put the DIRECT path to your file, and use forward slashes only...don't prefix it with 'file:' as they misleadingly insinuate (they are not wrong, just misleading)...i.e. c:/myTemplates/myTemplate.gsp)
In addition to that, I also stripped out the specialized GraniteDS datatypes in favor of the LCDS serialization convention that Adobe uses (i.e. a Java map should translate to an 'Object' type, a Java enum should translate to a 'String', and Java collections should always serialize as 'ArrayCollection')
For our application, we didn't do a 'base' version and a version that doesnt get touched by the code generator, but you could easily do so by modifying this template...it's not difficult...But if you just need a template that generates a LCDS compatible Actionscript class for your remoting service, this will do the trick:
I have two versions, this one is meant for Managed entities:
And this one is meant for non managed entities:
Hope this saves someone some time, I just threw this together pretty quickly for my own uses (using my preferred brace formatting) but feel free to expand upon it...I should note that this is a modified version of Granite DS's stock template, and all credit goes to them for gas3 and the template and such and such
When I get around to it I'll go ahead and add in some more data to the type ahead as well...
Thanks for the updated templates. What about contributing these templates to GraniteDS? It wouldn't be complicated to add an option to the GraniteDS builder (and the Ant task) so it would use your LCDS templates instead of genuine GraniteDS' ones.
If you are interested, post a JIRA issue with your files here.
And we will fix the documentation about the misleading "file:" prefix and forward slashes, thanks for the hint.
Hi Franck! You guys are more than welcome to use them, but if I were to do it the right way I wouldn't use these templates as they are only a patch rather than a fix...the type stuff is handled in the template through the use of if statements, but the proper way to resolve the type problem for Adobe's Java -> Actionscript serialization is to update the As3TypeFactory and As3Type classes to use Adobe's type conversions (as I'm sure you already know)...the change for creating a managed class as opposed to a non managed class is to replace the '[Bindable]' metadata with the '[Managed]' metadata, so that could easily be done with a passed in property from gas3...since you guys have the ability to do it the right way, that makes more sense of course
and sorry, didn't mean any offense about the 'file:' prefix, just noted it because it took me a few tests to finally get it to work correctly haha
I'm going to try to integrate your templates (together with a proper As3TypeFactory) and I'll ask you to test the next build (I don't have LCDS).
No offense with your "misleading but not wrong" (though it is quite a sophisticated distinction )
Quick question: how do you distinguish managed beans from bindable beans? Is there any specific LCDS runtime annotation (eg: @Managed) on the Java side that would indicate that we need a managed bean on the Flex side?
not really, unfortunately the entities are typically in a DAO which can either be local to the project or referenced in. In our case, we reference in the DAO and use GDS on the DAO project itself, which has no knowledge of the service which is the only piece annotated as managed. I just ran through the GDS UI and I think the best place to add the hook for creating it as 'Managed' instead would be to the package translater. That way we can specifically say 'any entities created from this package should be flagged as managed, and any from this other package should not be'
I ended up with the following solution (you can download a new build of the plugin here😞
Of course, I couldn't test anything with LCDS, tell me if it works or no.
Sounds like a good solution to me, but when I drop that new build in and then add the graniteDS nature to the project it says 'the chosen operation is not currently available'...also, oddly, the icon dissappeared for the context window...I pulled back to the last release build and added the nature through that, then switched to the new build as well to see if that would work and then when I go to the GraniteDS property page it pops up sayin g'Unable to create the selected property page'
Took me two hours to understand that you need to uninstall the builder from the Eclipse's "Help" menu: removing manually the old version from the plugins directory isn't enough, because the plugin was originally installed through an update site and it still exists has a kind of ghost extension... Hate this kind of problem .
So: open Eclipse, select "Help" -> "Install New Software...". Click on the "What is already installed?" (bottom right of the panel), select the GraniteDS Builder in the list and push the "Uninstall..." button. Close Eclipse, drop the new version of the builder in your plugins directory (make sure there no older version) and restart. It should work this time.
I just made a new build with few minor changes (cleanup, version updated, etc.), you can download it here.