Flex and Transfer Integration

[Mark Mandel]

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.

Mark

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

[Brian Kotek]

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.

[Jon Messer]

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 ;-)

[Mark Mandel]

Hey Jon,

Why is it such a big deal that the memento's are all in upper case?

Mark

[Brian Kotek]

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. ;-)

[Jon Messer]

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...

[Kurt Wiersma]

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

[Brian Kotek]

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.

[Jon Messer]

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.

[Mark Mandel]

Jon,

That is very interesting.

How do you go about bringing the VO data back to a Transfer Objects?

Mark

[Brian Kotek]

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.

[Jon Messer]

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.

[Sean Corfield]

I'm pretty sure it is documented and it was introduced for performance.

--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Jon Messer]

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.

[Jon Messer]

Wow, it didn't even occur to me to search if it was documented or not but here you go

http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=UseFlexDataService_05.html

thanks Sean, now I can feel all warm and fuzzy about my code...

[Brian Kotek]

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.

[Sean Corfield]

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.

[Tom McNeer]

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.



--
Thanks,

Tom

Tom McNeer
MediumCool
http://www.mediumcool.com
1735 Johnson Road NE
Atlanta, GA 30306
404.589.0560

[Brian Kotek]

On Jan 28, 2008 2:19 PM, Tom McNeer <tmc...@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-ColdSpring-Joy-Example-Files-for-AbstractMetadataAwareAdvice that 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).

Hopefully this helps.

[Kurt Wiersma]

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

[Jon Messer]

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...

[Tom McNeer]

On Jan 28, 2008 3:24 PM, Jon Messer <sylvan...@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.

[Mark Mandel]

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

[Brian Kotek]

On Jan 29, 2008 7:45 AM, Mark Mandel <mark....@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.

[Jon Messer]

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...

[Brian Kotek]

