Create v2.0 of the library

[typhonius]

…oint classes.

[coveralls]

Coverage increased (+1.7%) to 98.886% when pulling ca41b97 on 2.0 into 23fcc10 on master.

[typhonius]

@eporama @q0rban @timmillwood I know that you have been fairly active in this library. It'd be great to get some views from yourselves on this approach as it attempts to reduce the amount of code in each class (rather than having one mega client class we can use individual ones for each endpoint).

This would be a completely API breaking change, so if merged, I'd be cutting a 2.0 release for this.

[eporama]

I'm all for this approach as I drastically prefer being able to say things about the objects instead of just the client.

I am curious if it would be beneficial to go one level deeper and define the classes based on the objects instead of just on the endpoints.

example: instead of just a Teams class, we'd have a Team class with a lightweight Teams collection.

I think something like:

$team = new Team($client, $uuid);
echo "Deleting team: $team->getName()" . PHP_EOL;
$team->delete();

or

$myTeams = new Teams($client);
echo "my teams: " . PHP_EOL;
foreach ($myTeams as $team) {
  echo $team->getName() . PHP_EOL;
}

[typhonius]

I've thought about breaking it down further, especially since environments has so many endpoints that it really shouldn't just be one class. An example of this might be to split out things like crons and SSL certificates into their own top level class which then either translates to an environment endpoint or extends the Environments class.

That said, I'm totally unsure of whether this would be a best practice or would couple things too closely.

$certificates = new Certificates($client, $environmentUuid);
/* @var $certificate Certificate */
foreach ($certificates as $certificate) {
  echo $certificate->delete() . PHP_EOL;
}

I quite like what you've proposed as it seems clean and simple to use as a library consumer, do you know off the top of your head if this would impact testing/dependency injection at all?

[typhonius]

After just adding the notification class, I think it doesn't make sense to align to Acquia's endpoints with classes. The latest addition shows that when we're getting one notification vs all, we have to load different classes.

Getting a single notification

$notifications = new Notifications($client);
$result = $notifications->get('f4b37e3c-1g96-4ed4-ad20-3081fe0f9545');

Getting all notifications

$applications = new Applications($client);
$result = $applications->getNotifications('aa414bec-1fe0f-9545-813b-c15aa572ef11');

To me, it would be more logical to have one Notifications class and get and getAll methods. We can then extend this further with Crons, Certificates etc.

Potential method

$notifications = new Notifications($client);
// Load using a notification UUID
$single = $notifications->get('f4b37e3c-1g96-4ed4-ad20-3081fe0f9545');
// Load using an application UUID
$all = $notifications->getAll('aa414bec-1fe0f-9545-813b-c15aa572ef11');

We could potentially also implement a CloudApi interface with common methods (get, getAll, create, delete etc)

[typhonius]

This still needs more work - @eporama does this look on the right track to you? One I'm not sure where to put would be the code tasks. I've put deploy/switch/getBranches into their own class but they could also probably live in Environments.

[typhonius]

This has now been merged back into master.