Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EZP-25613 Add a way to register resources with the rest root #1619

Merged
merged 4 commits into from Apr 29, 2016
Merged

EZP-25613 Add a way to register resources with the rest root #1619

merged 4 commits into from Apr 29, 2016

Conversation

wizhippo
Copy link
Contributor

@wizhippo wizhippo commented Mar 23, 2016

JIRA: https://jira.ez.no/browse/EZP-25613

This adds the ability to add resources in the rest root so rest consumers can discover them. For example you can register the resource and use the capi auto discovery to find the uri for the resource.

To add a resource a bundle would add the resource using the PrependExtensionInterface and pre-pending the new resource to the config.

@wizhippo
Copy link
Contributor Author

tests fail on RootTest. This is because the Root now expects an array of Resources to be provided. Should I pass an arbitrary array of resources and test them or should I replicate the hard coded resources in the original Root value object visitor by creating array of resources based on the resources in default_settings.yml?

@bdunogier
Copy link
Member

Can you please create an issue on JIRA if there isn't one, and link the PR to the issue ? I'll assign it to you and move it to dev.

*/
class Resource extends RestValue
{
public $name;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

phpdoc with description + example for public properties of value objects.

@bdunogier
Copy link
Member

Looks good overall.

One thing I'd like to see improved is the separation between the Controller and the Root Value construction. Ideally, the Root value would be obtained via a service, and that service would have an implementation that uses an array of Resource objects, and uses the expression engine to generate the hrefs.

@wizhippo wizhippo changed the title [WIP] Add a way to register resources with the rest root [WIP] EZP-25613 Add a way to register resources with the rest root Mar 23, 2016
@wizhippo
Copy link
Contributor Author

Test are failing because the default_settings.yml are not loaded so the resources are not defined. They pass locally. Ideas on how I can fix this?

/** @var \eZ\Bundle\EzPublishCoreBundle\DependencyInjection\EzPublishCoreExtension $eZExtension */
$eZExtension = $container->getExtension('ezpublish');
$eZExtension->addConfigParser(new ConfigParser\RestResources());
$eZExtension->addDefaultSettings(__DIR__ . '/Resources/config', ['default_settings.yml']);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was loading the default_settings.yml file moved here? I don't think there's a reason for that.

I suspect this is the reason why the tests are not loading the config.

@bdunogier
Copy link
Member

Okay, this should cover it. It's mostly about naming, but as Camus said: "Misnaming things adds to the evil of the world."

Also, if you want to give it a try, it would be good to improve the REST functional tests, and check that we have the links we expect. This change removes some coverage from the visitor's unit tests, and I think we want to check that the root resource behaves as we expect it to.

@@ -4,3 +4,83 @@ parameters:

# URI part that all REST routes begin with. By this a REST request is recognized.
ezpublish_rest.path_prefix: /api/ezp/v2

ezpublish_rest.root_resources:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you write directly to the siteaccess aware container config ? You could then skip loading the container config altogether: https://github.com/ezsystems/ezpublish-kernel/pull/1619/files#diff-0b45d72cefd7a4d4849d6d15e1527b31R40.

ezsettings.default.rest_root_resources:
    content:
        ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this, this simpler. In service.yml I can just pass '$rest_root_resources$'. We would lose the checks from the semantic config.

@wizhippo
Copy link
Contributor Author

To add a test for the default configured resources. What would be a good test name? Would I just load in the resources from the default_settings.yml build a Root and test against the original tests removed in RootTest?

@bdunogier
Copy link
Member

To add a test for the default configured resources.

I meant a functional test, that uses the actual application, and validates the responses.
That way we are sure that the rest resource doesn't change without reasons (it should check that the expected elements are there, but it shouldn't check that there are no extra elements).

@wizhippo
Copy link
Contributor Author

@wizhippo wizhippo closed this Mar 27, 2016
@wizhippo wizhippo reopened this Mar 27, 2016
@wizhippo
Copy link
Contributor Author

@bdunogier Not sure if you saw but I had added the tests.

@bdunogier
Copy link
Member

bdunogier commented Mar 28, 2016 via email

@bdunogier
Copy link
Member

Looks good to me now.

Opinion @dpobel / @emodric ?

@emodric
Copy link
Contributor

emodric commented Apr 6, 2016

So how do we actually register custom root resources, apart from adding directly to internal ezsettings.default.rest_root_resources, which is discouraged? This probably needs semantic config, much like config for registering custom field view templates.

Other than that: 👍

/**
* This class represents a resource.
*/
class Resource extends RestValue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too bad RestValue doesn't implement the base ValueObject. We could have used the same properties scheme :/

@dpobel
Copy link
Contributor

dpobel commented Apr 8, 2016

nice! besides the missing JIRA issue +1

$resources[] = new Values\Resource(
$name,
$resource['mediaType'],
$language->evaluate($resource['href'], [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a try/catch here ? what will evaluate() do if the expression is invalid ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dpobel Missing JIRA issue? https://jira.ez.no/browse/EZP-25613

@bdunogier It throws an SyntaxError exception. Do you want the message more specific like new SyntaxError("Invalid expression '${resource['href']}' in resource '$name'"); or throw a different exception? If not to throw an exception then what?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An exception is good. It should end up as a 500 in REST, and that's good, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be good as is. evaluate will throw an SyntaxError already.

@bdunogier
Copy link
Member

Great, let's merge this then. We can take care of semantic config in another pull-request.

@bdunogier bdunogier merged commit c6b896d into ezsystems:master Apr 29, 2016
@andrerom andrerom changed the title [WIP] EZP-25613 Add a way to register resources with the rest root EZP-25613 Add a way to register resources with the rest root Apr 29, 2016
@wizhippo
Copy link
Contributor Author

Not sure it counts but you can do:

ez_publish_rest:
    system:
        default:
            rest_root_resources:
                someresource:
                    mediaType: ''
                    href: 'router.generate("ezpublish_rest_createContent")'

@wizhippo wizhippo deleted the dynamic-rest-uri branch April 29, 2016 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
5 participants