Unless you use my FormUtilities (http://formutils.riaforge.org/) which lets you pass structs with structs and arrays inside of structs ad infinitum. ;-)  But yes, the point is made. Again though, the take away is that you're just passing "data" back to the server. There is no automatic translation of AS classes into CFCs, etc.

[Jon Messer]

I just thought I'd share this, since I spent about an hour today trying to debug it while pulling my hair out. The frustrating part is that I have unit tests that cover both the Coldfusion gateway and the flex command class, but I wasn't testing the CFASSerializer.

I had been building typed structs essentially by hand, to squeezed every ounce of performance out of cf, but that solution was a little brittle and hard to maintain. So I built a more maintainable system, but in so doing I was setting values in the struct using associative array syntax on the cf query, ie :

vo['value']=query['#column#'];

you'd think this is all good, it works in cf, my unit tests passed, if you dump the struct you get the values you'd expect, it even works if you "fake" the remote call by invoking my remote proxy, but Coldfusion is just too smart for my own good.

I knew this in the back of my head, but the Coldfusion AS serializer will work with Java objects too, and query['column'] is actually a java object of type coldfusion.sql.QueryColumn, which gets deserialized as a comma separated list of ALL the column values from the underlying query on the AS side.

The fix is to use evaluate('query.#column#') or standard syntax query.column, so now I have to evaluate how much of a performance impact evaluate will have.

This is in fact very cool and desireable behavior on the part of CF, it allows you to serialize and de-serialize java objects using coldfusion as a service layer, but it's also something to be aware of since a lot of cf is actually java...

I hope this helps someone...

[Sean Corfield]

query[column] is a set of values. query[column][rownum] is a single
value. You do not need evaluate() here.

[Jon Messer]

I just realized that in my sleep. It looked like it was working because it was within a cfoutput on the query, but I needed to add query[column][currentrow]... which stupidly enough my older more fragile method was doing.

The strange thing for me, was the isDate(query[column]) on a column of type date returns true and all of my other test assertions worked, so clearly my unit test was not complete enough.

Still it was interesting to find that the deserializer works with java objects too...

[Gareth Arch]

Hi all,
I've been trying to get this working (on CFMX7), but have not been
successful. I began posting on CFTalk and was directed here to see if
someone else might have some insight (Jon Messer has been assisting
over there, but I still have not got it working yet).

Here's the link which should hopefully describe my problem in more
detail and has some debugging information.
http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:55258

If anyone knows what I could be doing wrong, please let me know. I'm
getting a little frustrated (as it supposedly *should* work, but has
not been). Thanks all.

[Jon Messer]

Just a follow up here.

I had thought that this worked on 7 as well, but I just re-tested it against a 7 server and I don't think it works without FDS or LCDS, just something to be aware of.

[Gareth Arch]

OK, as this seems to have been officially squelched for CFMX7 (just
using remoteObject calls), does anyone know if BlazeDS can also do
this or is it just via LiveCycle?
Thanks.

On Feb 21, 4:01 pm, "Jon Messer" <sylvan.mes...@gmail.com> wrote:
> Just a follow up here.
>
> I had thought that this worked on 7 as well, but I just re-tested it against
> a 7 server and I don't think it works without FDS or LCDS, just something to
> be aware of.
>

> On Mon, Jan 28, 2008 at 9:26 AM, Sean Corfield <seancorfi...@gmail.com>

[Kyle Hayes]

I am having issues with this process. My application will be returning
very large sets of data and I most certainly want to use the typed
struct method. However, when I set a breakpoint in the result()
function of my command class after receiving the data and it is still
an array of untyped objects.

As for now since I am returning the data from a query (which is
created from Transfer), I am keeping the ALLCAP keys for testing. In
addition, I have ensured that there is a CFC VO in the appropriate
location as well as an AS class in the same path. Finally, the AS
properties are all caps as well.

Can anyone possibly tell me what may be happening? If you need more
details just let me know.

Thanks!
-Kyle

[Jon Messer]

First, as Gareth and I found out, this only works on CF8.

Other than that you just have to make sure that your Actionscript VO has this above the class definition

    [RemoteClass(alias="your.cfc.vo.type")]

then add a key to your struct that matches

    myStruct['__type__'] = 'your.cfc.vo.type';

Coldfusion will take care of the rest. If you are returning an array you need to make sure that your actionscript VO is actually used somewhere otherwise it won't get compiled into your swf I do this by having a line like this somewhere

    // *** force compilation of the following classes
    private var _vos:Array = [MyVO];

Also one of the benefits of this other than speed is that "your.cfc.vo.type" doesn't have to exist on disk, so you don't have to create a whole new Value Object type of cfc.

Also as you noted the property case has to match.

[Kyle Hayes]

ARRGGGGHH...

 // *** force compilation of the following classes
    private var _vos:Array = [MyVO]; 

...was all I needed. Thanks Jon!

--
Kyle Hayes
kylehayes.info/blog
www.linkedin.com/in/kylehayes

"It's kind of fun to do the impossible." -Walt Disney

[Dan Wilson]

Jon is going to write this up on the ria.dzone.com site really soon. Maybe this will be the last push he needs to finish the article. I know it would help a lot of people out.



DW

--
"Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew."

Guillaume Apollinaire quotes

[Kyle Hayes]

Alright...now that I have the typed struct working in getting it over
to Flex my next step is turning a TransferObject into a typed struct.
My question is, let's say I have the generic situation of an Order
with Items. What is the best way to get that converted to a typed
struct so that both Order and the array of Items are typed structs? Is
this something that is accomplished in the decorator, or do I have to
create a recursive function inside my AOP converter class?

Thanks,
Kyle

On Apr 1, 8:02 am, "Dan Wilson" <sipac...@gmail.com> wrote:
> Jon is going to write this up on the ria.dzone.com site really soon. Maybe
> this will be the last push he needs to finish the article. I know it would
> help a lot of people out.
>
> DW
>
>
>
> On Tue, Apr 1, 2008 at 10:59 AM, Kyle Hayes <mrkyleha...@gmail.com> wrote:
> > ARRGGGGHH...
> >  // *** force compilation of the following classes
> >     private var _vos:Array = [MyVO];
>
> > ...was all I needed. Thanks Jon!
>

> > On Tue, Apr 1, 2008 at 7:50 AM, Jon Messer <sylvan.mes...@gmail.com>

> > wrote:
>
> > > First, as Gareth and I found out, this only works on CF8.
>
> > > Other than that you just have to make sure that your Actionscript VO has
> > > this above the class definition
>
> > >     [RemoteClass(alias="your.cfc.vo.type")]
>
> > > then add a key to your struct that matches
>
> > >     myStruct['__type__'] = 'your.cfc.vo.type';
>
> > > Coldfusion will take care of the rest. If you are returning an array you
> > > need to make sure that your actionscript VO is actually used somewhere
> > > otherwise it won't get compiled into your swf I do this by having a line
> > > like this somewhere
>
> > >     // *** force compilation of the following classes
> > >     private var _vos:Array = [MyVO];
>
> > > Also one of the benefits of this other than speed is that "
> > > your.cfc.vo.type" doesn't have to exist on disk, so you don't have to
> > > create a whole new Value Object type of cfc.
>
> > > Also as you noted the property case has to match.
>

> > > On Mon, Mar 31, 2008 at 7:54 PM, Kyle Hayes <mrkyleha...@gmail.com>

[Brian Kotek]

I'd do it in AOP since your business object really shouldn't have any knowledge of special Flex translation of its data.

[Kyle Hayes]

That's what I was thinking. Methinks a possible solution to this would be of course utilizing the metadataAdvice stuff and instead of passing the path to an actual vo, I could simply pass the path of the vo directory (e.g. com.hayes.project.vo) and in the advice, use the CF function getMetaData() to retrieve the "name" parameter and if it contains that VO path, then it knows to getMemento and set a __type__ attribute for all of it's included objects.

-Kyle

[Brian Kotek]

I don't like this for a few reasons. First, it assumes that all the properties and names in the ActionScript class matches exactly with the Transfer Object (and the database) which may often not be the case. It also uses getMemento(), which I don't like because it just pulls the raw instance data out of the TO, bypassing any Decorator logic in custom getters and leaving the TO as nothing but a dumb data container holding instance data.

Also, I'm not sure what you mean about using GetMetaData() or how this would help you resolve nested TOs. Given that Transfer uses method injection to create the getters and setters in the TO, GetMetaData() won't show you any of this. You could use StructKeyExists to look for matching properties or method names though.

You'll probably need to create a custom VOConverter and use that (assuming you're using my AbstractMetadataAwareAdvice and my VOConverterAdvice). You might be able to automate some of it but in many cases you may well need a custom converter.

