Ideas for next version

[neomerx]

Status: all changes to the code are finished and merged to develop and documents are updated. The code is just sitting and waiting to be released on 27-28 of Jan.

• [x] Change asserts
• [x] Add stronger types to methods (arguments and return values)
• [x] Remove depricated methods
• [x] Update query parser (done in limoncello, so just move is needed)
• [x] Simplify l10n with passing strings as a parameter rather than using a custom translator.
• [x] Update travis and docker files
• [x] Remove code related to deprecated JSON API Extensions.
• [x] Update docs and wiki (query param parser changed and encoding params cut a bit)
• [x] Code review (will give some improvement ideas). Unique chance to add incompatible code :smile:

[lindyhopchris]

@neomerx can we submit feature requests for 2.0?

Also it would be good if 2.0 was compatible with PHP 7.1 and above. I.e. drop support for 5.6 and skip 7.0 so that nullable return types can be used.

[neomerx]

Yes, PHP 7.1/7.2 will be minimum.

[lindyhopchris]

Great. Where's the best place to discuss feature requests for 2.0? Would you like an issue per request?

[neomerx]

Let's try Projects feature, shall we?

[neomerx]

@lindyhopchris I've also been working on some code for #183 (you upvoted it) and come to a conclusion it's not worth it. It adds much complexity in comparison to a simple solution with a static method in a Schema.

Alternative would be having something like below in the Schema

public static function get getSelfLink(User $user): LinkInterface
{
    return new Link(...);
}

A solution where you can refer an another Schema in a Schema looks attractive

    public function getRelationships($posting, $isPrimary, array $includeList)
    {
        $user = $posting->getUser();

        return [
            'author' => [
                self::LINKS => [
                    Link::RELATED => $this->getSchemaContainer()->getSchemaByType(User:class)->getSelfSubLink($user),
                ]
            ]
        ];
    }

However, it drastically changes the behaviour of both Container and a Schema. It starts to behave like a pool of resources and a resource. It means we have to ensure consistency of both and Schema cannot be just created with new and has to be created from a container.

It's all doable but will require many changes in client code without adding much. To my mind, it not worth it for the following reasons

• rare usage scenario
• easy and simple alternative

And yes, a custom Container/BaseSchemaProvider could be added by any developer who wants it.

[lindyhopchris]

I think you only need to return an object that the encoder can then convert to the related link.

E.g.

    public function getRelationships($posting, $isPrimary, array $includeList)
    {
        $user = $posting->getUser();

        return [
            'author' => [
                self::LINKS => [
                    Link::RELATED => new ResourceLink($user),
                ]
            ]
        ];
    }

Not saying it should necessarily be called ResourceLink, just using that to demonstrate the point.

[neomerx]

OK. All interaction with links boils down to this

$value = $link->hasMeta() === true ? $link->getHrefWithMeta($prefix) : $link->getHref($prefix);

where $link is LinkInterface so any implementation will work.

@lindyhopchris I also renamed SchemaProvider to Schema and thinking about what would be right name Schema or Scheme, how do you think?

[lindyhopchris]

Schema is the better name of those two, in my opinion.

[neomerx]

Ok, thanks. Will stick to this name.

[neomerx]

Released v2.0.0-beta. Updated wiki in v2 branch its repository (accessable ONLY via git).

To my mind, it's in a good condition and might be released without any changes.

[neomerx]

@lindyhopchris I'm going to release it this weekend. Let me know if you need more time. If you are OK I would appreciate if you could agree to release earlier. I think it's ready for v2.0.0

[lindyhopchris]

@neomerx sorry, just seen this. Happy for v2 if you think it's ready to go. Unfortunately I won't be able to use it for a while because we still need to support websites on PHP 5.6. Hoping to get all of them updated by EOL later this year.

[neomerx]

@lindyhopchris Thanks. So we likely to have some ideas for v3 by that time :wink:

[lindyhopchris]

Hahaha! Maybe ;-)