Awesome, so it should get a good workout! Wonderful ;o) So there are several layers to what I am doing with Flex integration, so I'll give you the big picture.
Basically, I wanted to make it as close as possible to how CF does remoting in the first place, with <cfproperty> and alias attributes on CFCs. So going Transfer=>Flex, is pretty straight forward. You need to create decorators for your TO's, with the appropriate <cfproperty> and alias attributes for your values. This gives you lots of flexibility as you can choose to send or not send whatever information you want from your TO and Decorator to Flex. This is exactly the same as you would in regular CF=>Flex communications. The only extra piece of information that is required is a 'transferAlias' attribute on the cfcomponent tag of your decorator, which needs to be the class name of the <object> definition in Transfer, or if for some reason you are sharing decorators amongst <object> definitions, if you define 'this.transferAlias' on your object when it is created, that will work as well. This is used for Flex=>Transfer communication. That's pretty much it for Transfer=>Flex Now when doing Flex=>CF, there is obviously issues as as the created .cfcs that Flex returns to CF don't have all the injected methods we have all come to love, so to that effect we now have the transfer.com.remoting.VOConverter.cfc. For incoming Value Objects from Flex, we run them through VOConverter.convert(), and it will take all the values that come back from Flex, and apply them to the appropriate TransferObjects(s) as neccessary. You can then save them, or do as you will with them as you need to. In the long term, if you are using ColdSpring, the VOConverter will be incorporated into some CS AOP classes you can apply to your RemoteProxyFactory generated RemoteProxies, so you will have the option of manually writing your RemoteProxies, or you can do it with CS as well. You can see this stuff at work in my POC Transfer RemoteProxy that is available here: http://svn.riaforge.org/transfer/transfer/trunk/com/remoting/RemoteProxy.cfc Here is me creating an instance of it, for my Flex Unit tests. http://svn.riaforge.org/transfer/flexunittest/trunk/cfml/cfc/TransferRemoteProxy.cfc You can also see some Decorators built for remoting here: http://svn.riaforge.org/transfer/flexunittest/trunk/cfml/cfc/decorator/ Really the Transfer remote proxy isn't supposed to be used for 'real' applications, but gives you a quick overview of how to use the VOConverter, and/or is useful for quick prototyping. The other layer to this is the code generation layer. I've built some quite extensible static code generation tools right into Transfer, which comes with a Decorator Generator and Templates for generating your decorators for you, with the required remoting information already inside them. What makes this generator quite nifty is that while you can use it for one time generation, it defined 'blocks' within your generated code. That means that if your Transfer XML changes, you can re-run the generator, and it will * only change the code inside those blocks *, it won't changed any of your custom code inside the Decorators. It also means that if you have already written a Decorator, you can ADD the block comments (it's just a comment format) inside your Decorator, and then run the generator, and it will then ADD the generated block from the Template. My Flex Unit tests rerun the generation code every time (the template for Decorator Remoting still requires some work for parent m2o, m2o's and m2ms), and you can see that here: http://svn.riaforge.org/transfer/flexunittest/trunk/cfml/cfc/TestBootstrap.cfc I'll get into more detail on generation as time goes on, where you can write your own Templates for Generators, and also write your own Generators for use with Transfer, but this should be enough to give you a taste. Mark On Sat, Nov 29, 2008 at 8:53 AM, Tom McNeer <[EMAIL PROTECTED]> wrote: > Mark, > > Me, too. I have one client for whom I have done a public-facing application > using Transfer, and now we're getting ready to build lots of internal > management applications. Those apps will be primarily (or all) in Flex, and > I'm certainly planning on using Transfer. > > I also have another project in the planning stages, to manage drug research > studies. It'll be Flex, too, and I was planning on using a > Transfer/ColdSpring back end. > > > -- > Thanks, > > Tom > > Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560 > > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" 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/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