[Kyle Hayes]

Indeed I am using a custom converter and got this solution to work. Please provide your comments that you mentioned to the parts of code that could be improved:

<!--- MetaData XML --->

<metadata>

<target name="TrendService"

vopath="com.hayes.trends.vo"

converter="flexTypedStructConverter" />

</metadata>

<!--- Custom converter to convert TOs to Typed Structs --->

<cffunction name="convert" access="public" returntype="any" output="false" hint="">

<cfargument name="data" type="any" required="true" />

<cfargument name="metadata" type="struct" required="true" />

<cfargument name="methodName" type="string" required="true" />

<cfset var local = StructNew() />

<cfset local.voArray = ArrayNew(1) />

<cfif getMetaData(arguments.data).name contains arguments.metadata.vopath>

<cfset local.obj = applyType(arguments.data, arguments.metadata.vopath) />

<cfreturn local.obj />

.......

.......

<cffunction name="applyType" access="private" returntype="any">

<cfargument name="obj" type="any" required="true" />

<cfargument name="vopath" type="string" required="true" />

<cfargument name="debugMe" type="any" required="false" default="0">

<cfset var local = structNew() />

<cfset local.md = getMetaData(arguments.obj) />

<cfset local.result = ""/>

<cfif local.md.name contains arguments.vopath>

<cfset local.result = arguments.obj.getMemento() />

<cfloop from="1" to="#arrayLen(local.md.properties)#" index="i">

