Thanks -- and I'll post back any changes/bug fixes I come across.... On Sep 21, 11:55 pm, Bryan Turner <[email protected]> wrote: > I'd be happy to post the pom.xml for our Flex model module, as well as the > type factory, transformer and template files. The templates for the service > stuff you can use pretty easily. I'll post a couple Java annotations, too. > We use them to allow us to generate around some weaknesses in our object > model, and also to deal with some of the lazy compilation problems in Flex. > I'm away from my PC at the moment, but I'll post those things up tomorrow. I > really need to post them to the Granite mailing list as well; I see > questions like these fairly often, and I've spent a lot of time on our > solution. > > > Wow. Thanks for the information...incredibly useful stuff to know. > > Wow - you have really assembled a world-class solution...I am blown > > away. > > > I am torn however, as we are a small shop and I am not sure we can > > afford the investment in tooling that you guys have done to get it all > > to work well. > > > On the other hand, our system is new and our entities are fairly well > > composed. And it is likely that we'll be refactoring them a lot over > > the next year. > > > The lack of automatic generation of the RemoteObject service > > interfaces is a bummer, but I could conceivably do those by > > hand....for now. I also might start out by leaving the generated code > > in subversion....and not messing with source paths....again...for now. > > > Sounds like its not an easy path either way! > > > Any chance you are able and willing to share any of your pom and/or > > templates? If not, I totally understand and thank you again for your > > help. > > > On Sep 21, 11:42 am, Bryan Turner <[email protected]> wrote: > >> 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]> > > >> >> <flex-mojos%[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]> > > <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 > > ... > > 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/
