configureTransformer returns double-optional content about siesta

[pcantrell]

ObjectMapper seems like such a natural partner for Siesta, I’ve heard people talk about it — but I haven’t used it myself, and don’t know of any example code.

Could your problem be as simple as missing parens?

configureTransformer("/profile/") {
    Mapper<User>().map($0.content as JSON)
}

Also, it’s not clear to me that ObjectMapper works with SwiftyJSON — but you should be able to pass it a raw dict as parsed by Siesta:

configureTransformer("/profile/") {
    Mapper<User>().map($0.jsonDict)
}

[andrewloyola]

Ah, yes the parens definitely needed to be added, but does not fix the problem. Unfortunately removing the global SwiftyJSON transformer and instead using the raw jsonDict seems to have the same problem too. Investigations ongoing...

[andrewloyola]

Some progress!

  configureTransformer("/profile/") {
        Mapper<User>().map($0.content as Dictionary)
    }

this is close! , but now I'm having trouble grabbing the data from the resource in the closure. currently using this, which does not work.:

            if let user: User = resource.typedContent() {
                self?.refreshText(user)
            }

or this:

            if let user = resource.latestData?.content as? User {
                self?.refreshText(user)
            }

refresh text is never called in either case, but I do see the below in the debugger, so I know that the object is in there somewhere...

is there a good way to get at it?

[andrewloyola]

ok this seems to fully work for accessing the data. it seems like one too many unwraps, but since resource.latestData.content ends up as a User? from the transformer, I ended up with this:

            if let optionalUser: User? = resource.typedContent() {
                if let user = optionalUser {
                    self?.refreshText(user)
                }                    
            }

for reference from the previous posts, this was the ObjectMapper call that worked in configureTransformer:

configureTransformer("/profile/") {
      Mapper<User>().map($0.content as Dictionary)
  }

[pcantrell]

Ah, yes, welcome to the wonderful world of Swift’s type inference: 80% awesome, 20% wat?! Anyway, glad you figured it out.

I’m puzzled that this didn’t compile:

if let user: User = resource.typedContent() {

It works for me when I try to construct a parallel case. I’m wondering … does this compile for you?

if let user = resource.typedContent() as User? {

What about this one (even though it obviously always returns nil)?

if let text: String = resource.typedContent() {

[andrewloyola]

Sorry! I should have been more clear, all of your examples do indeed compile, but none of them succeed in unwrapping at runtime.

I think the second one:

if let user = resource.typedContent() as User? {

should work, based on what I see in the debugger, but it fails to unwrap like the others.

[pcantrell]

Hmm, looking a little closer at the ObjectMapper API, I think Siesta is giving you content of type User??. Yuck.

Would you mind running this check to verify the theory?

print("--------->", resource.latestData?.content.dynamicType)

If you see Optional(Swift.Optional<MyProject.User>), then bingo.

(Minor aside: it’s both legal and idiomatic Swift to say if let user = user. The non-optional one shadows the optional one within the if’s body, so you don’t have to define a separate optionalUser.)

[andrewloyola]

Yup, with that print()

---------> Optional(Swift.Optional<SwiftAPI.User>)

also, appreciate the tip on optionalUser.

[pcantrell]

OK, thanks! I think that’s something I can address in Siesta. I’ll send you a fix on a branch to test when I’ve had a chance to sit down with it.

[andrewloyola]

thanks, looking forward to it!

[pcantrell]

I think I’ve fixed this on master. Give it a whirl if you get a chance, and let me know if you’re still getting the double optional!

[andrewloyola]

Confirmed as fixed, sorry for the delay. much appreciated @pcantrell

---------> Optional(SwiftAPI.User)

[pcantrell]

No worries. Thanks for verifying!

[andrewloyola]

@pcantrell just curious, any plans to properly add a release with this change?

[pcantrell]

It will be in the next beta for sure, though Siesta work is on hold for a couple of weeks for the start of the semester.

[andrewloyola]

got it. thanks!

[o15a3d4l11s2]

Is this change included in the latest released version?

[pcantrell]

@o15a3d4l11s2 No, you’ll have to use master for now.

[yehe01]

@pcantrell Hi,
This fix has not been merged to V1.0 right?
Which installation method should I follow to use master branch?
I am using cocoapod.
Thanks.

[o15a3d4l11s2]

@yehe01, if using Cocoapods, you could set the pod as
pod 'Siesta', :git=>'https://github.com/bustoutsolutions/siesta'
This will make Cocoapods use the master branch.

[pcantrell]

This was merged and released over a year ago. If you’re having trouble with double optionals, please file a new issue with a reproducible test case.