mediamonks / drupal-controller-annotations Goto Github PK

https://www.drupal.org/docs/8/converting-drupal-7-modules-to-drupal-8/d7-to-d8-upgrade-tutorial-convert-hook_menu-and-hook

Would it be possible to add something to the annotation, to register menu links, tabs etc?

E.g. here, https://github.com/drupal/drupal/blob/b560f348bd5bfe11ab7c4784b529f0cca5277639/core/modules/dblog/dblog.links.menu.yml
most of this looks redundant.

I guess this would be a separate problem, not immediately related to this module..

This is not about this specific module, but a question to you as a person / developer.

This module is about replacing *.routing.yml definitions with annotations.
I wonder if the same could be done for services.

After a quick research I found this:
http://jmsyst.com/bundles/JMSDiExtraBundle/master/annotations

Interestingly, yched mentions this here, https://www.drupal.org/node/1863816#comment-6877622 5 years ago.

From #7

donquixote:

Somehow I don't like how those annotation classes are so verbose and boilerplate-y.
But I suppose it is a matter of taste, and it would be futile trying to convince you.

slootjes:

I would rather call it explicit, a matter of taste I guess :-)

I think what I don't like is all the setters and getters, made necessary by the base class ConfigurationAnnotation, and its constructor mechanics.
The setters are only called in a "magical" way in the constructor.
Also the getters are never going to be called from outside.

So..

• setters could be protected
• getters could be private
• getters could be removed completely, and the modifyRoute() would directly access the private properties instead.

I was thinking that the base class could be replaced. The constructor would then write to the private properties directly instead of calling the setters. However, to do this from a base class, the properties would have to be protected instead of private. I like private :) So this means the setters should stay, but can be protected.

I was also thinking to remove the private properties completely and replace them with an associative array. However, this would prevent the PhpStorm annotation plugin from doing autocomplete.

How would we annotate a _title_callback?

/**
 * @Route(..)
 */
class MyController {
  /**
   * @RouteTitleCallback(..)
   */
  function title($arg) {
    return Html::escape($arg);
  }

  /**
   * @Route(..)
   */
  function page($arg) {
    return ...;
  }
}

Question: How would we tell that the title callback is for the route method below?
The annotation could contain the route machine name.. but I would like to avoid this.
Maybe something like @TitleCallbackForRouteBelow(..), or have this implicit?

Maybe this is better:

/**
 * @Route(..)
 */
class MyController {

  function title($arg) {
    return Html::escape($arg);
  }

  /**
   * @Route(..)
   * @RouteTitleCallback("::title")
   */
  function page($arg) {
    return ...;
  }
}

Or "self::title" instead of "::title" ?

Looking for "ParamConverterInterface", I find:

• Drupal\Core\ParamConverter\ParamConverterInterface
• Sensio\Bundle\FrameworkExtraBundle\Request\ParamConverter\ParamConverterInterface

The first one is used in "traditional" Drupal routes declared via *.routing.yml.
The second one is recommended in https://github.com/mediamonks/drupal-controller-annotations/blob/8.x-1.x/docs/2-usage.rst#paramconverter

Does this mean the existing Drupal param converters will not work with controllers registered via annotation?

In my PR at #7. I proposed separate annotations for @title and @TitleCallback.

The reason being: _title_arguments (and _title_context) are only useful in combination with _title_callback.
And _title and _title_callback are not meant to be used in combination.

Separate annotations would make it make it easier to use the API correctly.

The ControllerEventSubscriber subscribes to KernelEvents::CONTROLLER with 'onKernelController'.
I don't really understand why this needs to happen.

The way I understand it, the purpose of this module is to create route definitions from annotations.
So the annotations should be read whenever the *.routing.yml is read, which is on every cache rebuild.
There should be no need to read annotations when visiting the page.

So I don't really know what the 'onKernelController' is doing.

I'm a Symfony developer working on a project using Drupal 8.4.x with some homebrew and imported modules located in folders with names like:

