I agree that making it all work without a helper project is better, but here are the reasons I created it:
EnhancedAs3TypeFactory -- This was needed to map Java's Collection, List, and Set into Flex's ArrayCollection. At least in the earlier version this did not happen by default, they were serialized into something that needed the GraniteDS collection in Flex. EnhancedJavaAs3GroovyTransformer -- I separate out the "base" and "regular" classes in my source tree. The "base" classes are (re)code generated on every build no matter what, but the "regular" ones don't. So far this is typical GAS3 behavior. However, by default GAS3 put my interfaces and enums in with the "regular" source tree...but I wanted them generated every time. So I created this class to extend the normal transformer in order to alter the place where generated enum and interface classes are placed to use the BaseOutputDirectory (e.g. /src/main/flex-generated). This class also filters out any package-info.java files so that nothing is generated for them, although I later learned that it was possible to exclude these files from within the POM. ServiceRemoteDestinationFactory and ServiceJavaRemoteDestination ServiceRemoteDestinationFactory removes the requirement that Service class be annotated with the GraniteDS annotation @RemoteDestination in favor of Spring's @RemotingDestination annotation which I already had in place. It also implements GraniteDS's org.granite.generator.as3.RemoteDestinationFactory interface in order to provide a customized remote destination object ServiceJavaRemoteDestination. ServiceJavaRemoteDestination which replaces Granite's @IgnoreMethod annotation with Spring's @RemotingExclude annotation. This class also determines the remoting destination name. This is computed by taking the simple class name, lower-casing the first character, and dropping an "Impl" suffix if it exists. In the future I'll also probably modify it to take into account Spring- Flex's @AMFIgnore annotation on fields. I have to add that GAS3 has nicely designed in these extension points and the fact that Flexmojos allows for easy injection of the extensions through POM configuration made it easy. Most of my knowledge in this area though came from another user here named Bryan...he's the real brain trust. Dave On Oct 27, 11:09 am, Christofer Dutz <[email protected]> wrote: > I think with the chages I added to FM4-RC2 you don't need to unpack > anything anymore if you use the GraniteDS Transformer. You can simply > define the template location be prefixing the path to the template > with "class:". But as you seem to be using a custom Transformer, this > will propably not work. > > I have to admit that I have never used custom > remoteDestinationFactory, transformer or as3typefactory and hereby > currently not quite understand what they are used for, but I'm allways > eager to learn :-) > > Chris > > 2011/10/27 Christofer Dutz <[email protected]>: > > > > > > > > > Hi David, > > > May I ask why you need such a tool? > > > I know the classes generated by GraniteDS per default use Granite > > classes on the flex side, but I simply created custom templates to > > generate classes that don't need them. > > > The only place where I currently see a real dependency to some > > GraniteDS stuff would be on the Server-Side in conjunction with > > services for wich I want to create flex clients using the > > remote-template. That GraniteDS @RemoteDestination annotation > > currently seems to be the only dependency I would need and my solution > > to this would be to simply create an annotation of that type (same > > package and Name) and to use that together with a custom template in > > the Generator. > > > I think it would be a good Idea to simply post my Templates together > > with the documentation cause currently this works without any helpers. > > > But I'm certainly interested in your solution if it is a better solution :-) > > So I would be glad, if you could point out some benefits of your > > solution in contrast to mine. > > > Chris > > > 2011/10/27 David Vree <[email protected]>: > >> Christofer -- that is good stuff. Like you, I use the generate goal > >> to create classes that work with BlazeDS. In my case, I felt the need > >> to avoid using any GraniteDS annotations in my code partially because > >> I didn't want the extra dependency and partially because I already > >> have Spring and JPA annotations that should have been enough. I've > >> written a tool I call gas3-helper which overrides some of the classes > >> in GAS3 via flexmojo configuration: > > >> <extraOptions> > >> <!-- Customized remote destination factory class --> > > >> <remoteDestinationFactory>com.mycorp.gas3helper.ServiceRemoteDestinationFactory</ > >> remoteDestinationFactory> > >> <!-- Customized transformer class --> > >> > >> <transformer>com.mycorp.gas3helper.EnhancedJavaAs3GroovyTransformer</ > >> transformer> > >> <!-- Customized type mapper --> > >> <as3typefactory>com.mycorp.gas3helper.EnhancedAs3TypeFactory</ > >> as3typefactory> > >> </extraOptions> > > >> I have Maven compile my custom templates into this JAR and then I add > >> the JAR to flexmojos as a dependency. I then pull the templates out > >> of this JAR as follows: > > >> <plugin> > >> <!-- Used to pull the Groovy templates for code > >> generation from the > >> Gas3-Helper JAR --> > >> <groupId>org.apache.maven.plugins</groupId> > >> <artifactId>maven-dependency-plugin</artifactId> > >> <executions> > >> <execution> > >> > >> <id>unpack-custom-groovy-templates</id> > >> <!-- Using the initialize phase > >> because it is before the generate > >> sources phase --> > >> <phase>initialize</phase> > >> <goals> > >> <!-- Using the unpack goal > >> because gas3-helper is not a > >> dependency of this module --> > >> <goal>unpack</goal> > >> </goals> > >> <configuration> > >> <artifactItems> > >> <artifactItem> > >> <!-- > >> Artifact Holds our custom templates --> > >> > >> <groupId>com.mycorp</groupId> > >> > >> <artifactId>gas3-helper</artifactId> > >> > >> <version>${gas3helper.version}</version> > >> > >> <type>jar</type> > >> </artifactItem> > >> </artifactItems> > >> > >> <includes>**/*.gsp</includes> > >> > >> <outputDirectory>${project.basedir}/target/templates</ > >> outputDirectory> > >> </configuration> > >> </execution> > >> </executions> > >> </plugin> > > >> Because my gas3-helper project is a tool, my company has no problem if > >> I open source it. I don't have time, but you've done such a good job > >> documenting all this, if you wish to create a gas3-blazeds open source > >> project, I'd be happy to send you my notes and the project. I'd also > >> be happy to be a contributor, I just don't have time (or knowledge) to > >> set it all up. > > >> On Oct 27, 7:22 am, Christofer Dutz <[email protected]> > >> wrote: > >>> Hi, > > >>> I just updated my documentation of how to configure Flexmojos Code > >>> generation in my wiki ... I extended it with the description of one of > >>> the new features of FM4-RC2 (custom templates in the classpath) ... > >>> perhaps it helps > >>> someone.https://dev.c-ware.de/confluence/display/PUBLIC/Generating+your+model > > >>> Chris > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Flex Mojos" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >>http://groups.google.com/group/flex-mojos > > >>http://flexmojos.sonatype.org/ -- You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos http://flexmojos.sonatype.org/
