After doing the database schema yesterday, I tweaked it a bit today to fix a few things and then set about adjusting the user creation functionality I worked on last week to work with it. This involved changing the createUser PHP function, the SOAP server, and the Flex code. Then I hit a snag.
As part of that last step, I updated the SOAP service in Flex Builder so it could adjust its generated code. I noticed that something truly bizarre happened: Flex re-ordered the arguments to the createUser function in what appears to be a completely random order. It seemed odd, but I figured, whatever, it really doesn’t matter what order the Flex code wants them in as long as they get sent correctly. Well it turns out that they don’t get sent correctly. Using the order that the generated code specifies fails epically, while using the order that the SOAP server specifies them in works perfectly.
I have no idea why this occurs. Nobody else seems to either; in fact, almost nobody else even appears to have encountered this problem! The only references to the situation I could find on Google are here and here. It occurs to me that the problem could be in the way NuSOAP generates the WSDL file; one of the pages I linked to said they were using the NuSOAP library, the other didn’t say what their web service was written in. In any case, this isn’t a deal-breaker and probably isn’t worth expending a lot of effort looking into, but it is damn annoying.
Something else that is also annoying is that for some reason the form alignment on the “Create User” page of the Flex app is messed up. Again, no idea why and not something worth spending a lot of time looking into (for now at least) since the form works fine. What is particularly curious is that if you switch back to the base state and then back to the newUser state, the misalignment disappears. Will start a bug tracker on SourceForge to note these things.
EDIT: Bug tracker is up and our inaugural bugs are added!
This *is* quite annoying! I had the same problem, and my web service is also NuSOAP based.
I was able to “solve” the problem by hand-editing the BaseXXX.as file to put the parameters back in the correct order. (Of course, if I need to regen for some reason, I’ll need to re-edit, I’m sure.) While I was in there, I also noticed that the response values are munged as well, but I haven’t yet seen that cause an issue.
I wonder if Adobe has any intention of fixing this?!?
Thanks for this post, it was helpful to see that it wasn’t just my imagination!
I ended up solving the problem by switching to document/literal encoding and use instead of the default RPC/encoded. This is theoretically the best solution anyway because document/literal is WS-I compliant, whereas RPC/encoded is not.
Further discussion in my “WSDL Hell” post here:
http://captainrichard.wordpress.com/2009/09/15/wsdl-hell/
Pingback: Flex Sucks: Greatest Hits! « CaptainRichard's Blog