<cfif local.md.properties[i].type eq 'array'>

<cfset local.arrayName = local.md.properties[i].name>

<cfset local.arrayProp = local.result[local.arrayName] />

<cfloop from="1" to="#arrayLen(local.arrayProp)#" index="k">

<cfset local.result[local.arrayName][k] = applyType(evaluate('arguments.obj.get#local.arrayName#(k)'), arguments.vopath, 1) />

</cfloop>

</cfif>

</cfloop>

</cfif>

<cfset local.result["__type__"] = local.md.name>

<cfreturn local.result />

</cffunction>

[Kyle Hayes]

It seems since I replied to your message via email, it removed all the
tabs.

> > On Tue, Apr 1, 2008 at 12:20 PM, Kyle Hayes <mrkyleha...@gmail.com> wrote:
>
> > > That's what I was thinking. Methinks a possible solution to this would
> > > be of course utilizing the metadataAdvice stuff and instead of passing the
> > > path to an actual vo, I could simply pass the path of the vo directory (
> > > e.g. com.hayes.project.vo) and in the advice, use the CF function
> > > getMetaData() to retrieve the "name" parameter and if it contains that VO
> > > path, then it knows to getMemento and set a __type__ attribute for all of
> > > it's included objects.
> > > -Kyle
>

> > > On Tue, Apr 1, 2008 at 9:13 AM, Brian Kotek <brian...@gmail.com> wrote:
>
> > > > I'd do it in AOP since your business object really shouldn't have any
> > > > knowledge of special Flex translation of its data.
>

> > > > On Tue, Apr 1, 2008 at 11:42 AM, Kyle Hayes <mrkyleha...@gmail.com>

[Brian Kotek]

A few comments.

• GetMetaData() can be slow and this could potentially call it a lot.
• getMemento returns a struct of instance data from the Transfer Object which bypasses any logic in your getters.
• I'm not sure where the Properties key of your metadata is coming from, unless you are manually adding cfproperty tags to your Decorator?
• getMemento() will return the keys in all upper case, which means your ActionScript class would need to force all uppercase (or though a remoting option if I recall, all lowercase) property names.
• Case sensitivity may also apply to using the metadata name as the type value since ActionScript class names are also case-sensitive.
  
• Don't use Evaluate() ;-)
  

[Kyle Hayes]

Great comments. Thank you.

Enlighten me, what is a better way of doing something like this? How would you approach it?

[Brian Kotek]

Sure. You can get the name of the component by using transferObject.getClassName() to avoid the GetMetaData() calls. You could use a StructKeyList on getMemento() to give you the names of the properties and call their corresponding getters using cfinvoke to make sure you aren't bypassing logic in the getters. And to properly set the case of the properties in the outgoing value object you can define them in the Advice metadata for that method if you don't want to force all upper or lowercase property names on your ActionScript classes.

[Mark Mandel]

You can also use Transfer.getMetaData()...

Mark

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

[Kyle Hayes]

Oh I see. All makes sense, definitely! So the methodology I had was on the right track, just execution could be different?

[Kyle Hayes]

Hmm, I tried that and I kept getting an undefined function. And Brian,
after trying getClassName() I realized that it is not what I want.
That gives me the transfer class name, not the decorator class name.

On Apr 1, 2:10 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> You can also use Transfer.getMetaData()...
>
> Mark
>

> On Wed, Apr 2, 2008 at 8:08 AM, Brian Kotek <brian...@gmail.com> wrote:
> > Sure. You can get the name of the component by using
> > transferObject.getClassName() to avoid the GetMetaData() calls. You could
> > use a StructKeyList on getMemento() to give you the names of the properties
> > and call their corresponding getters using cfinvoke to make sure you aren't
> > bypassing logic in the getters. And to properly set the case of the
> > properties in the outgoing value object you can define them in the Advice
> > metadata for that method if you don't want to force all upper or lowercase
> > property names on your ActionScript classes.
>

