Implementing Item Changes

[srichter]

I'd like to discuss and hear your ideas for how to best implement the changes endpoint for specific items.

• It seems that the response for changes on a tv show/movie/person follow a mostly-standard format, but each different item will have certain differences in its potential values. That makes me think that a generic ItemChange object is not the way to go.
• How many levels deep do we want to go with this? For instance for TV show changes sometimes it will return that a TV season or episode has been changed. Do we want to then fetch and parse those changes automatically or should that be up to the developer to fetch themselves?
• Do we want to provide a full interface for each type of change? Something like getPosterChanges() that returns either a change or null, or do we just return an array of changes consisting of "poster" => "newValue"?

I would love to hear your thoughts and ideas on this before beginning to implement it.

[vfalies]

Hi, You're right the response for changes is a mostly-standard format for tvshow / movie / person. In documentation, the information returned is only movie, person and tvshow (not tvseason or episode)

If we apply KISS principle (Keep it Stupid and Simple), I think that a simple user utilisation will be for instance:

require` 'vendor/autoload.php';

use VfacTmdb\Factory;
use VfacTmdb\Search;
use VfacTmdb\Item;

// Initialize Wrapper
$tmdb = Factory::create()->getTmdb('your_api_key');

// Get changes
$changes = new Changes($tmdb);

// Get movie change list
$responses = $changes->movie($start_date, $end_date);

// Get tvshow change list
$responses = $changes->tvshow($start_date, $end_date);

// Get person change list
$responses = $changes->person($start_date, $end_date);

The response could be like a search object response. A changes call can be assimile to a search call (with specific parameters) Search response object is already developped, we can reused it.

I think that we can not detail changements on each items. The API response include the iteme id only, not the changement detail. We can not get them.

[srichter]

I have the main Changes endpoints implemented in PR #48, but you actually can get the change details for each item (tvshow example). This will return the detail of what changed and can vary a lot in format between movie/tvshow/person

[vfalies]

I did not see that we can get details on each elements.

So, if I believe the documentation, there are common items in response of each movie / tvshow / tvepisode / tvseason / people. A generic ItemChange object can be good idea if it's a abstract generic item. A specific ItemChange should be defined for each element. For instance a MovieChange herited from ItemChange for define all specifications.

I don't think that provie a complete interface for each changement is a good idea.

To get detail for each items, the call could be like:

$tmdb  = Factory::create()->getTmdb('your_api_key');

$item  = new Item($tmdb);
$infos = $item->getMovieChange($movie_id);

To get new value, a call to getMovie() is enough. All usefull methods are already implemented.

I think that we must be very close of the original implementation. The change list is informative, to get details we must use existing methods.

If you agree, i will merge #48 pull request when all implementation of change will be done.

At this moment, I will update the changelog and documentation.

[srichter]

Do you think it's worth adding a method to retrieve the associated ItemChanges object from a Change result? So someone could do:

$changes = new Changes($tmdb);
$responses = $changes->movie($start_date, $end_date);
$change = $responses->current();
$change->getItemChanges(); // This will return a new MovieItemChanges for the Results\Change->id

If not, do you think it's worth providing an interface around the ItemChanges or should we just leave it up to the developer to do new MovieItemChanges($tmdb, $change->getId(), $start_date, $end_date); if they don't want to retrieve the whole Movie object first?

[vfalies]

I think that the first solution is more elegant if and only if it can be used on all types of objects