Basically, queries and Transfer Objects are converted into simple Value Objects (or arrays of Value Objects) via AOP. These are nothing but flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can then be told to automatically convert the VO CFCs into corresponding ActionScript VOs.
On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
I take essentially the same approach, there are a couple differences, one is when it comes when returning large sets objects.
If you have an object that is composed of 5 other objects and has 2 one to many arrays that have say 5 composed objects, even returning 20 base objects will turn into several hundred objects which is VERY expensive to create in CF even on 8. In these situations I build essentially typed structs on the cf side that map to vo's on the as side, using this approach I can return literaly tens of thousands of composed objects in milliseconds, trying to return that many cfcs will crash your server.
Another challenge is: if you are going to use transfer decorators to pass directly to flex, then you have to be careful because the AMF CF CFC to AS VO converter (acronym much?) won't call the getM2OObject() so composed objects won't be included. This is why you have to do a little messaging and build the VO like Brian says.
You could use AOP to insert the composed object into to the transfer decorator before it gets returned, or you could use the to.getMemento() (I don't because transfer memento's are SHOUT CASE) and parse the result on the flex side, or you could use the trick (hack) that I use and build typed case preserving structs.
The combination of transfer, coldspring, flex and coldfusions automagic conversion is very powerful and pretty straight forward. Now if I could just convince Mark to change the GetMementoWriter so that is was case preserving... (I've got a patch file ;-)
On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> Basically, queries and Transfer Objects are converted into simple Value > Objects (or arrays of Value Objects) via AOP. These are nothing but flat > CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can then be > told to automatically convert the VO CFCs into corresponding ActionScript > VOs.
> On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > Hi all,
> > I keep getting pressure from a fair few people on how to do the whole > > Flex -> Transfer and back again thing.
> > Unfortunately, my Flex skills are far from developed, so I don't have > > an answer to this question.
> > For those of you who are developing with Flex and Transfer, can you > > give us a quick run down of how you go about doing it?
> > I would really appreciate it, and hopefully we can all learn something.
> I take essentially the same approach, there are a couple differences, one is > when it comes when returning large sets objects.
> If you have an object that is composed of 5 other objects and has 2 one to > many arrays that have say 5 composed objects, even returning 20 base objects > will turn into several hundred objects which is VERY expensive to create in > CF even on 8. In these situations I build essentially typed structs on the > cf side that map to vo's on the as side, using this approach I can return > literaly tens of thousands of composed objects in milliseconds, trying to > return that many cfcs will crash your server.
> Another challenge is: if you are going to use transfer decorators to pass > directly to flex, then you have to be careful because the AMF CF CFC to AS > VO converter (acronym much?) won't call the getM2OObject() so composed > objects won't be included. This is why you have to do a little messaging and > build the VO like Brian says.
> You could use AOP to insert the composed object into to the transfer > decorator before it gets returned, or you could use the to.getMemento() (I > don't because transfer memento's are SHOUT CASE) and parse the result on the > flex side, or you could use the trick (hack) that I use and build typed case > preserving structs.
> The combination of transfer, coldspring, flex and coldfusions automagic > conversion is very powerful and pretty straight forward. Now if I could just > convince Mark to change the GetMementoWriter so that is was case > preserving... (I've got a patch file ;-)
> On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote: > > Basically, queries and Transfer Objects are converted into simple Value > Objects (or arrays of Value Objects) via AOP. These are nothing but flat > CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can then be > told to automatically convert the VO CFCs into corresponding ActionScript > VOs.
> > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > Hi all,
> > > I keep getting pressure from a fair few people on how to do the whole > > > Flex -> Transfer and back again thing.
> > > Unfortunately, my Flex skills are far from developed, so I don't have > > > an answer to this question.
> > > For those of you who are developing with Flex and Transfer, can you > > > give us a quick run down of how you go about doing it?
> > > I would really appreciate it, and hopefully we can all learn something.
ActionScript is case sensitive, so any properties in the CFC must have matching case in the ActionScript class. Which means you have to define all the properties in the AS class in all upper case too. Which isn't good. ;-)
On Jan 27, 2008 4:44 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> Why is it such a big deal that the memento's are all in upper case?
> Mark
> On Jan 28, 2008 6:46 AM, Jon Messer <sylvan.mes...@gmail.com> wrote: > > I take essentially the same approach, there are a couple differences, > one is > > when it comes when returning large sets objects.
> > If you have an object that is composed of 5 other objects and has 2 one > to > > many arrays that have say 5 composed objects, even returning 20 base > objects > > will turn into several hundred objects which is VERY expensive to create > in > > CF even on 8. In these situations I build essentially typed structs on > the > > cf side that map to vo's on the as side, using this approach I can > return > > literaly tens of thousands of composed objects in milliseconds, trying > to > > return that many cfcs will crash your server.
> > Another challenge is: if you are going to use transfer decorators to > pass > > directly to flex, then you have to be careful because the AMF CF CFC to > AS > > VO converter (acronym much?) won't call the getM2OObject() so composed > > objects won't be included. This is why you have to do a little messaging > and > > build the VO like Brian says.
> > You could use AOP to insert the composed object into to the transfer > > decorator before it gets returned, or you could use the to.getMemento() > (I > > don't because transfer memento's are SHOUT CASE) and parse the result on > the > > flex side, or you could use the trick (hack) that I use and build typed > case > > preserving structs.
> > The combination of transfer, coldspring, flex and coldfusions automagic > > conversion is very powerful and pretty straight forward. Now if I could > just > > convince Mark to change the GetMementoWriter so that is was case > > preserving... (I've got a patch file ;-)
> > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote: > > > Basically, queries and Transfer Objects are converted into simple > Value > > Objects (or arrays of Value Objects) via AOP. These are nothing but flat > > CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > then be > > told to automatically convert the VO CFCs into corresponding > ActionScript > > VOs.
> > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > > Hi all,
> > > > I keep getting pressure from a fair few people on how to do the > whole > > > > Flex -> Transfer and back again thing.
> > > > Unfortunately, my Flex skills are far from developed, so I don't > have > > > > an answer to this question.
> > > > For those of you who are developing with Flex and Transfer, can you > > > > give us a quick run down of how you go about doing it?
> > > > I would really appreciate it, and hopefully we can all learn > something.
What Brian said. And I know if you made the change it would break some code (only with actionscript not cf), since I think anyone who is using transfer memento's to send data to Flex is probably just converting them on the AS side to proper case. At least that's what I would do, since I just couldn't bear working with all properties in upper case.
So you might not think it's worth breaking the backwards compatibility which is a valid concern, but I think in the long run as more people integrate Flex/Transfer it would be a worthwhile change.
Just my .02 anyway...
On Jan 27, 2008 3:48 PM, Brian Kotek <brian...@gmail.com> wrote:
> ActionScript is case sensitive, so any properties in the CFC must have > matching case in the ActionScript class. Which means you have to define all > the properties in the AS class in all upper case too. Which isn't good. ;-)
> On Jan 27, 2008 4:44 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > Hey Jon,
> > Why is it such a big deal that the memento's are all in upper case?
> > Mark
> > On Jan 28, 2008 6:46 AM, Jon Messer <sylvan.mes...@gmail.com> wrote: > > > I take essentially the same approach, there are a couple differences, > > one is > > > when it comes when returning large sets objects.
> > > If you have an object that is composed of 5 other objects and has 2 > > one to > > > many arrays that have say 5 composed objects, even returning 20 base > > objects > > > will turn into several hundred objects which is VERY expensive to > > create in > > > CF even on 8. In these situations I build essentially typed structs on > > the > > > cf side that map to vo's on the as side, using this approach I can > > return > > > literaly tens of thousands of composed objects in milliseconds, trying > > to > > > return that many cfcs will crash your server.
> > > Another challenge is: if you are going to use transfer decorators to > > pass > > > directly to flex, then you have to be careful because the AMF CF CFC > > to AS > > > VO converter (acronym much?) won't call the getM2OObject() so composed > > > objects won't be included. This is why you have to do a little > > messaging and > > > build the VO like Brian says.
> > > You could use AOP to insert the composed object into to the transfer > > > decorator before it gets returned, or you could use the to.getMemento() > > (I > > > don't because transfer memento's are SHOUT CASE) and parse the result > > on the > > > flex side, or you could use the trick (hack) that I use and build > > typed case > > > preserving structs.
> > > The combination of transfer, coldspring, flex and coldfusions > > automagic > > > conversion is very powerful and pretty straight forward. Now if I > > could just > > > convince Mark to change the GetMementoWriter so that is was case > > > preserving... (I've got a patch file ;-)
> > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote: > > > > Basically, queries and Transfer Objects are converted into simple > > Value > > > Objects (or arrays of Value Objects) via AOP. These are nothing but > > flat > > > CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > > then be > > > told to automatically convert the VO CFCs into corresponding > > ActionScript > > > VOs.
> > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > > > Hi all,
> > > > > I keep getting pressure from a fair few people on how to do the > > whole > > > > > Flex -> Transfer and back again thing.
> > > > > Unfortunately, my Flex skills are far from developed, so I don't > > have > > > > > an answer to this question.
> > > > > For those of you who are developing with Flex and Transfer, can > > you > > > > > give us a quick run down of how you go about doing it?
> > > > > I would really appreciate it, and hopefully we can all learn > > something.
> I take essentially the same approach, there are a couple differences, one > is when it comes when returning large sets objects.
> If you have an object that is composed of 5 other objects and has 2 one to > many arrays that have say 5 composed objects, even returning 20 base objects > will turn into several hundred objects which is VERY expensive to create in > CF even on 8. In these situations I build essentially typed structs on the > cf side that map to vo's on the as side, using this approach I can return > literaly tens of thousands of composed objects in milliseconds, trying to > return that many cfcs will crash your server.
> Another challenge is: if you are going to use transfer decorators to pass > directly to flex, then you have to be careful because the AMF CF CFC to AS > VO converter (acronym much?) won't call the getM2OObject() so composed > objects won't be included. This is why you have to do a little messaging and > build the VO like Brian says.
> You could use AOP to insert the composed object into to the transfer > decorator before it gets returned, or you could use the to.getMemento() (I > don't because transfer memento's are SHOUT CASE) and parse the result on the > flex side, or you could use the trick (hack) that I use and build typed case > preserving structs.
> The combination of transfer, coldspring, flex and coldfusions automagic > conversion is very powerful and pretty straight forward. Now if I could just > convince Mark to change the GetMementoWriter so that is was case > preserving... (I've got a patch file ;-)
> On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > Basically, queries and Transfer Objects are converted into simple Value > > Objects (or arrays of Value Objects) via AOP. These are nothing but flat > > CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can then be > > told to automatically convert the VO CFCs into corresponding ActionScript > > VOs.
> > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > Hi all,
> > > I keep getting pressure from a fair few people on how to do the whole > > > Flex -> Transfer and back again thing.
> > > Unfortunately, my Flex skills are far from developed, so I don't have > > > an answer to this question.
> > > For those of you who are developing with Flex and Transfer, can you > > > give us a quick run down of how you go about doing it?
> > > I would really appreciate it, and hopefully we can all learn > > > something.
His "typed structs" are Value Object CFCs, with all properties in the THIS scope and all properties declared in CFPROPERTY tags. On the Flex side, the ActionScript class defines the mapping with [RemoteClass(alias=" com.foo.MyComponent")] and the conversion happens automatically.
On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> Do your "typed structs" automatically get converted into the apprepriate > AS object or do you have code on the AS side that does that?
> I would be interested in see some example code of this process if it is > something you can post.
> --Kurt
> On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > I take essentially the same approach, there are a couple differences, > > one is when it comes when returning large sets objects.
> > If you have an object that is composed of 5 other objects and has 2 one > > to many arrays that have say 5 composed objects, even returning 20 base > > objects will turn into several hundred objects which is VERY expensive to > > create in CF even on 8. In these situations I build essentially typed > > structs on the cf side that map to vo's on the as side, using this approach > > I can return literaly tens of thousands of composed objects in milliseconds, > > trying to return that many cfcs will crash your server.
> > Another challenge is: if you are going to use transfer decorators to > > pass directly to flex, then you have to be careful because the AMF CF CFC > > to AS VO converter (acronym much?) won't call the getM2OObject() so composed > > objects won't be included. This is why you have to do a little messaging and > > build the VO like Brian says.
> > You could use AOP to insert the composed object into to the transfer > > decorator before it gets returned, or you could use the to.getMemento() > > (I don't because transfer memento's are SHOUT CASE) and parse the result on > > the flex side, or you could use the trick (hack) that I use and build typed > > case preserving structs.
> > The combination of transfer, coldspring, flex and coldfusions automagic > > conversion is very powerful and pretty straight forward. Now if I could just > > convince Mark to change the GetMementoWriter so that is was case > > preserving... (I've got a patch file ;-)
> > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > Basically, queries and Transfer Objects are converted into simple > > > Value Objects (or arrays of Value Objects) via AOP. These are nothing but > > > flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > > > then be told to automatically convert the VO CFCs into corresponding > > > ActionScript VOs.
> > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > > Hi all,
> > > > I keep getting pressure from a fair few people on how to do the > > > > whole > > > > Flex -> Transfer and back again thing.
> > > > Unfortunately, my Flex skills are far from developed, so I don't > > > > have > > > > an answer to this question.
> > > > For those of you who are developing with Flex and Transfer, can you > > > > give us a quick run down of how you go about doing it?
> > > > I would really appreciate it, and hopefully we can all learn > > > > something.
Actually Brian I am talking about typed structs. Although I have done and do sometimes do what you are describing but what I mean by typed struct is this...
Essentially if you add '__type__' key to your struct (not a cfc) with a value of "path.to.your.cfc" that matches the RemoteClass in AS then yes you get automatic conversion.
Example :
actionscript VO :
package vo { [RemoteClass(alias="path.to.your.cfc")] [Bindable] public class FooVO { public var FooId:Number = undefined; public var FooProperty:String = ""; }
}
coldfusion :
s = structNew(); s['FooId']=1; s['FooProperty']="Bar"; s['__type__']="path.to.your.cfc";
return s;
This struct (s) will get converted to a FooVO in Flex, this works recursively too so you can build typed stucts within typed structs and get composed vo's in Flex. Now "path.to.your.cfc" has to exist but it doesn't matter what is in it. I use "path.to.my.transfer.decorator" because I have those either way.
I should be very clear here though, this is undocumented as far as I can tell. Also I wish I could remember where I read about the '__type__' technique so that I could give credit, but I don't recall who's blog I read about it on.
On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> His "typed structs" are Value Object CFCs, with all properties in the THIS > scope and all properties declared in CFPROPERTY tags. On the Flex side, the > ActionScript class defines the mapping with [RemoteClass(alias=" > com.foo.MyComponent")] and the conversion happens automatically.
> On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > Do your "typed structs" automatically get converted into the apprepriate > > AS object or do you have code on the AS side that does that?
> > I would be interested in see some example code of this process if it is > > something you can post.
> > --Kurt
> > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > I take essentially the same approach, there are a couple differences, > > > one is when it comes when returning large sets objects.
> > > If you have an object that is composed of 5 other objects and has 2 > > > one to many arrays that have say 5 composed objects, even returning 20 base > > > objects will turn into several hundred objects which is VERY expensive to > > > create in CF even on 8. In these situations I build essentially typed > > > structs on the cf side that map to vo's on the as side, using this approach > > > I can return literaly tens of thousands of composed objects in milliseconds, > > > trying to return that many cfcs will crash your server.
> > > Another challenge is: if you are going to use transfer decorators to > > > pass directly to flex, then you have to be careful because the AMF CF CFC > > > to AS VO converter (acronym much?) won't call the getM2OObject() so composed > > > objects won't be included. This is why you have to do a little messaging and > > > build the VO like Brian says.
> > > You could use AOP to insert the composed object into to the transfer > > > decorator before it gets returned, or you could use the to.getMemento() > > > (I don't because transfer memento's are SHOUT CASE) and parse the result on > > > the flex side, or you could use the trick (hack) that I use and build typed > > > case preserving structs.
> > > The combination of transfer, coldspring, flex and coldfusions > > > automagic conversion is very powerful and pretty straight forward. Now if I > > > could just convince Mark to change the GetMementoWriter so that is was case > > > preserving... (I've got a patch file ;-)
> > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > > Basically, queries and Transfer Objects are converted into simple > > > > Value Objects (or arrays of Value Objects) via AOP. These are nothing but > > > > flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > > > > then be told to automatically convert the VO CFCs into corresponding > > > > ActionScript VOs.
> > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > > > Hi all,
> > > > > I keep getting pressure from a fair few people on how to do the > > > > > whole > > > > > Flex -> Transfer and back again thing.
> > > > > Unfortunately, my Flex skills are far from developed, so I don't > > > > > have > > > > > an answer to this question.
> > > > > For those of you who are developing with Flex and Transfer, can > > > > > you > > > > > give us a quick run down of how you go about doing it?
> > > > > I would really appreciate it, and hopefully we can all learn > > > > > something.
> Actually Brian I am talking about typed structs. Although I have done and do > sometimes do what you are describing but what I mean by typed struct is > this...
> Essentially if you add '__type__' key to your struct (not a cfc) with a > value of "path.to.your.cfc" that matches the RemoteClass in AS then yes you > get automatic conversion.
> Example :
> actionscript VO :
> package vo > { > [RemoteClass(alias="path.to.your.cfc")] > [Bindable] > public class FooVO > { > public var FooId:Number = undefined; > public var FooProperty:String = ""; > } > }
> coldfusion :
> s = structNew(); > s['FooId']=1; > s['FooProperty']="Bar"; > s['__type__']="path.to.your.cfc";
> return s;
> This struct (s) will get converted to a FooVO in Flex, this works > recursively too so you can build typed stucts within typed structs and get > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it doesn't > matter what is in it. I use "path.to.my.transfer.decorator" because I have > those either way.
> I should be very clear here though, this is undocumented as far as I can > tell. Also I wish I could remember where I read about the '__type__' > technique so that I could give credit, but I don't recall who's blog I read > about it on.
> On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote: > > His "typed structs" are Value Object CFCs, with all properties in the THIS > scope and all properties declared in CFPROPERTY tags. On the Flex side, the > ActionScript class defines the mapping with > [RemoteClass(alias="com.foo.MyComponent")] and the conversion happens > automatically.
> > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > Do your "typed structs" automatically get converted into the apprepriate > AS object or do you have code on the AS side that does that?
> > > I would be interested in see some example code of this process if it is > something you can post.
> > > --Kurt
> > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > I take essentially the same approach, there are a couple differences, > one is when it comes when returning large sets objects.
> > > > If you have an object that is composed of 5 other objects and has 2 > one to many arrays that have say 5 composed objects, even returning 20 base > objects will turn into several hundred objects which is VERY expensive to > create in CF even on 8. In these situations I build essentially typed > structs on the cf side that map to vo's on the as side, using this approach > I can return literaly tens of thousands of composed objects in milliseconds, > trying to return that many cfcs will crash your server.
> > > > Another challenge is: if you are going to use transfer decorators to > pass directly to flex, then you have to be careful because the AMF CF CFC > to AS VO converter (acronym much?) won't call the getM2OObject() so composed > objects won't be included. This is why you have to do a little messaging and > build the VO like Brian says.
> > > > You could use AOP to insert the composed object into to the transfer > decorator before it gets returned, or you could use the to.getMemento() (I > don't because transfer memento's are SHOUT CASE) and parse the result on the > flex side, or you could use the trick (hack) that I use and build typed case > preserving structs.
> > > > The combination of transfer, coldspring, flex and coldfusions > automagic conversion is very powerful and pretty straight forward. Now if I > could just convince Mark to change the GetMementoWriter so that is was case > preserving... (I've got a patch file ;-)
> > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > Basically, queries and Transfer Objects are converted into simple > Value Objects (or arrays of Value Objects) via AOP. These are nothing but > flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > then be told to automatically convert the VO CFCs into corresponding > ActionScript VOs.
> > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> > > > > > Hi all,
> > > > > > I keep getting pressure from a fair few people on how to do the > whole > > > > > > Flex -> Transfer and back again thing.
> > > > > > Unfortunately, my Flex skills are far from developed, so I don't > have > > > > > > an answer to this question.
> > > > > > For those of you who are developing with Flex and Transfer, can > you > > > > > > give us a quick run down of how you go about doing it?
> > > > > > I would really appreciate it, and hopefully we can all learn > something.
While that is actually quite interesting, I definitely wouldn't build anything of importance on top of it since, as you noted, it is undocumented and subject to change at any time. Simple Value Object CFCs are very inexpensive to create so I'll stick with that route.
On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> Actually Brian I am talking about typed structs. Although I have done and > do sometimes do what you are describing but what I mean by typed struct is > this...
> Essentially if you add '__type__' key to your struct (not a cfc) with a > value of "path.to.your.cfc" that matches the RemoteClass in AS then yes > you get automatic conversion.
> Example :
> actionscript VO :
> package vo > { > [RemoteClass(alias="path.to.your.cfc")] > [Bindable] > public class FooVO > { > public var FooId:Number = undefined; > public var FooProperty:String = ""; > } > }
> coldfusion :
> s = structNew(); > s['FooId']=1; > s['FooProperty']="Bar"; > s['__type__']="path.to.your.cfc";
> return s;
> This struct (s) will get converted to a FooVO in Flex, this works > recursively too so you can build typed stucts within typed structs and get > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it doesn't > matter what is in it. I use "path.to.my.transfer.decorator" because I have > those either way.
> I should be very clear here though, this is undocumented as far as I can > tell. Also I wish I could remember where I read about the '__type__' > technique so that I could give credit, but I don't recall who's blog I read > about it on.
> On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > His "typed structs" are Value Object CFCs, with all properties in the > > THIS scope and all properties declared in CFPROPERTY tags. On the Flex side, > > the ActionScript class defines the mapping with [RemoteClass(alias=" > > com.foo.MyComponent")] and the conversion happens automatically.
> > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > Do your "typed structs" automatically get converted into the > > > apprepriate AS object or do you have code on the AS side that does that?
> > > I would be interested in see some example code of this process if it > > > is something you can post.
> > > --Kurt
> > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > I take essentially the same approach, there are a couple > > > > differences, one is when it comes when returning large sets objects.
> > > > If you have an object that is composed of 5 other objects and has 2 > > > > one to many arrays that have say 5 composed objects, even returning 20 base > > > > objects will turn into several hundred objects which is VERY expensive to > > > > create in CF even on 8. In these situations I build essentially typed > > > > structs on the cf side that map to vo's on the as side, using this approach > > > > I can return literaly tens of thousands of composed objects in milliseconds, > > > > trying to return that many cfcs will crash your server.
> > > > Another challenge is: if you are going to use transfer decorators to > > > > pass directly to flex, then you have to be careful because the AMF CF CFC > > > > to AS VO converter (acronym much?) won't call the getM2OObject() so composed > > > > objects won't be included. This is why you have to do a little messaging and > > > > build the VO like Brian says.
> > > > You could use AOP to insert the composed object into to the transfer > > > > decorator before it gets returned, or you could use the > > > > to.getMemento() (I don't because transfer memento's are SHOUT CASE) > > > > and parse the result on the flex side, or you could use the trick (hack) > > > > that I use and build typed case preserving structs.
> > > > The combination of transfer, coldspring, flex and coldfusions > > > > automagic conversion is very powerful and pretty straight forward. Now if I > > > > could just convince Mark to change the GetMementoWriter so that is was case > > > > preserving... (I've got a patch file ;-)
> > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > Basically, queries and Transfer Objects are converted into simple > > > > > Value Objects (or arrays of Value Objects) via AOP. These are nothing but > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex can > > > > > then be told to automatically convert the VO CFCs into corresponding > > > > > ActionScript VOs.
> > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > > > > > wrote:
> > > > > > Hi all,
> > > > > > I keep getting pressure from a fair few people on how to do the > > > > > > whole > > > > > > Flex -> Transfer and back again thing.
> > > > > > Unfortunately, my Flex skills are far from developed, so I don't > > > > > > have > > > > > > an answer to this question.
> > > > > > For those of you who are developing with Flex and Transfer, can > > > > > > you > > > > > > give us a quick run down of how you go about doing it?
> > > > > > I would really appreciate it, and hopefully we can all learn > > > > > > something.
I use a custom cfc (a reverse factory?) that takes the memento (typed struct) back in and recursively turns it back into a proper transfer object that is then handed off to my service layer.
Some of the code I use is directly "borrowed" from bender ( http://www.tobytremayne.com/index.cfm/Bender), but when I first evaluated bender it didn't work as is, made some weird design choices (to me) and wasn't being developed, so I went my own way but used some of the core cf code.
It looks like bender may be revived so I'll have to look back into it.
As to Brians comment I 100% agree that it might not be right for everyone or every situation. It worked in CF7 and didn't break in CF8 and I have the luxury of being in house so I have complete control of the entire environment so I knowingly made the decision to use undocumented features.
As to cost, even simple cfc's get expensive when you are talking about thousands of them, this is when I use typed structs. It's also not a huge refactor to drop the "typing" and treat them like plain old mementos (which I do on the trip back anyway since the CFASDeserializer won't properly create a transfer object.
On Jan 27, 2008 8:01 PM, Mark Mandel <mark.man...@gmail.com> wrote:
> How do you go about bringing the VO data back to a Transfer Objects?
> Mark
> On Jan 28, 2008 12:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote: > > Actually Brian I am talking about typed structs. Although I have done > and do > > sometimes do what you are describing but what I mean by typed struct is > > this...
> > Essentially if you add '__type__' key to your struct (not a cfc) with a > > value of "path.to.your.cfc" that matches the RemoteClass in AS then yes > you > > get automatic conversion.
> > Example :
> > actionscript VO :
> > package vo > > { > > [RemoteClass(alias="path.to.your.cfc")] > > [Bindable] > > public class FooVO > > { > > public var FooId:Number = undefined; > > public var FooProperty:String = ""; > > } > > }
> > This struct (s) will get converted to a FooVO in Flex, this works > > recursively too so you can build typed stucts within typed structs and > get > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it > doesn't > > matter what is in it. I use "path.to.my.transfer.decorator" because I > have > > those either way.
> > I should be very clear here though, this is undocumented as far as I can > > tell. Also I wish I could remember where I read about the '__type__' > > technique so that I could give credit, but I don't recall who's blog I > read > > about it on.
> > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote: > > > His "typed structs" are Value Object CFCs, with all properties in the > THIS > > scope and all properties declared in CFPROPERTY tags. On the Flex side, > the > > ActionScript class defines the mapping with > > [RemoteClass(alias="com.foo.MyComponent")] and the conversion happens > > automatically.
> > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > > Do your "typed structs" automatically get converted into the > apprepriate > > AS object or do you have code on the AS side that does that?
> > > > I would be interested in see some example code of this process if it > is > > something you can post.
> > > > --Kurt
> > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > > I take essentially the same approach, there are a couple > differences, > > one is when it comes when returning large sets objects.
> > > > > If you have an object that is composed of 5 other objects and has > 2 > > one to many arrays that have say 5 composed objects, even returning 20 > base > > objects will turn into several hundred objects which is VERY expensive > to > > create in CF even on 8. In these situations I build essentially typed > > structs on the cf side that map to vo's on the as side, using this > approach > > I can return literaly tens of thousands of composed objects in > milliseconds, > > trying to return that many cfcs will crash your server.
> > > > > Another challenge is: if you are going to use transfer decorators > to > > pass directly to flex, then you have to be careful because the AMF CF > CFC > > to AS VO converter (acronym much?) won't call the getM2OObject() so > composed > > objects won't be included. This is why you have to do a little messaging > and > > build the VO like Brian says.
> > > > > You could use AOP to insert the composed object into to the > transfer > > decorator before it gets returned, or you could use the to.getMemento() > (I > > don't because transfer memento's are SHOUT CASE) and parse the result on > the > > flex side, or you could use the trick (hack) that I use and build typed > case > > preserving structs.
> > > > > The combination of transfer, coldspring, flex and coldfusions > > automagic conversion is very powerful and pretty straight forward. Now > if I > > could just convince Mark to change the GetMementoWriter so that is was > case > > preserving... (I've got a patch file ;-)
> > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > > Basically, queries and Transfer Objects are converted into > simple > > Value Objects (or arrays of Value Objects) via AOP. These are nothing > but > > flat CFCs with properties in the THIS scope and CFPROPERTY tags. Flex > can > > then be told to automatically convert the VO CFCs into corresponding > > ActionScript VOs.
> > > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > wrote:
> > > > > > > Hi all,
> > > > > > > I keep getting pressure from a fair few people on how to do > the > > whole > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > Unfortunately, my Flex skills are far from developed, so I > don't > > have > > > > > > > an answer to this question.
> > > > > > > For those of you who are developing with Flex and Transfer, > can > > you > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > I would really appreciate it, and hopefully we can all learn > > something.
> While that is actually quite interesting, I definitely wouldn't build > anything of importance on top of it since, as you noted, it is undocumented > and subject to change at any time. Simple Value Object CFCs are very > inexpensive to create so I'll stick with that route.
> On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > Actually Brian I am talking about typed structs. Although I have done and > > do sometimes do what you are describing but what I mean by typed struct is > > this...
> > Essentially if you add '__type__' key to your struct (not a cfc) with a > > value of "path.to.your.cfc" that matches the RemoteClass in AS then yes > > you get automatic conversion.
> > Example :
> > actionscript VO :
> > package vo > > { > > [RemoteClass(alias="path.to.your.cfc")] > > [Bindable] > > public class FooVO > > { > > public var FooId:Number = undefined; > > public var FooProperty:String = ""; > > } > > }
> > This struct (s) will get converted to a FooVO in Flex, this works > > recursively too so you can build typed stucts within typed structs and get > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it doesn't > > matter what is in it. I use "path.to.my.transfer.decorator" because I have > > those either way.
> > I should be very clear here though, this is undocumented as far as I can > > tell. Also I wish I could remember where I read about the '__type__' > > technique so that I could give credit, but I don't recall who's blog I > read > > about it on.
> > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > His "typed structs" are Value Object CFCs, with all properties in the > > > THIS scope and all properties declared in CFPROPERTY tags. On the Flex > side, > > > the ActionScript class defines the mapping with [RemoteClass(alias=" > > > com.foo.MyComponent")] and the conversion happens automatically.
> > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > > Do your "typed structs" automatically get converted into the > > > > apprepriate AS object or do you have code on the AS side that does > that?
> > > > I would be interested in see some example code of this process if it > > > > is something you can post.
> > > > --Kurt
> > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > > I take essentially the same approach, there are a couple > > > > > differences, one is when it comes when returning large sets objects.
> > > > > If you have an object that is composed of 5 other objects and has 2 > > > > > one to many arrays that have say 5 composed objects, even returning > 20 base > > > > > objects will turn into several hundred objects which is VERY > expensive to > > > > > create in CF even on 8. In these situations I build essentially > typed > > > > > structs on the cf side that map to vo's on the as side, using this > approach > > > > > I can return literaly tens of thousands of composed objects in > milliseconds, > > > > > trying to return that many cfcs will crash your server.
> > > > > Another challenge is: if you are going to use transfer decorators to > > > > > pass directly to flex, then you have to be careful because the AMF > CF CFC > > > > > to AS VO converter (acronym much?) won't call the getM2OObject() so > composed > > > > > objects won't be included. This is why you have to do a little > messaging and > > > > > build the VO like Brian says.
> > > > > You could use AOP to insert the composed object into to the transfer > > > > > decorator before it gets returned, or you could use the > > > > > to.getMemento() (I don't because transfer memento's are SHOUT CASE) > > > > > and parse the result on the flex side, or you could use the trick > (hack) > > > > > that I use and build typed case preserving structs.
> > > > > The combination of transfer, coldspring, flex and coldfusions > > > > > automagic conversion is very powerful and pretty straight forward. > Now if I > > > > > could just convince Mark to change the GetMementoWriter so that is > was case > > > > > preserving... (I've got a patch file ;-)
> > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > > Basically, queries and Transfer Objects are converted into simple > > > > > > Value Objects (or arrays of Value Objects) via AOP. These are > nothing but > > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY tags. > Flex can > > > > > > then be told to automatically convert the VO CFCs into > corresponding > > > > > > ActionScript VOs.
> > > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > > > > > > wrote:
> > > > > > > Hi all,
> > > > > > > I keep getting pressure from a fair few people on how to do the > > > > > > > whole > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > Unfortunately, my Flex skills are far from developed, so I don't > > > > > > > have > > > > > > > an answer to this question.
> > > > > > > For those of you who are developing with Flex and Transfer, can > > > > > > > you > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > I would really appreciate it, and hopefully we can all learn > > > > > > > something.
> I'm pretty sure it is documented and it was introduced for performance.
> On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > While that is actually quite interesting, I definitely wouldn't build > > anything of importance on top of it since, as you noted, it is > undocumented > > and subject to change at any time. Simple Value Object CFCs are very > > inexpensive to create so I'll stick with that route.
> > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > Actually Brian I am talking about typed structs. Although I have done > and > > > do sometimes do what you are describing but what I mean by typed > struct is > > > this...
> > > Essentially if you add '__type__' key to your struct (not a cfc) with > a > > > value of "path.to.your.cfc" that matches the RemoteClass in AS then > yes > > > you get automatic conversion.
> > > Example :
> > > actionscript VO :
> > > package vo > > > { > > > [RemoteClass(alias="path.to.your.cfc")] > > > [Bindable] > > > public class FooVO > > > { > > > public var FooId:Number = undefined; > > > public var FooProperty:String = ""; > > > } > > > }
> > > This struct (s) will get converted to a FooVO in Flex, this works > > > recursively too so you can build typed stucts within typed structs and > get > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it > doesn't > > > matter what is in it. I use "path.to.my.transfer.decorator" because I > have > > > those either way.
> > > I should be very clear here though, this is undocumented as far as I > can > > > tell. Also I wish I could remember where I read about the '__type__' > > > technique so that I could give credit, but I don't recall who's blog I > > read > > > about it on.
> > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > > His "typed structs" are Value Object CFCs, with all properties in > the > > > > THIS scope and all properties declared in CFPROPERTY tags. On the > Flex > > side, > > > > the ActionScript class defines the mapping with [RemoteClass(alias=" > > > > com.foo.MyComponent")] and the conversion happens automatically.
> > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > > > Do your "typed structs" automatically get converted into the > > > > > apprepriate AS object or do you have code on the AS side that does > > that?
> > > > > I would be interested in see some example code of this process if > it > > > > > is something you can post.
> > > > > --Kurt
> > > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> > wrote:
> > > > > > I take essentially the same approach, there are a couple > > > > > > differences, one is when it comes when returning large sets > objects.
> > > > > > If you have an object that is composed of 5 other objects and > has 2 > > > > > > one to many arrays that have say 5 composed objects, even > returning > > 20 base > > > > > > objects will turn into several hundred objects which is VERY > > expensive to > > > > > > create in CF even on 8. In these situations I build essentially > > typed > > > > > > structs on the cf side that map to vo's on the as side, using > this > > approach > > > > > > I can return literaly tens of thousands of composed objects in > > milliseconds, > > > > > > trying to return that many cfcs will crash your server.
> > > > > > Another challenge is: if you are going to use transfer > decorators to > > > > > > pass directly to flex, then you have to be careful because the > AMF > > CF CFC > > > > > > to AS VO converter (acronym much?) won't call the getM2OObject() > so > > composed > > > > > > objects won't be included. This is why you have to do a little > > messaging and > > > > > > build the VO like Brian says.
> > > > > > You could use AOP to insert the composed object into to the > transfer > > > > > > decorator before it gets returned, or you could use the > > > > > > to.getMemento() (I don't because transfer memento's are SHOUT > CASE) > > > > > > and parse the result on the flex side, or you could use the > trick > > (hack) > > > > > > that I use and build typed case preserving structs.
> > > > > > The combination of transfer, coldspring, flex and coldfusions > > > > > > automagic conversion is very powerful and pretty straight > forward. > > Now if I > > > > > > could just convince Mark to change the GetMementoWriter so that > is > > was case > > > > > > preserving... (I've got a patch file ;-)
> > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> > wrote:
> > > > > > > Basically, queries and Transfer Objects are converted into > simple > > > > > > > Value Objects (or arrays of Value Objects) via AOP. These are > > nothing but > > > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY > tags. > > Flex can > > > > > > > then be told to automatically convert the VO CFCs into > > corresponding > > > > > > > ActionScript VOs.
> > > > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > > > > > > > wrote:
> > > > > > > > Hi all,
> > > > > > > > I keep getting pressure from a fair few people on how to do > the > > > > > > > > whole > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > Unfortunately, my Flex skills are far from developed, so I > don't > > > > > > > > have > > > > > > > > an answer to this question.
> > > > > > > > For those of you who are developing with Flex and Transfer, > can > > > > > > > > you > > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > > I would really appreciate it, and hopefully we can all learn > > > > > > > > something.
> Holy c*!p really? Because it really does boost performance a lot with > large datasets. It would be great if it didn't feel like such a hack.
> On Jan 27, 2008 9:07 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> > I'm pretty sure it is documented and it was introduced for performance.
> > On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > > While that is actually quite interesting, I definitely wouldn't build > > > anything of importance on top of it since, as you noted, it is > > undocumented > > > and subject to change at any time. Simple Value Object CFCs are very > > > inexpensive to create so I'll stick with that route.
> > > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > Actually Brian I am talking about typed structs. Although I have > > done and > > > > do sometimes do what you are describing but what I mean by typed > > struct is > > > > this...
> > > > Essentially if you add '__type__' key to your struct (not a cfc) > > with a > > > > value of "path.to.your.cfc" that matches the RemoteClass in AS then > > yes > > > > you get automatic conversion.
> > > > Example :
> > > > actionscript VO :
> > > > package vo > > > > { > > > > [RemoteClass(alias="path.to.your.cfc")] > > > > [Bindable] > > > > public class FooVO > > > > { > > > > public var FooId:Number = undefined; > > > > public var FooProperty:String = ""; > > > > } > > > > }
> > > > This struct (s) will get converted to a FooVO in Flex, this works > > > > recursively too so you can build typed stucts within typed structs > > and get > > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it > > doesn't > > > > matter what is in it. I use "path.to.my.transfer.decorator" because > > I have > > > > those either way.
> > > > I should be very clear here though, this is undocumented as far as I > > can > > > > tell. Also I wish I could remember where I read about the '__type__' > > > > technique so that I could give credit, but I don't recall who's blog > > I > > > read > > > > about it on.
> > > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > His "typed structs" are Value Object CFCs, with all properties in > > the > > > > > THIS scope and all properties declared in CFPROPERTY tags. On the > > Flex > > > side, > > > > > the ActionScript class defines the mapping with > > [RemoteClass(alias=" > > > > > com.foo.MyComponent")] and the conversion happens automatically.
> > > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > > > > Do your "typed structs" automatically get converted into the > > > > > > apprepriate AS object or do you have code on the AS side that > > does > > > that?
> > > > > > I would be interested in see some example code of this process > > if it > > > > > > is something you can post.
> > > > > > --Kurt
> > > > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> > > wrote:
> > > > > > > I take essentially the same approach, there are a couple > > > > > > > differences, one is when it comes when returning large sets > > objects.
> > > > > > > If you have an object that is composed of 5 other objects and > > has 2 > > > > > > > one to many arrays that have say 5 composed objects, even > > returning > > > 20 base > > > > > > > objects will turn into several hundred objects which is VERY > > > expensive to > > > > > > > create in CF even on 8. In these situations I build > > essentially > > > typed > > > > > > > structs on the cf side that map to vo's on the as side, using > > this > > > approach > > > > > > > I can return literaly tens of thousands of composed objects in > > > milliseconds, > > > > > > > trying to return that many cfcs will crash your server.
> > > > > > > Another challenge is: if you are going to use transfer > > decorators to > > > > > > > pass directly to flex, then you have to be careful because the > > AMF > > > CF CFC > > > > > > > to AS VO converter (acronym much?) won't call the > > getM2OObject() so > > > composed > > > > > > > objects won't be included. This is why you have to do a little > > > messaging and > > > > > > > build the VO like Brian says.
> > > > > > > You could use AOP to insert the composed object into to the > > transfer > > > > > > > decorator before it gets returned, or you could use the > > > > > > > to.getMemento() (I don't because transfer memento's are SHOUT > > CASE) > > > > > > > and parse the result on the flex side, or you could use the > > trick > > > (hack) > > > > > > > that I use and build typed case preserving structs.
> > > > > > > The combination of transfer, coldspring, flex and coldfusions > > > > > > > automagic conversion is very powerful and pretty straight > > forward. > > > Now if I > > > > > > > could just convince Mark to change the GetMementoWriter so > > that is > > > was case > > > > > > > preserving... (I've got a patch file ;-)
> > > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> > > wrote:
> > > > > > > > Basically, queries and Transfer Objects are converted into > > simple > > > > > > > > Value Objects (or arrays of Value Objects) via AOP. These > > are > > > nothing but > > > > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY > > tags. > > > Flex can > > > > > > > > then be told to automatically convert the VO CFCs into > > > corresponding > > > > > > > > ActionScript VOs.
> > > > > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > > > > > > > > wrote:
> > > > > > > > > Hi all,
> > > > > > > > > I keep getting pressure from a fair few people on how to > > do the > > > > > > > > > whole > > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > > Unfortunately, my Flex skills are far from developed, so I > > don't > > > > > > > > > have > > > > > > > > > an answer to this question.
> > > > > > > > > For those of you who are developing with Flex and > > Transfer, can > > > > > > > > > you > > > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > > > I would really appreciate it, and hopefully we can all > > learn > > > > > > > > > something.
Agree, that is really great. I haven't had any performance issues with CFC VOs, but since I am generating them with AOP Advices, having the Advice generate an array of structs instead of an array of CFC VOs is a simple change and would definitely matter for larger sets of VOs. Thanks for the heads up on this Jon, and the confirmation Sean.
On Jan 28, 2008 12:22 AM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> thanks Sean, now I can feel all warm and fuzzy about my code...
> On Jan 27, 2008 9:11 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > Holy c*!p really? Because it really does boost performance a lot with > > large datasets. It would be great if it didn't feel like such a hack.
> > On Jan 27, 2008 9:07 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> > > I'm pretty sure it is documented and it was introduced for > > > performance.
> > > On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > > > While that is actually quite interesting, I definitely wouldn't > > > build > > > > anything of importance on top of it since, as you noted, it is > > > undocumented > > > > and subject to change at any time. Simple Value Object CFCs are very > > > > inexpensive to create so I'll stick with that route.
> > > > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > > Actually Brian I am talking about typed structs. Although I have > > > done and > > > > > do sometimes do what you are describing but what I mean by typed > > > struct is > > > > > this...
> > > > > Essentially if you add '__type__' key to your struct (not a cfc) > > > with a > > > > > value of "path.to.your.cfc" that matches the RemoteClass in AS > > > then yes > > > > > you get automatic conversion.
> > > > > This struct (s) will get converted to a FooVO in Flex, this works > > > > > recursively too so you can build typed stucts within typed structs > > > and get > > > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it > > > doesn't > > > > > matter what is in it. I use "path.to.my.transfer.decorator" > > > because I have > > > > > those either way.
> > > > > I should be very clear here though, this is undocumented as far as > > > I can > > > > > tell. Also I wish I could remember where I read about the > > > '__type__' > > > > > technique so that I could give credit, but I don't recall who's > > > blog I > > > > read > > > > > about it on.
> > > > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > > His "typed structs" are Value Object CFCs, with all properties > > > in the > > > > > > THIS scope and all properties declared in CFPROPERTY tags. On > > > the Flex > > > > side, > > > > > > the ActionScript class defines the mapping with > > > [RemoteClass(alias=" > > > > > > com.foo.MyComponent")] and the conversion happens automatically.
> > > > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> > > > wrote:
> > > > > > > Do your "typed structs" automatically get converted into the > > > > > > > apprepriate AS object or do you have code on the AS side that > > > does > > > > that?
> > > > > > > I would be interested in see some example code of this process > > > if it > > > > > > > is something you can post.
> > > > > > > --Kurt
> > > > > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> > > > wrote:
> > > > > > > > I take essentially the same approach, there are a couple > > > > > > > > differences, one is when it comes when returning large sets > > > objects.
> > > > > > > > If you have an object that is composed of 5 other objects > > > and has 2 > > > > > > > > one to many arrays that have say 5 composed objects, even > > > returning > > > > 20 base > > > > > > > > objects will turn into several hundred objects which is VERY > > > > expensive to > > > > > > > > create in CF even on 8. In these situations I build > > > essentially > > > > typed > > > > > > > > structs on the cf side that map to vo's on the as side, > > > using this > > > > approach > > > > > > > > I can return literaly tens of thousands of composed objects > > > in > > > > milliseconds, > > > > > > > > trying to return that many cfcs will crash your server.
> > > > > > > > Another challenge is: if you are going to use transfer > > > decorators to > > > > > > > > pass directly to flex, then you have to be careful because > > > the AMF > > > > CF CFC > > > > > > > > to AS VO converter (acronym much?) won't call the > > > getM2OObject() so > > > > composed > > > > > > > > objects won't be included. This is why you have to do a > > > little > > > > messaging and > > > > > > > > build the VO like Brian says.
> > > > > > > > You could use AOP to insert the composed object into to the > > > transfer > > > > > > > > decorator before it gets returned, or you could use the > > > > > > > > to.getMemento() (I don't because transfer memento's are > > > SHOUT CASE) > > > > > > > > and parse the result on the flex side, or you could use the > > > trick > > > > (hack) > > > > > > > > that I use and build typed case preserving structs.
> > > > > > > > The combination of transfer, coldspring, flex and > > > coldfusions > > > > > > > > automagic conversion is very powerful and pretty straight > > > forward. > > > > Now if I > > > > > > > > could just convince Mark to change the GetMementoWriter so > > > that is > > > > was case > > > > > > > > preserving... (I've got a patch file ;-)
> > > > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> > > > wrote:
> > > > > > > > > Basically, queries and Transfer Objects are converted into > > > simple > > > > > > > > > Value Objects (or arrays of Value Objects) via AOP. These > > > are > > > > nothing but > > > > > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY > > > tags. > > > > Flex can > > > > > > > > > then be told to automatically convert the VO CFCs into > > > > corresponding > > > > > > > > > ActionScript VOs.
> > > > > > > > > > I keep getting pressure from a fair few people on how to > > > do the > > > > > > > > > > whole > > > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > > > Unfortunately, my Flex skills are far from developed, so > > > I don't > > > > > > > > > > have > > > > > > > > > > an answer to this question.
> > > > > > > > > > For those of you who are developing with Flex and > > > Transfer, can > > > > > > > > > > you > > > > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > > > > I would really appreciate it, and hopefully we can all > > > learn > > > > > > > > > > something.
> thanks Sean, now I can feel all warm and fuzzy about my code...
> On Jan 27, 2008 9:11 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > Holy c*!p really? Because it really does boost performance a lot with > > large datasets. It would be great if it didn't feel like such a hack.
> > On Jan 27, 2008 9:07 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> > > I'm pretty sure it is documented and it was introduced for performance.
> > > On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > > > While that is actually quite interesting, I definitely wouldn't build > > > > anything of importance on top of it since, as you noted, it is > > > undocumented > > > > and subject to change at any time. Simple Value Object CFCs are very > > > > inexpensive to create so I'll stick with that route.
> > > > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > > Actually Brian I am talking about typed structs. Although I have > > > done and > > > > > do sometimes do what you are describing but what I mean by typed > > > struct is > > > > > this...
> > > > > Essentially if you add '__type__' key to your struct (not a cfc) > > > with a > > > > > value of "path.to.your.cfc" that matches the RemoteClass in AS then > > > yes > > > > > you get automatic conversion.
> > > > > This struct (s) will get converted to a FooVO in Flex, this works > > > > > recursively too so you can build typed stucts within typed structs > > > and get > > > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but it > > > doesn't > > > > > matter what is in it. I use "path.to.my.transfer.decorator" because > > > I have > > > > > those either way.
> > > > > I should be very clear here though, this is undocumented as far as I > > > can > > > > > tell. Also I wish I could remember where I read about the '__type__' > > > > > technique so that I could give credit, but I don't recall who's blog > > > I > > > > read > > > > > about it on.
> > > > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > > His "typed structs" are Value Object CFCs, with all properties in > > > the > > > > > > THIS scope and all properties declared in CFPROPERTY tags. On the > > > Flex > > > > side, > > > > > > the ActionScript class defines the mapping with > > > [RemoteClass(alias=" > > > > > > com.foo.MyComponent")] and the conversion happens automatically.
> > > > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> wrote:
> > > > > > > Do your "typed structs" automatically get converted into the > > > > > > > apprepriate AS object or do you have code on the AS side that > > > does > > > > that?
> > > > > > > I would be interested in see some example code of this process > > > if it > > > > > > > is something you can post.
> > > > > > > --Kurt
> > > > > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com> > > > wrote:
> > > > > > > > I take essentially the same approach, there are a couple > > > > > > > > differences, one is when it comes when returning large sets > > > objects.
> > > > > > > > If you have an object that is composed of 5 other objects and > > > has 2 > > > > > > > > one to many arrays that have say 5 composed objects, even > > > returning > > > > 20 base > > > > > > > > objects will turn into several hundred objects which is VERY > > > > expensive to > > > > > > > > create in CF even on 8. In these situations I build > > > essentially > > > > typed > > > > > > > > structs on the cf side that map to vo's on the as side, using > > > this > > > > approach > > > > > > > > I can return literaly tens of thousands of composed objects in > > > > milliseconds, > > > > > > > > trying to return that many cfcs will crash your server.
> > > > > > > > Another challenge is: if you are going to use transfer > > > decorators to > > > > > > > > pass directly to flex, then you have to be careful because the > > > AMF > > > > CF CFC > > > > > > > > to AS VO converter (acronym much?) won't call the > > > getM2OObject() so > > > > composed > > > > > > > > objects won't be included. This is why you have to do a little > > > > messaging and > > > > > > > > build the VO like Brian says.
> > > > > > > > You could use AOP to insert the composed object into to the > > > transfer > > > > > > > > decorator before it gets returned, or you could use the > > > > > > > > to.getMemento() (I don't because transfer memento's are SHOUT > > > CASE) > > > > > > > > and parse the result on the flex side, or you could use the > > > trick > > > > (hack) > > > > > > > > that I use and build typed case preserving structs.
> > > > > > > > The combination of transfer, coldspring, flex and coldfusions > > > > > > > > automagic conversion is very powerful and pretty straight > > > forward. > > > > Now if I > > > > > > > > could just convince Mark to change the GetMementoWriter so > > > that is > > > > was case > > > > > > > > preserving... (I've got a patch file ;-)
> > > > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> > > > wrote:
> > > > > > > > > Basically, queries and Transfer Objects are converted into > > > simple > > > > > > > > > Value Objects (or arrays of Value Objects) via AOP. These > > > are > > > > nothing but > > > > > > > > > flat CFCs with properties in the THIS scope and CFPROPERTY > > > tags. > > > > Flex can > > > > > > > > > then be told to automatically convert the VO CFCs into > > > > corresponding > > > > > > > > > ActionScript VOs.
> > > > > > > > > On Jan 26, 2008 8:29 PM, Mark Mandel <mark.man...@gmail.com> > > > > > > > > > wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > > I keep getting pressure from a fair few people on how to > > > do the > > > > > > > > > > whole > > > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > > > Unfortunately, my Flex skills are far from developed, so I > > > don't > > > > > > > > > > have > > > > > > > > > > an answer to this question.
> > > > > > > > > > For those of you who are developing with Flex and > > > Transfer, can > > > > > > > > > > you > > > > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > > > > I would really appreciate it, and hopefully we can all > > > learn > > > > > > > > > > something.
First, let me say I have absolutely nothing to contribute to anyone's knowledge regarding the subject of this thread. Rather, it's one important topic I'd really like to learn more about.
As Mark knows well from our recent conversation about hierarchical queries, I'm still working to learn the ins and outs of Transfer's features.
But I've been using the Model-Glue/ColdSpring/Transfer combination for a while, so I've touched the surface of both ColdSpring and Transfer. I have two Flex projects coming up -- my first real ones -- and one of them will utilize the model of an existing MG/CS/Transfer application.
I suspect there are a number of other folks out there in more-or-less my situation:
- I'm familiar enough with building in Model-Glue and Mach-II that I have some grasp of MVC architecture. - I've used Reactor, and now Transfer, enough that I like the idea of using an ORM framework, and I'm *relatively* comfortable with them, though I clearly have more to learn about (in particular) Transfer's capabilities. - I've only used ColdSpring for dependency injection; I understand that in not using AOP, I'm missing a whole world of power, and I'm experimenting with AOP in ColdSpring to learn it. - I'm just learning Flex. I understand the automatic translation of a flat CFC with properties into an ActionScript VO, and I can "get" how ColdSpring's creation of remote object proxies could be used to create such a flat CFC from a Transfer Object.
All that said -- and with the understanding that I'm a) willing to do the work to learn on my own, and b) well aware of the dangers of "copying" someone else's solution and taking it as the "one true way" -- it would be extremely helpful to me and, I'm sure, to others, if we could see some examples of the techniques discussed in this thread. From Brian's process, which sounds like a fairly straightforward use of AOP and CS remote objects to send flat CFCs, with whatever reverse processing he does when the object comes back from Flex. To Jon's use of typed structs. To whatever Sean happens to be using today.
I'm not asking someone to do my work for me. I'm not even asking that any of you spend a bunch of time putting together examples. If they're not something you can throw together in a few minutes, it's too much to ask.
But as Mark said in starting the thread, this is a topic of interest to many. Unfortunately, "many" are like me -- unable to contribute to the discussion, but eager to learn. Any code to learn from would be highly appreciated.
On Jan 28, 2008 2:19 PM, Tom McNeer <tmcn...@gmail.com> wrote:
> All that said -- and with the understanding that I'm a) willing to do the > work to learn on my own, and b) well aware of the dangers of "copying" > someone else's solution and taking it as the "one true way" -- it would be > extremely helpful to me and, I'm sure, to others, if we could see some > examples of the techniques discussed in this thread. From Brian's process, > which sounds like a fairly straightforward use of AOP and CS remote objects > to send flat CFCs, with whatever reverse processing he does when the object > comes back from Flex. To Jon's use of typed structs. To whatever Sean > happens to be using today.
I put up a simple example of converting a query to an array of Value Objects at http://www.briankotek.com/blog/index.cfm/2008/1/17/Yet-More-ColdSprin... might be a good start. This leverages my MetaDataAwareAdvice to instruct the Advice on what type of Value Objects to create. Using the struct approach would be about the same (I'll probably just update the GenericVOConverterAdvice to build up arrays of structs instead of actual CFC instances).
There is no "reverse engineering" when data comes in from Flex. The remote proxy would take simple arguments (ie productID, quantity, etc.) and then perform whatever processing they would in any other situation (web service call or call from a front-controller like Model-Glue).
I remember hearing about this feature or something similar for working with LCDs in CF 8. I didn't realize you could use this method in CF 7 and CF 8 while using the regular Flex remoting gateway.
--Kurt
On Jan 28, 2008 11:26 AM, Sean Corfield <seancorfi...@gmail.com> wrote:
> I believe it was omitted from the 7.0 docs (but haven't checked) even > tho' it did work in 7.0. > I'm on my iPhone otherwise I'd check it.
> On 1/27/08, Jon Messer <sylvan.mes...@gmail.com> wrote: > > Wow, it didn't even occur to me to search if it was documented or not > but > > here you go
> > thanks Sean, now I can feel all warm and fuzzy about my code...
> > On Jan 27, 2008 9:11 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > Holy c*!p really? Because it really does boost performance a lot with > > > large datasets. It would be great if it didn't feel like such a hack.
> > > On Jan 27, 2008 9:07 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> > > > I'm pretty sure it is documented and it was introduced for > performance.
> > > > On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > > > > While that is actually quite interesting, I definitely wouldn't > build > > > > > anything of importance on top of it since, as you noted, it is > > > > undocumented > > > > > and subject to change at any time. Simple Value Object CFCs are > very > > > > > inexpensive to create so I'll stick with that route.
> > > > > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> > wrote:
> > > > > > Actually Brian I am talking about typed structs. Although I have > > > > done and > > > > > > do sometimes do what you are describing but what I mean by typed > > > > struct is > > > > > > this...
> > > > > > Essentially if you add '__type__' key to your struct (not a cfc) > > > > with a > > > > > > value of "path.to.your.cfc" that matches the RemoteClass in AS > then > > > > yes > > > > > > you get automatic conversion.
> > > > > > This struct (s) will get converted to a FooVO in Flex, this > works > > > > > > recursively too so you can build typed stucts within typed > structs > > > > and get > > > > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but > it > > > > doesn't > > > > > > matter what is in it. I use "path.to.my.transfer.decorator" > because > > > > I have > > > > > > those either way.
> > > > > > I should be very clear here though, this is undocumented as far > as I > > > > can > > > > > > tell. Also I wish I could remember where I read about the > '__type__' > > > > > > technique so that I could give credit, but I don't recall who's > blog > > > > I > > > > > read > > > > > > about it on.
> > > > > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> wrote:
> > > > > > > His "typed structs" are Value Object CFCs, with all properties > in > > > > the > > > > > > > THIS scope and all properties declared in CFPROPERTY tags. On > the > > > > Flex > > > > > side, > > > > > > > the ActionScript class defines the mapping with > > > > [RemoteClass(alias=" > > > > > > > com.foo.MyComponent")] and the conversion happens > automatically.
> > > > > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> > wrote:
> > > > > > > > Do your "typed structs" automatically get converted into the > > > > > > > > apprepriate AS object or do you have code on the AS side > that > > > > does > > > > > that?
> > > > > > > > I would be interested in see some example code of this > process > > > > if it > > > > > > > > is something you can post.
> > > > > > > > --Kurt
> > > > > > > > On Jan 27, 2008 1:46 PM, Jon Messer <sylvan.mes...@gmail.com
> > > > wrote:
> > > > > > > > > I take essentially the same approach, there are a couple > > > > > > > > > differences, one is when it comes when returning large > sets > > > > objects.
> > > > > > > > > If you have an object that is composed of 5 other objects > and > > > > has 2 > > > > > > > > > one to many arrays that have say 5 composed objects, even > > > > returning > > > > > 20 base > > > > > > > > > objects will turn into several hundred objects which is > VERY > > > > > expensive to > > > > > > > > > create in CF even on 8. In these situations I build > > > > essentially > > > > > typed > > > > > > > > > structs on the cf side that map to vo's on the as side, > using > > > > this > > > > > approach > > > > > > > > > I can return literaly tens of thousands of composed > objects in > > > > > milliseconds, > > > > > > > > > trying to return that many cfcs will crash your server.
> > > > > > > > > Another challenge is: if you are going to use transfer > > > > decorators to > > > > > > > > > pass directly to flex, then you have to be careful because > the > > > > AMF > > > > > CF CFC > > > > > > > > > to AS VO converter (acronym much?) won't call the > > > > getM2OObject() so > > > > > composed > > > > > > > > > objects won't be included. This is why you have to do a > little > > > > > messaging and > > > > > > > > > build the VO like Brian says.
> > > > > > > > > You could use AOP to insert the composed object into to > the > > > > transfer > > > > > > > > > decorator before it gets returned, or you could use the > > > > > > > > > to.getMemento() (I don't because transfer memento's are > SHOUT > > > > CASE) > > > > > > > > > and parse the result on the flex side, or you could use > the > > > > trick > > > > > (hack) > > > > > > > > > that I use and build typed case preserving structs.
> > > > > > > > > The combination of transfer, coldspring, flex and > coldfusions > > > > > > > > > automagic conversion is very powerful and pretty straight > > > > forward. > > > > > Now if I > > > > > > > > > could just convince Mark to change the GetMementoWriter so > > > > that is > > > > > was case > > > > > > > > > preserving... (I've got a patch file ;-)
> > > > > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek <brian...@gmail.com> > > > > wrote:
> > > > > > > > > > Basically, queries and Transfer Objects are converted > into > > > > simple > > > > > > > > > > Value Objects (or arrays of Value Objects) via AOP. > These > > > > are > > > > > nothing but > > > > > > > > > > flat CFCs with properties in the THIS scope and > CFPROPERTY > > > > tags. > > > > > Flex can > > > > > > > > > > then be told to automatically convert the VO CFCs into > > > > > corresponding > > > > > > > > > > ActionScript VOs.
> > > > > > > > > > > I keep getting pressure from a fair few people on how > to > > > > do the > > > > > > > > > > > whole > > > > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > > > > Unfortunately, my Flex skills are far from developed, > so I > > > > don't > > > > > > > > > > > have > > > > > > > > > > > an answer to this question.
> > > > > > > > > > > For those of you who are developing with Flex and > > > > Transfer, can > > > > > > > > > > > you > > > > > > > > > > > give us a quick run down of how you go about doing it?
> > > > > > > > > > > I would really appreciate it, and hopefully we can all > > > > learn > > > > > > > > > > > something.
I don't have an readily available examples (besides client code), but Brian is much more eloquent than I, and his example like he says, is easily extended to use typed structs...
On Jan 28, 2008 11:36 AM, Kurt Wiersma <kwier...@gmail.com> wrote:
> I remember hearing about this feature or something similar for working > with LCDs in CF 8. I didn't realize you could use this method in CF 7 and CF > 8 while using the regular Flex remoting gateway.
> --Kurt
> On Jan 28, 2008 11:26 AM, Sean Corfield <seancorfi...@gmail.com> wrote:
> > I believe it was omitted from the 7.0 docs (but haven't checked) even > > tho' it did work in 7.0. > > I'm on my iPhone otherwise I'd check it.
> > On 1/27/08, Jon Messer <sylvan.mes...@gmail.com> wrote: > > > Wow, it didn't even occur to me to search if it was documented or not > > but > > > here you go
> > > thanks Sean, now I can feel all warm and fuzzy about my code...
> > > On Jan 27, 2008 9:11 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > > > Holy c*!p really? Because it really does boost performance a lot > > with > > > > large datasets. It would be great if it didn't feel like such a > > hack.
> > > > On Jan 27, 2008 9:07 PM, Sean Corfield <seancorfi...@gmail.com> > > wrote:
> > > > > I'm pretty sure it is documented and it was introduced for > > performance.
> > > > > On 1/27/08, Brian Kotek <brian...@gmail.com> wrote: > > > > > > While that is actually quite interesting, I definitely wouldn't > > build > > > > > > anything of importance on top of it since, as you noted, it is > > > > > undocumented > > > > > > and subject to change at any time. Simple Value Object CFCs are > > very > > > > > > inexpensive to create so I'll stick with that route.
> > > > > > On Jan 27, 2008 8:56 PM, Jon Messer <sylvan.mes...@gmail.com> > > wrote:
> > > > > > > Actually Brian I am talking about typed structs. Although I > > have > > > > > done and > > > > > > > do sometimes do what you are describing but what I mean by > > typed > > > > > struct is > > > > > > > this...
> > > > > > > Essentially if you add '__type__' key to your struct (not a > > cfc) > > > > > with a > > > > > > > value of "path.to.your.cfc" that matches the RemoteClass in AS > > then > > > > > yes > > > > > > > you get automatic conversion.
> > > > > > > This struct (s) will get converted to a FooVO in Flex, this > > works > > > > > > > recursively too so you can build typed stucts within typed > > structs > > > > > and get > > > > > > > composed vo's in Flex. Now "path.to.your.cfc" has to exist but > > it > > > > > doesn't > > > > > > > matter what is in it. I use "path.to.my.transfer.decorator" > > because > > > > > I have > > > > > > > those either way.
> > > > > > > I should be very clear here though, this is undocumented as > > far as I > > > > > can > > > > > > > tell. Also I wish I could remember where I read about the > > '__type__' > > > > > > > technique so that I could give credit, but I don't recall > > who's blog > > > > > I > > > > > > read > > > > > > > about it on.
> > > > > > > On Jan 27, 2008 5:45 PM, Brian Kotek <brian...@gmail.com> > > wrote:
> > > > > > > > His "typed structs" are Value Object CFCs, with all > > properties in > > > > > the > > > > > > > > THIS scope and all properties declared in CFPROPERTY tags. > > On the > > > > > Flex > > > > > > side, > > > > > > > > the ActionScript class defines the mapping with > > > > > [RemoteClass(alias=" > > > > > > > > com.foo.MyComponent")] and the conversion happens > > automatically.
> > > > > > > > On Jan 27, 2008 7:47 PM, Kurt Wiersma <kwier...@gmail.com> > > wrote:
> > > > > > > > > Do your "typed structs" automatically get converted into > > the > > > > > > > > > apprepriate AS object or do you have code on the AS side > > that > > > > > does > > > > > > that?
> > > > > > > > > I would be interested in see some example code of this > > process > > > > > if it > > > > > > > > > is something you can post.
> > > > > > > > > --Kurt
> > > > > > > > > On Jan 27, 2008 1:46 PM, Jon Messer < > > sylvan.mes...@gmail.com> > > > > > wrote:
> > > > > > > > > > I take essentially the same approach, there are a couple > > > > > > > > > > differences, one is when it comes when returning large > > sets > > > > > objects.
> > > > > > > > > > If you have an object that is composed of 5 other > > objects and > > > > > has 2 > > > > > > > > > > one to many arrays that have say 5 composed objects, > > even > > > > > returning > > > > > > 20 base > > > > > > > > > > objects will turn into several hundred objects which is > > VERY > > > > > > expensive to > > > > > > > > > > create in CF even on 8. In these situations I build > > > > > essentially > > > > > > typed > > > > > > > > > > structs on the cf side that map to vo's on the as side, > > using > > > > > this > > > > > > approach > > > > > > > > > > I can return literaly tens of thousands of composed > > objects in > > > > > > milliseconds, > > > > > > > > > > trying to return that many cfcs will crash your server.
> > > > > > > > > > Another challenge is: if you are going to use transfer > > > > > decorators to > > > > > > > > > > pass directly to flex, then you have to be careful > > because the > > > > > AMF > > > > > > CF CFC > > > > > > > > > > to AS VO converter (acronym much?) won't call the > > > > > getM2OObject() so > > > > > > composed > > > > > > > > > > objects won't be included. This is why you have to do a > > little > > > > > > messaging and > > > > > > > > > > build the VO like Brian says.
> > > > > > > > > > You could use AOP to insert the composed object into to > > the > > > > > transfer > > > > > > > > > > decorator before it gets returned, or you could use the > > > > > > > > > > to.getMemento() (I don't because transfer memento's are > > SHOUT > > > > > CASE) > > > > > > > > > > and parse the result on the flex side, or you could use > > the > > > > > trick > > > > > > (hack) > > > > > > > > > > that I use and build typed case preserving structs.
> > > > > > > > > > The combination of transfer, coldspring, flex and > > coldfusions > > > > > > > > > > automagic conversion is very powerful and pretty > > straight > > > > > forward. > > > > > > Now if I > > > > > > > > > > could just convince Mark to change the GetMementoWriter > > so > > > > > that is > > > > > > was case > > > > > > > > > > preserving... (I've got a patch file ;-)
> > > > > > > > > > On Jan 27, 2008 10:57 AM, Brian Kotek < > > brian...@gmail.com> > > > > > wrote:
> > > > > > > > > > > Basically, queries and Transfer Objects are converted > > into > > > > > simple > > > > > > > > > > > Value Objects (or arrays of Value Objects) via AOP. > > These > > > > > are > > > > > > nothing but > > > > > > > > > > > flat CFCs with properties in the THIS scope and > > CFPROPERTY > > > > > tags. > > > > > > Flex can > > > > > > > > > > > then be told to automatically convert the VO CFCs into > > > > > > corresponding > > > > > > > > > > > ActionScript VOs.
> > > > > > > > > > > > I keep getting pressure from a fair few people on > > how to > > > > > do the > > > > > > > > > > > > whole > > > > > > > > > > > > Flex -> Transfer and back again thing.
> > > > > > > > > > > > Unfortunately, my Flex skills are far from > > developed, so I > > > > > don't > > > > > > > > > > > > have > > > > > > > > > > > > an answer to this question.
> > > > > > > > > > > > For those of you who are developing with Flex and > > > > > Transfer, can > > > > > > > > > > > > you > > > > > > > > > > > > give us a quick run down of how you go about doing > > it?
> > > > > > > > > > > > I would really appreciate it, and hopefully we can > > all > > > > > learn > > > > > > > > > > > > something.
On Jan 28, 2008 3:24 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> I don't have an readily available examples (besides client code), but > Brian is much more eloquent than I, and his example like he says, is easily > extended to use typed structs...
Actually, I read Brian's blog entry a few days ago and downloaded the code, but haven't had a chance to work through it. (Thanks Brian.) And I didn't immediately identify it as applying directly to a Flex application, since it's an article on how to use ColdSpring AOP. But of course, the code sample creates Value Objects, doesn't it ...?
I'll study Brian's sample, and deal with the typed structs from there. Thanks very much, guys.
These seem to be the best options for the moment (as far as I can tell)
(A) Pushing CF based data -> Flex
1) Take query data, and convert it over to a typed struct as required. 2) Take a TransferObject (or array of them), and convert that over to a typed struct
(B) Pushing Flex VO data -> CF
1) Pushing a memento / struct back down to CF and (somehow?) pushing that data back onto a TransferObject and saving it.
The (A) side of pushing data from a query or from a TransferObject to Flex seems reasonably straight forward. Going the other way, and pulling it back down to Transfer could be a bit trickier, but not impossible.
Would that be correct?
Mark
On Jan 29, 2008 9:34 AM, Tom McNeer <tmcn...@gmail.com> wrote:
> On Jan 28, 2008 3:24 PM, Jon Messer <sylvan.mes...@gmail.com> wrote:
> > I don't have an readily available examples (besides client code), but > > Brian is much more eloquent than I, and his example like he says, is easily > > extended to use typed structs...
> Actually, I read Brian's blog entry a few days ago and downloaded the > code, but haven't had a chance to work through it. (Thanks Brian.) And I > didn't immediately identify it as applying directly to a Flex application, > since it's an article on how to use ColdSpring AOP. But of course, the code > sample creates Value Objects, doesn't it ...?
> I'll study Brian's sample, and deal with the typed structs from there. > Thanks very much, guys.
> -- > Thanks,
> Tom
> Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560
On Jan 29, 2008 7:45 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> These seem to be the best options for the moment (as far as I can tell)
> (A) Pushing CF based data -> Flex
> 1) Take query data, and convert it over to a typed struct as required. > 2) Take a TransferObject (or array of them), and convert that over to a > typed struct
Yep!
> (B) Pushing Flex VO data -> CF
> 1) Pushing a memento / struct back down to CF and (somehow?) pushing that > data back onto a TransferObject and saving it.
> The (A) side of pushing data from a query or from a TransferObject to Flex > seems reasonably straight forward. Going the other way, and pulling it back > down to Transfer could be a bit trickier, but not impossible.
> Would that be correct?
Sort of. Just to be sure everyone is on the same page, think of pushing data from Flex to CF as the same as pushing data from an HTML form to CF. Mark isn't falling into this "trap", but I've seen several other folks talk about pushing "objects" or ActionScript classes to CF from Flex. This isn't what happens. What happens is that, as Mark alludes, you move simple values or a struct of data (just like you would with the FORM scope) into your Model, and once there you do anything you want with it. So you'd populate a Transfer Object with Flex data the same way you'd populate a Transfer Object with data from an HTML form. I just wanted to make sure this was clear and that it made sense to everyone.
I agree with Brian, but would add that the data coming back from flex can be nested, unlike an HTML form.
So you can have structs with structs and arrays inside of other structs ad infinitum. It should still be treated as a simple data transfer object when you are dealing with transfer, so you will have to get that simple (possibly nested) data back into transfer objects using the transfer factory.
IF your cfc objects don't require a factory to create and have no real dependencies that need resolving then flex will create them for you form an AS VO, but that is a pretty anemic object and I would have to agree that more likely a better approach is to treat them like data transfer objects...
On Jan 29, 2008 5:36 AM, Brian Kotek <brian...@gmail.com> wrote:
> On Jan 29, 2008 7:45 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> > These seem to be the best options for the moment (as far as I can tell)
> > (A) Pushing CF based data -> Flex
> > 1) Take query data, and convert it over to a typed struct as required. > > 2) Take a TransferObject (or array of them), and convert that over to a > > typed struct
> Yep!
> > (B) Pushing Flex VO data -> CF
> > 1) Pushing a memento / struct back down to CF and (somehow?) pushing > > that data back onto a TransferObject and saving it.
> > The (A) side of pushing data from a query or from a TransferObject to > > Flex seems reasonably straight forward. Going the other way, and pulling it > > back down to Transfer could be a bit trickier, but not impossible.
> > Would that be correct?
> Sort of. Just to be sure everyone is on the same page, think of pushing > data from Flex to CF as the same as pushing data from an HTML form to CF. > Mark isn't falling into this "trap", but I've seen several other folks talk > about pushing "objects" or ActionScript classes to CF from Flex. This isn't > what happens. What happens is that, as Mark alludes, you move simple values > or a struct of data (just like you would with the FORM scope) into your > Model, and once there you do anything you want with it. So you'd populate a > Transfer Object with Flex data the same way you'd populate a Transfer Object > with data from an HTML form. I just wanted to make sure this was clear and > that it made sense to everyone.
|