> > On Tue, Apr 1, 2008 at 3:58 PM, Kyle Hayes <mrkyleha...@gmail.com> wrote:
> > > Great comments. Thank you.
>
> > > Enlighten me, what is a better way of doing something like this? How would
> > you approach it?
>

> > > On Tue, Apr 1, 2008 at 12:51 PM, Brian Kotek <brian...@gmail.com> wrote:
>
> > > > A few comments.
>
> > > > GetMetaData() can be slow and this could potentially call it a lot.
> > > > getMemento returns a struct of instance data from the Transfer Object
> > which bypasses any logic in your getters.
> > > > I'm not sure where the Properties key of your metadata is coming from,
> > unless you are manually adding cfproperty tags to your Decorator?
> > > > getMemento() will return the keys in all upper case, which means your
> > ActionScript class would need to force all uppercase (or though a remoting
> > option if I recall, all lowercase) property names.
> > > > Case sensitivity may also apply to using the metadata name as the type
> > value since ActionScript class names are also case-sensitive.
>
> > > > Don't use Evaluate() ;-)
>

> > > > On Tue, Apr 1, 2008 at 1:31 PM, Kyle Hayes <mrkyleha...@gmail.com>

> > > > > On Tue, Apr 1, 2008 at 10:03 AM, Brian Kotek <brian...@gmail.com>

> > wrote:
>
> > > > > > I don't like this for a few reasons. First, it assumes that all the
> > properties and names in the ActionScript class matches exactly with the
> > Transfer Object (and the database) which may often not be the case. It also
> > uses getMemento(), which I don't like because it just pulls the raw instance
> > data out of the TO, bypassing any Decorator logic in custom getters and
> > leaving the TO as nothing but a dumb data container holding instance data.
>
> > > > > > Also, I'm not sure what you mean about using GetMetaData() or how
> > this would help you resolve nested TOs. Given that Transfer uses method
> > injection to create the getters and setters in the TO, GetMetaData() won't
> > show you any of this. You could use StructKeyExists to look for matching
> > properties or method names though.
>
> > > > > > You'll probably need to create a custom VOConverter and use that
> > (assuming you're using my AbstractMetadataAwareAdvice and my
> > VOConverterAdvice). You might be able to automate some of it but in many
> > cases you may well need a custom converter.
>

> > > > > > On Tue, Apr 1, 2008 at 12:20 PM, Kyle Hayes <mrkyleha...@gmail.com>

> > wrote:
>
> > > > > > > That's what I was thinking. Methinks a possible solution to this
> > would be of course utilizing the metadataAdvice stuff and instead of passing
> > the path to an actual vo, I could simply pass the path of the vo directory
> > (e.g. com.hayes.project.vo) and in the advice, use the CF function
> > getMetaData() to retrieve the "name" parameter and if it contains that VO
> > path, then it knows to getMemento and set a __type__ attribute for all of
> > it's included objects.
>
> > > > > > > -Kyle
>

> > > > > > > On Tue, Apr 1, 2008 at 9:13 AM, Brian Kotek <brian...@gmail.com>

> ...
>
> read more »

[Mark Mandel]

Oh it's getTransferMetaData.. I guess I should read my own docs sometimes.

Mark

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

[Brian Kotek]

My Decorators are just about always named the same as the underlying TO, but if you need to you can always override the method in your Decorator so that it gives you the correct name.

[Mark Mandel]

* cough *

http://www.transfer-orm.com/transfer/documentation/cfcdoc/contentfb32.html

* cough *

Mark

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

[Kyle Hayes]

Heh, are you pointing out that it is not to be over-written? If so,
how else can I get the path of the vo?

On Apr 1, 8:43 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> * cough *
>
> http://www.transfer-orm.com/transfer/documentation/cfcdoc/contentfb32...

>
> * cough *
>
> Mark
>
>
>
> On Wed, Apr 2, 2008 at 2:41 PM, Brian Kotek <brian...@gmail.com> wrote:
> > My Decorators are just about always named the same as the underlying TO, but
> > if you need to you can always override the method in your Decorator so that
> > it gives you the correct name.
>

> E: mark.man...@gmail.com
> W:www.compoundtheory.com

