I would kinda prefer @ausi's solution in #4055 (comment)
If I ever write an attribute with a type, I would never write

#AsContentElement("texts", "foobar")

The goal should be to work the same as annotatinos did, so to use named paramters (I know we can't enforce that). Either write

#AsContentElement(category: 'texts')

or write

#AsContentElement("foobar", category: 'texts')

if you have a type. Making category default null and throw an exception would solve that.

@m-vo Will you update this PR accordingly?

I’d prefer something that works so that my IDE shows me if something is missing or what will happen.

IMO only the following two possibilities accomplish that:

__construct(string $category, string $type = null, …
__construct(string $type = null, string $category = 'texts',…

With string $category = null my IDE would suggest that this parameter is nullable and not required (which it is not at runtime then 😕)

I‘d be fine with string $category = 'texts' as well.

But then you could omit all parameters and the element would appear in the text category (why text?). I'm ok with that, but I think I would prefer a solution without adding magic.

Why don‘t we just make $type a required parameter, too?

__construct(string $type, string $category, …

The maker bundle will always set the type anyway:

Why don‘t we just make $type a required parameter, too?

In my opinion it's a good thing, that the type is inferred by default, because it promotes a common naming scheme. And I don't want to type it when creating fragments myself. 🙂

We should also discuss the usage of the variadic parameter.

I usually always end up using

/**
 * @ContentElement(MyContentElement::TYPE, category="texts")
 */
class MyContentElement extends AbstractContentElementController
{
    public const TYPE = 'my_content_element';
}

so that I can reference the type in the DCA for example.

I usually always end up using

/**

• @ContentElement(MyContentElement::TYPE, category="texts")
  */

👍 for constants, that can be automatically refactored. Maybe the FQCN should get the default type in the future?

Other aspect: We currently use the type to identify templates, but with Twig there is no point in injecting a Template in getResponse(). So either we build a special render method that, again, uses the type to identify a template or you would explicitly reference a template in $this->render() anyways and not need the type at all. This is also coupled to the discussion about template selection in the back end.

If we want to alter the behavior in Contao 5, we could maybe already prepare this in 4.13 when using attributes.

The changes are now implemented as discussed.

Because we're now in a situation, where it's required to use named arguments to set arbitrary keys, I had to use some trickery in the tests, so that jobs < PHP8 would not result in a syntax error. If there is a better solution, let me know.

If there is a better solution, let me know.

new AsContentElement(...[
    'type' => 'content_element/text',
    'template' => 'a_template',
    'method' => 'aMethod',
    'renderer' => 'inline',
    'foo' => 'bar',
    'baz' => 42,
]);

https://3v4l.org/3mVUg

Thank you @m-vo.