More complex parameters structure

[iosware]

I tried to use this great example to work with some Wordpress plugins.

But there can be situations when POST parameters should generate certain JSON structure.
E.g.
{ "title":"aaa", "post":23, "seo": { "keywords":"bmw,audi", "rating":"10", "optimize":"true" } }

Current approach to use enums won't work to generate such structure.
public enum basicParameters: EVAssociated { case title(String) case post(Number) case seo([seoParameters]) } public enum seoParameters: EVAssociated { case keywords(String) case rating(Number) case optimize(Bool) }
So possibly I'm doing it wrong though I didn't want to change anything in "EVWordPressAPI".
I would appreciate if you can suggest correct way to generate required JSON structure as it will allow to use "EVWordPressAPI" with some plugins too.

[evermeer]

I have chosen the enum approach as a standard for the API. It's not that difficult to create a call that accepts an object instead of an enum and then use the json of that object instead of the enum. Which API call(s) accept an object instead of a parameter list?

[iosware]

@evermeer
It is custom Worpress plugin which accepts object as parameter. So as I understand genericCall should be changed in EVWordPressAPI to accept object in parameter. But won't it require changing current parameters as enums approach including WordPressRequestConvertible where parameters are parsed?

Alamofire does allow it using JSON-Encoded Parameters but EVWordPressAPI accepts only enums as parameters.

[evermeer]

Ah, but it would not be that hard to implement a notGenericCall function based on the existing code. The genericCall code looks like this:

    internal func genericCall<T:WPObject, P>(_ path:String, parameters:[P]?, completionHandler: @escaping (T?) -> Void) where P: EVAssociated {
        Alamofire.request(self.wordpressOauth2Settings.baseURL + path, parameters: Dictionary<String,AnyObject>(associated: parameters))
        .responseObject(completionHandler: {  (result:DataResponse<T>) -> Void in
            self.handleResponse(result, completionHandler: completionHandler)
        })
    }

I even think this is all that it takes.

    internal func noneGenericCall<T:WPObject>(_ path:String, parameters:[String:AnyObject]?, completionHandler: @escaping (T?) -> Void)  {
        Alamofire.request(self.wordpressOauth2Settings.baseURL + path, parameters:  parameters)
        .responseObject(completionHandler: {  (result:DataResponse<T>) -> Void in
            self.handleResponse(result, completionHandler: completionHandler)
        })
    }

Maybe I can do some tests this weekend and add it to EVWordpressAPI

[iosware]

Excellent - new method can solve such issue.