[Mark Mandel]

Nothing stopping you using getMetaData to get from the decorator...
getMetaData isn't that slow, it's cached after the first execution.

Brian - your experience with getMetaData is different?

Mark

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

[Kyle Hayes]

Hmm, I restarted my computer for other reasons and I get the following error when initializing code that worked before:
The XML Provided in 'C:\var\wwwroot\trends\config\transfer.xml' is not valid against its XML Schema:[Error] :71:45: cvc-complex-type.2.4.a: Invalid content was found starting with element 'onetomany'. One of '{"":manytomany, "":function}' is expected. [Error] :105:44: cvc-complex-type.2.4.a: Invalid content was found starting with element 'manytoone'. One of '{"":onetomany, "":manytomany, "":function}' is expected.

[Kyle Hayes]

Well, I changed around the order of my relationships and I am not getting that error anymore but now I am getting a different one:

Error while attempting to autowire object of type transfer.com.sql.transaction.TransactionManager:
[Line: 210 :: C:\var\wwwroot\trends\transfer\com\factory\AbstractBaseFactory.cfc :: Error while attempting to autowire object of type transfer.com.sql.transaction.Transaction ::
[Line: 210 :: C:\var\wwwroot\trends\transfer\com\factory\AbstractBaseFactory.cfc :: Error while attempting to autowire object of type transfer.com.sql.transaction.TransactionEventPool ::
[Line: 93 :: C:\var\wwwroot\trends\transfer\com\util\javaloader\JavaLoader.cfc :: org.apache.commons.collections.BufferUtils :: ]]]

This is all very strange as it was working fine before I rebooted.

[Mark Mandel]

With the latest XSD, I made it so you could write it in any order.

What version are you running? Almost sounds like you have more than
one codebase around...

Mark

[Kyle Hayes]

I was running 0.6.3, but then I ran BER just to see if that would fix it, but it didn't.

[Mark Mandel]

Sounds like you messed up your install.

You follow the upgrade guide?

Mark

[Kyle Hayes]

Uh oh. I guess that is why I am on this list, because I am so new to Transfer and learning all of the ins and outs :-\

[Kyle Hayes]

Hmm, everything is working now :-\

[Brian Kotek]

Heh, fair enough. Since I never do this or need to, I was just throwing out suggestions. Thanks.

[Brian Kotek]

I believe it is cached per class instance.

However, GetMetaData() on the Decorator isn't going to show you any of the injected methods, correct?

[Kyle Hayes]

I believe you are correct, Brian, however, I am not using it for that. I believe I am really using it to get the full decorator class name (com.hayes.project.cfc etc). Come to think of it though, I suppose since I am using a decorator I could just put another method in each of them that returns their cfc path as a string rather than bringing getMetaData() into the picture. Especially since this particular operation is going to be looped over rather heavily.

[Brian Kotek]

I tend to organize my model by the type of object, such as factories, business, vo, utility, etc. So in my environment variables (which are based on host name mainly) I can define the path to something like my business objects (Decorators) and easily determine the full package path as a combination of getClassName() and the environment variable defining the package path to my business objects.

Incidentally I'm also using these environment variables to dynamically generate my ColdSpring XML so that I don't have hardcoded package paths in my ColdSpring config.

[Kyle Hayes]

That makes sense. I have a very similar setup, although I am not defining those paths in environment variables. I suppose it would be a difficult thing to incorporate. I wil have to consider that. In the meantime,  is having a method like so:
    <cffunction name="getCFCPath" acccess="public" returntype="string" output="false">
        <cfreturn "com.hayes.trends.vo.Term" />
    </cffunction>

Considered bad form for the decorator?

[Brian Kotek]

I wouldn't say it is "bad form" to have such a method, but I'm not sure I'd say it's the best idea since you have to go change actual code any time you want to change this value, and you'll have to manually add it to every Decorator to be able to use it reliably, otherwise you won't know which Decorators have it and which don't. It also means you must decorate everything since normal TOs won't have this method. I decorate everything by convention so it may not matter but just pointing it out.

