Bryan -- Thank you for your thoughtful response. A couple of follow up questions if I may:
a) Do you also generate the service classes (e.g. RemoteObjects - if you are using AMF)? b) If it does generate service classes, does it generate interfaces too? or just the classes? I really hate the idea of invoking methods on the weakly typed remoteobject instances.... Would love to see a set of ActionScript interfaces to match the Java interfaces we have on our service objects. c) Since you do not put the generated source files in the actual project, how to you get code hinting, or other IDE (Eclipse?) capabilities? I would have thought that the IDE would be going bonkers with errors about missing "imports", etc. How does this get resolved? d) I understand that GAS can be customized via Groovy templates? Is this something you had to do? I am concern about the type mapping capabilities... Again...thanks! Dave On Sep 20, 11:14 pm, Bryan Turner <[email protected]> wrote: > My project is using flexmojos:generate to code-generate several hundred > model classes. We've also made (unfortunately) heavy use of generics (mostly > incorrectly), and enums, and inheritance, and more. In my opinion, it is the > best way to ensure that your client and server models stay in sync, which is > very important with AMF calls. > > We do not check any of our generated model in. In fact, to help ensure this, > we generate the model under target/, which is in our svn:ignore set. Because > GAS has support for customizing the generated output, both with the > templates it uses to emit ActionScript and with the generated files > themselves, we check customized (by hand) model classes in under > src/main/flex. We the use a quick antrun to copy src/main/flex to > target/src/as3 before flexmojos:generate runs. This gives us the best of > both worlds: Customizable model classes which are code-generated from the > Java to keep them in sync. > > I'd be happy to post some chunks of that pom.xml. The only issues we've run > into so far have been with Granite and some of the bad decisions in our > object model (and we've been able to overcome them all). FlexMojos GAS > integration has worked splendidly. While your object model is small now, it > will most likely grow with time. This is a good thing to setup early and get > your team used to. It will save you a lot of hassle later. > > > I've got a BlazeDS back-end up and running and now I am looking at > > creating ActionScript service and value object classes. I have about > > 30 Java entities spread across 7-8 service classes -- so not too many, > > but not a trivial app either. > > > I am enticed by the generate goal which I understand is built on > > Granite Gas3. > > > There are many graphs within my entities, and extensive use of > > generics, but limited use of enums. Would I be better off just hand > > coding these things or should I rely on the code generator? > > > A related question is, do you check them into your SCM system? > > > -- > > 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]<flex-mojos%[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/
