The lazy loading thing would be cool. The guys at Farata system created a DataCollection.as class to handle that as well as updates. Its a good source for ideas.
http://sourceforge.net/projects/cleartoolkit/ For now, I've decided against lazy loading for a more explicit approach in order to maximize performance. We'll see...could be changing my mind in a few weeks if I get too much code bloat... Will send you my stuff...and don't need/want any credit... Dave On Oct 27, 11:48 am, Christofer Dutz <[email protected]> wrote: > @Grant .... I allready had them attached to the Page, I recently > (minutes ago) added some links with a little explanation. > > @David ... BlazeDS uses ArrayCollection per default for serializing > Sets and Lists so I think you no longer need your > EnhancedAs3TypeFactory. Regarding your > EnhancedJavaAs3GroovyTransformer I remember there once was an extra > parameter where you could make GraniteDS generate Enums in the > base-directory. Unfortunately this is no longer supported. Having the > Enums and Interfaces generated in the Base directory is also a thing > that I would really like. Perhaps re-adding the option to FM would be > a good idea ... I think I'll have a look at that. And now to your last > part ... I LIKE THAT ! :-) If you want to, you could send me your > solution and I would integrate that to my documentation (Of course > mentioning that this was your solution). > > One cool thing would be if the entity template was extended in a was > that BlazeDS4s lazy-loading features could be exploited. Unfortunately > I started with BlazeDS3 and never had the urge to dig into the cool > 4-features. > > Chris > > 2011/10/27 David Vree <[email protected]>: > > > > > > > > > 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. > > ... > > read more » -- 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/