Basically, I'd consider using some applicaiton-wide settings to control this instead of manually hardcoding it in every Decorator, unless the path to your Decorators is different across Decorators (which may well be the case). In that case you have to decide which is better, but I'd still say some application-wide settings would be better than hardcoding it in the Decorators.

BTW I'm using a heavily customized version of this to handle my environment variables and ColdSpring properties: http://environmentconfig.riaforge.org/

[Jon Messer]

I agree with pretty much every thing Brian has said, although for single transfer objects I don't go the AOP route (I do usually for arrays from queries).

I define a decorator for every transfer object, even if it does virtually nothing. In those decorators (or the base class they extend) I'll define a getVO() method that will build a typed struct by looping over properties and collections and calling their getters. The type of the struct will match the decorator path as defined in the transfer.xml. (this is one thing I go back and forth on is whether to have my 'typed' VOs for remote consumption be a different non-existent on disk class)

I originally was doing this same thing, but with getMemento() (after a patch to getMementoWriter to make it preserve case), but later decided to go the custom getVO() route, largely for the reasons Brian laid out (it doesn't circumvent the custom getters).

Most of my getVO()s will also setup something specific and convenient for the flex consumption side, depending on if I want a straight copy of the server side TO or something more aggregated, extra or different.

[Brian Kotek]

Out of curiosity, how do you handle the fact that the TO properties are all uppercase? Do you just have all uppercase properties in your corresponding AS3 classes?

[Jon Messer]

the afor mentioned patches to transfer... I know it's frowned on but I haven't made the effort to come up with custom meta data type solution yet.

[Brian Kotek]

Ah sorry I missed that in your original message. I emailed Mark about it since it looks like it would be a fairly simple change that would have a lot of benefits.

[Jon Messer]

I basically went through transfer and made all struct syntax associative array instead of ., which shouldn't (doesn't) affect CF code since it's not case sensitive, but makes AS life a lot nicer. I posted a request to the list last year to see if we could make the changes and no-one responded so I just went ahead with my patches. Maybe we should request it again of the list?

Mark said he didn't care but didn't want to break existing code the expected SHOUTCASE (like bender)...

[Brian Kotek]

I would think that Bender would be updated since supporting case-sensitive property names is pretty much a required piece of any CFC to Flex translation. No self-respecting Flex programmer is going to use all uppercase or lowercase property names just because of CF.

Also, having a look at Bender, I'm not sure how it would fit into something like Cairngrom which uses Delegates for all communication with the server. I'll have to poke around at it.

[Jon Messer]

I evaluated bender and based on the CASE thing, and a couple others (the get/set memento in the VO, the fact that the VOs had responders in them and that it doesn't work out of the box) I decided not to use it.

Although with some modifications I got the CF part to work, and just for evaluation I integrated it into an existing cairngorm flex app I had. But I didn't use the flex/as part of it at all, just the bender.cfc to handle the remote save and delete. It's interesting and has potential, but I preferred how I was doing it.

I totally agree about the case thing, that's why I don't think changing transfer would break anything, I'd hope people integrating transfer with flex would have already dealt with the case issue somehow and not have developed Actionscript VO.SHOUTPROPERTY type stuff...

[Kyle Hayes]

I also don't see it being much of an issue due to the shear fact that there are probably not a whole lot of developers using Transfer + Flex.

[Jon Messer]

Heresy!  We are legion!

[Kyle Hayes]

Jon,

How do you handle the "getVO()" method if your CFC has a one-to-many
relationship with another?

On Apr 2, 6:39 am, "Jon Messer" <sylvan.mes...@gmail.com> wrote:
> I agree with pretty much every thing Brian has said, although for single
> transfer objects I don't go the AOP route (I do usually for arrays from
> queries).
>
> I define a decorator for every transfer object, even if it does virtually
> nothing. In those decorators (or the base class they extend) I'll define a
> getVO() method that will build a typed struct by looping over properties and
> collections and calling their getters. The type of the struct will match the
> decorator path as defined in the transfer.xml. (this is one thing I go back
> and forth on is whether to have my 'typed' VOs for remote consumption be a
> different non-existent on disk class)
>
> I originally was doing this same thing, but with getMemento() (after a patch
> to getMementoWriter to make it preserve case), but later decided to go the
> custom getVO() route, largely for the reasons Brian laid out (it doesn't
> circumvent the custom getters).
>
> Most of my getVO()s will also setup something specific and convenient for
> the flex consumption side, depending on if I want a straight copy of the
> server side TO or something more aggregated, extra or different.
>

