Smarter function calls

[neuroscr]

Thinking about this. Maybe AppDotNet class should be straight dumb calls and EZ should a smarter wrapper that makes the API easier to deal with. This would give the advantage if you already knew/want to the learn the ADN API you can use straight AppDotNet and anything specific to our upgrade would be in EZ.

This would revert the change to getFile and getFiles to make them 2 different web calls but then EZ would have a function that takes one or more IDs and be smarted enough to make the appropriate backend call.

[jdolitsky]

good call, we can keep down the size of the lib itself.

[jdolitsky]

@neuroscr suggesting something like this?

require_once 'AppDotNet.php';

$app = new AppDotNet($clientId,$clientSecret);

$user = $app->httpReq('get',$app->baseUrl.'users/'
                 .urlencode($userId).'?'.$app->buildQueryString($params));

[neuroscr]

Actually no, but that's an interesting thought too. We could refactor our authentication, session and IO calls from the AppDotNet, so we have 3 layers and the user can choose to use the library at any level they're comfortable with. Though personally, I'd use it with the function stubs (app->getUser instead of app->httpReq).

I wonder if we could use the app_scopes global to determine what parts of the library to load in. We could use polymorphism w/ an auto-loader or maybe some type of parser.

[ravisorg]

Normally I'm all for abstraction, but I want to jump in and warn against too much of it. If someone was looking to do tasks at a low enough level that they're specifying all the parameters for an http request, they probably won't be using this library, they'll just be using curl. And if they did for some reason want to use this library for this particular use case (eg: avoid doing the oauth stuff themselves) then they can still call httpReq (assuming it's public). I don't think it needs another layer. Just my 2c :)

[neuroscr]

@ravisorg Yea, that's very true. I don't see many users utilize just an IO, auth and session library unless they're already familiar with the API. I like the idea of making httpReq public, that would negate this use case completely without too much additional cost.

Though we still could have that 3rd layer if there was a need for a non-CURL IO library but that's something we can deal with later, as I don't think there is any demand for that yet.