Anyone doing / soon to be doing Flex work with Transfer?

[Mark Mandel]

Hey guys,

Just wanted to test the water a little here, as I've been writing up
some stuff for some pretty seamless integration with Flex... and I'm
very slowly getting towards the point where I may need some testers.

Obviously the code is available in SVN (even tho' its not complete)
right now, but if there are people who are looking to develop with
Transfer + Flex, I'd be more than happy to spend some time and talk
you through what I've been doing.

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Stephen Judd]

Mark,

  I'm going to be starting a Flex project in the next couple of weeks, and have been trying to figure out incorporating Transfer.  I'd love to hear what you're doing.

Steve

[Bob Silverberg]

I've done next to nothing with Flex yet, but Ive got a big project
coming up in the new year that will be primarily Flex for the
front-end. I look forward to seeing what you've come up with.

Bob

--
Bob Silverberg
www.silverwareconsulting.com

[James Allen]

Hey there Bob.

You always seem to nail your blog posts on Transfer etc, so I was wondering
if you have any plans to blog on your Flex learnings?

I've never used it either but keep on hearing how good it is.. Some blog
posts on the basics would be great to read.

---
James Allen

[Kevin Roche]

Mark,

I will be starting a new project soon that will use Flex and probably
Transfer too.

Kevin Roche

-----Original Message-----
From: transf...@googlegroups.com [mailto:transf...@googlegroups.com]
On Behalf Of Mark Mandel
Sent: 28 November 2008 06:48
To: transf...@googlegroups.com
Subject: [transfer-dev] Anyone doing / soon to be doing Flex work with
Transfer?

[Tom McNeer]

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

[Mark Mandel]

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

[Mark Mandel]

I should probably give people an update on this.

I got pretty stuck when I hit this bug here:
http://www.compoundtheory.com/?action=displayPost&ID=384

As it pretty much completely destroyed the possibility of doing
Flex/Transfer communication the way I * thought * the easiest way was
going to be.

That being said, the end result of be digging through layers of
Remoting, AMF and BlazeDS stuff, is a product called Conduit, that
will enable Transfer to do some pretty seamless integration with Flex,
without any of the AOP / Translation CFCs.

You can read more about Conduit here:
http://www.compoundtheory.com/?action=displayPost&ID=385

So you can pretty much ignore some of the earlier stuff (except the
generation code part, that stays), and expect something rather
different in the future.

Mark

On Sat, Nov 29, 2008 at 10:27 AM, Mark Mandel <mark....@gmail.com> wrote:
> 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....