> On Wed, Apr 2, 2008 at 5:53 AM, Brian Kotek <brian...@gmail.com> wrote:
> > I wouldn't say it is "bad form" to have such a method, but I'm not sure
> > I'd say it's the best idea since you have to go change actual code any time
> > you want to change this value, and you'll have to manually add it to every
> > Decorator to be able to use it reliably, otherwise you won't know which
> > Decorators have it and which don't. It also means you must decorate
> > everything since normal TOs won't have this method. I decorate everything by
> > convention so it may not matter but just pointing it out.
>
> > Basically, I'd consider using some applicaiton-wide settings to control
> > this instead of manually hardcoding it in every Decorator, unless the path
> > to your Decorators is different across Decorators (which may well be the
> > case). In that case you have to decide which is better, but I'd still say
> > some application-wide settings would be better than hardcoding it in the
> > Decorators.
>
> > BTW I'm using a heavily customized version of this to handle my
> > environment variables and ColdSpring properties:
> >http://environmentconfig.riaforge.org/
>

> > On Wed, Apr 2, 2008 at 8:40 AM, Kyle Hayes <mrkyleha...@gmail.com> wrote:
>
> > > That makes sense. I have a very similar setup, although I am not
> > > defining those paths in environment variables. I suppose it would be a
> > > difficult thing to incorporate. I wil have to consider that. In the
> > > meantime,  is having a method like so:
> > >     <cffunction name="getCFCPath" acccess="public" returntype="string"
> > > output="false">
> > >         <cfreturn "com.hayes.trends.vo.Term" />
> > >     </cffunction>
>
> > > Considered bad form for the decorator?
>

> > > On Wed, Apr 2, 2008 at 5:34 AM, Brian Kotek <brian...@gmail.com> wrote:
>
> > > > I tend to organize my model by the type of object, such as factories,
> > > > business, vo, utility, etc. So in my environment variables (which are based
> > > > on host name mainly) I can define the path to something like my business
> > > > objects (Decorators) and easily determine the full package path as a
> > > > combination of getClassName() and the environment variable defining the
> > > > package path to my business objects.
>
> > > > Incidentally I'm also using these environment variables to dynamically
> > > > generate my ColdSpring XML so that I don't have hardcoded package paths in
> > > > my ColdSpring config.
>

> > > > On Wed, Apr 2, 2008 at 8:29 AM, Kyle Hayes <mrkyleha...@gmail.com>

> > > > wrote:
>
> > > > > I believe you are correct, Brian, however, I am not using it for
> > > > > that. I believe I am really using it to get the full decorator class name
> > > > > (com.hayes.project.cfc etc). Come to think of it though, I suppose since I
> > > > > am using a decorator I could just put another method in each of them that
> > > > > returns their cfc path as a string rather than bringing getMetaData() into
> > > > > the picture. Especially since this particular operation is going to be
> > > > > looped over rather heavily.
>

> > > > > On Wed, Apr 2, 2008 at 5:04 AM, Brian Kotek <brian...@gmail.com>

[Jon Messer]

All of my transfer objects have getVO implemented, so I'll get the collections iterator and build arrays (or structs) of the child VOs recursivly. So if objectA has many objectB in objectA.getVO i will iterate over the objectBArray and call objectB.getVO()...

so in the end you have a fully populated value object (or not if you want to lazy load, but for flex VOs I tend to send the whole shebang)

[Kyle Hayes]

Actually that was my next question about lazy-loading. Hmm, I still haven't decided what I will be doing for sure.