good to hear things are better and working there Tom. No I didn't
know about __type__, interesting, thanks for the info.
cheers!
DK
On Fri, Jul 18, 2008 at 10:41 AM, Tom McNeer <[EMAIL PROTECTED]> wrote:
> 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
>
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