modules/custom/*
modules/override/*

Many of these modules contain templates needed for controllers that use annotations. Unfortunately, the @Template annotation as it stands is triggering an error for these modules:

The website encountered an unexpected error. Please try again later.

Tracing the problem reveals that the drupal-controller-annotations bundle is hard-coded to expect all modules to live within:

modules/* (without the extra sub folder)

This is located in the format function, on line 85 in TemplateResolver:

return sprintf('modules/%s/templates/%s.html.twig', $module, $templateName);

To fix this problem in a future release, please amend as follows:

return sprintf('%s/templates/%s.html.twig', drupal_get_path('module', $module), $templateName);

This change will allow module templates to be located however they are configured.

Hi,
when trying to run composer require drupal/controller_annotations, it says:

Your requirements could not be resolved to an installable set of packages.

Problem 1
- symfony/framework-bundle 4.0.x-dev requires php ^7.1.3 -> your PHP version (5.6.31) does not satisfy that requirement.
- Conclusion: remove phpdocumentor/reflection-docblock 2.0.5
- Conclusion: don't install phpdocumentor/reflection-docblock 2.0.5
[..]

It goes on from there, trying to somehow make it work.
So my question is, is it currently possible to install this on PHP 5.6?

I currently still have Drupal 7 sites which I do not want to take the trouble of making them compliant with PHP 7. This is why I am still on PHP 5.6.
Maybe I should use Docker.. just did not take the time yet to make myself familiar with it and make it work on my system.

I was looking at AnnotatedRouteControllerLoader::configureRoute().
Currently this supports a limited and hardcoded selection of annotation classes.

What about a new interface for generic route config annotations, like this:

interface RouteConfigurationAnnotationInterface {
  public function configureRoute(Route $route);
}

Then in AnnotatedRouteControllerLoader::configureRoute() we would add this:

            } elseif ($configuration instanceof RouteConfigurationAnnotationInterface) {
                $configuration->configureRoute($route);

As a (controversial) use case, currently I am thinking of this: #3
E.g. a @MenuLink(..) annotation, which would set an option in the route, which later can be read by a menu link plugin derivative.

Maybe there are less controversial use cases.
E.g. shortcuts for @Security: Instead of @Security(access=true), one could then write @AccessPublic.
Or instead of @Security(role="admin"), write @Role("admin")

Or maybe a @RouteTitle("Hello") or a generic @Option(_title = "Hello"), instead of @Route("/path/to/hello", options = {"title" = "Hello"})

Ok, I am not sure yet if my examples are really worthwhile, but I do think it would open some interesting possibilities.

Btw, I prefer longer identifiers like @RouteTitle over just @Title, this reduces the ambiguity on IDE autocomplete.

Hello @slootjes !

After a long time dealing only with Drupal 7, I finally rediscovered this module, and remember all the good times. (#3, #4).
I see a number of nice changes were done.

However, on the module page I see:

• Usage count = 1.
• Not covered by security policy.

The usage count does not mean it is abandoned - I have similar projects on D7 which suffer the same fate. But this makes it hard to propose this for a corporate environment, and risky to base another contrib module on it.

Do you have plans for this module? Or perhaps everybody downloads the module from github instead of drupal.org?

Background

What happened is I had modules lying around that I was planning to publish a D8 version of (cfr / renderkit / entdisp etc), and that was using my own hacked version of controller annotations. Not a good state for publishing.

I then noticed that you implemented some of the ideas, especially the RouteModifierInterface, which was then split into two distinct interfaces for class and method. And you are passing the reflection class + method to the route modifier. Cool stuff!
I also notice that the nasty dependency is gone.

As a first step I rebased all my custom modifications on the latest version of the module, and made it match the new API, to see what would be left. I will have to review the changes and decide which of them still make sense. Perhaps some pull requests will be born from that.

For #3 I now have a dedicated module with some additional route modifiers.