Yep got it thanks ... I'll look into it when I'm back in my office tomorrow :-)
Thanks :) Chris 2011/10/27 David Vree <[email protected]>: > @Christofer -- Email sent...let me know if you receive. > > On Oct 27, 12:00 pm, David Vree <[email protected]> wrote: >> 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> >> > >> >> >> >> ... >> >> 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/ > -- 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/
