Hi Douglas,
First, thanks so much for helping. This is really the same issue I threw out
last week, which you tried to help with.
My supposition that it was an object translation issue was correct. But I
wouldn't have solved it without you.
A few specifics here, just to show what the problem was, since this could
bite someone else.
First, the ArrayCollection/Array mismatch you pointed out was just my own
dumbness -- although in the end, I needed your ingenious custom
accessor/mutator solution to work it out.
See, the configAC was always an ArrayCollection in Estimate.as because I
never intended to have an estimate.cfc.
I worked happily through the whole app, stuffing nested objects into that
AC. But when I sent the Estimate object back down the line, CF tried to tell
me that the parameter wasn't supplied. And this was with a saveEstimate()
method that accepted one argument - estimate - with a type of "any" for
testing.
Creating the getEstimate() was just a test to see if object translation was
the problem -- and it was. Once I set up Estimate.as according to your blog
entry, getEstimate() worked fine. The Estimate object was recognized
correctly.
Better yet, when I sent the Estimate back to CF, it was accepted.
So here's the tip, for anyone with CFC/VO issues: I was originally trying to
send an untyped object back to CF. My understanding (although it could be
wrong) is that the untyped object should be handled by CF as a struct. I
haven't had a chance to actually test that yet.
But here's what I *think* was happening; since the untyped object contained
some *typed* objects that CF recognized (the configAC has nested objects
with CFC counterparts), CF threw up. It expected any object *containing* a
typed object to *be* a typed object.
At least, that's what I was guessing. And it appears to be true. Because
once there was an estimate.cfc (and I got the Array/ArrayCollection thing
straightened out), the "parameter" error went away. Whew!!
So - problem solved. Great thanks to you.
A couple of other things, since you mention it's been a while since you
worked much with CF: you don't have to have getters/setters in the CFC. As
long as you have property definitions that match the structure of the AS
class, it'll work.
And one question: you say that the following code will only return a generic
Object in Flex:
> > <cffunction name="getEstimate" access="remote" output="false"
> > returntype="any">
> > <cfset var estimate = structNew()/>
> > <cfset estimate['__type__'] = "meridien.model.estimate">
> > <cfset estimate['estimateID'] = 1 />
> > <cfset estimate['order'] =
> > createObject("component","meridien.model.products.order") />
> > <cfset estimate['customer'] =
> > createObject("component","meridien.model.customer.customer") />
> > <cfset estimate['configAC'] = arrayNew(1) />
> > <cfreturn estimate />
> > </cffunction>
> > =============================
>
Did you say that because of the "typed struct" I was creating, or because of
an error in the code itself? If it's the former, the method does work, and
is pretty handy. Flex will recognize the __type__ as the name of the CFC and
match it to the AS class. According to what I'm told (but have not tested),
the CFC needs to exist -- but doesn't even need to have the right structure.
Only the struct being sent to Flex has to be correct.
It's pretty handy in working with situations where the "real" objects can't
necessarily match. For instance, it's being used a lot by folks who use Mark
Mandel's Transfer ORM with CF. The "real" object on the CF side may be a
Transfer Decorator -- which can be a rich business object, in addition to
wrapping the database record in the base Transfer object. So you can pull
the data from the Decorator into a typed struct and have it identified
correctly on the Flex side. Then when it comes back, the data can flow into
the Decorator.
On the other hand, if you already know all that, and were just referring to
something stupid in my code, I apologize for being pedantic. And I hope
you'll tell me what I did wrong.
Anyway -- thanks again for straightening me out. I hope to be able to get to
your presentation next week, but it's not looking good at the moment.
I really appreciate all your help.
--
Thanks,
Tom
Tom McNeer
MediumCool
http://www.mediumcool.com
1735 Johnson Road NE
Atlanta, GA 30306
404.589.0560
