David, a) Yes, we do generate ActionScript from our service interfaces. In order to be able to mock test our Flex code that calls AMF services, we need to--ASMock and Floxy/Flemit do not mock dynamic classes like RemoteObject correctly. However, the templates provided with Granite by default for services are not very good. That brings me to b)...
b) Yes, we generate interfaces for the services. I had to customize the Groovy templates *and* the Transformer to make this work. I customized the base template to generate an interface instead of a class, and the non-base template to generate a class that implements that interface. I had to extend the Transformer so that I could get the names right. For example, we have a service interface called ScheduledOrderService. I customized the Transformer so that the base template also generates an interface named ScheduledOrderService. The non-base template then generates AmfScheduledOrderService, implementing the interface. c) Whether in IDEA or Flex/FlashBuilder, you can configure where the source directories are. src/main/flex is not configured as a source directory, but target/src/base and target/src/as3 are. Flex/FlashBuilder, since they are not Maven-aware, really don't care what directories you use for source directories. Since IDEA is Maven and FlexMojos-aware, it just uses the generated config-report.xml, which contains the correct two source paths. I highly recommend you create a separate SWC just for your model if you're going to do code-generation, though. It's much easier to have everything work peacefully if the module you do all of the code-generation in is not a module you write a lot of code by hand in. d) Yes it can, and yes, I've had to. Our object model has some seriously poor programming practices, and as a result the emitted Flex model if it is code-generated using the stock GAS templates is completely useless. Our templates only vaguely resemble the ones originally provided with GAS at this point. We've created custom annotations for our Java which are understood by the Groovy templates and used to help it generate code that bypasses a lot of object model ugliness from the Java side when emitting Flex. Type mapping is a bit of a separate issue. You can subclass the default Granite type factory to perform arbitrary type mappings. For example, we map the Joda LocalDate and DateTime classes to a custom SimpleDate and standard Flex Date classes, respectively. As a result, the type mapping is pretty flexible. However, for our use cases, we needed the ability to do custom type mapping in a slightly different place in the generation process. So in our Groovy templates (I hate to admit this, but it was the only way to make code-generation for our project work like we needed it to) we use Reflection to get access to some private variables inside GAS. It's not the ideal approach, but it works. Hopefully in a future release of Granite they'll make the variables we need accessible by default. Hope this helps. Bryan On Tue, Sep 21, 2010 at 7:52 AM, Marvin Froeder <[email protected]> wrote: > Most of your question are probably already answered at granite site/user > list > http://www.graniteds.org/ > > VELO > > > On Tue, Sep 21, 2010 at 10:50 AM, David Vree <[email protected]>wrote: > >> 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]> >> <flex-mojos%[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]<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]<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/
