Use attribute to render templates

[nickygerritsen]

I saw that since Symfony 6.2 you can use a #[Template] attribute to indicate which template to render. I think it makes the controllers a bit cleaner, so I wanted to implement it.

Then I found out that we have some controllers that render a different file for AJAX requests, so I added a #[AjaxTemplate] attribute to support this. I also added a way to set a custom response object, which we sometimes do for setting custom headers or other things.

I then modified the public controller myself and afterwards used AI (Claude in particular) to rewrite all other controllers and verified myself afterwards if it did anything weird (like long lines or stuff that just doesn't work).

I committed the the new attribute + event listeners in a separate commit. As said the big, second one is mostly AI generated.

It does add some lines to make the docblocks clearer. If we don't like that, we can change all of them to array<string, mixed>.

[eldering]

I'm not sure this is cleaner. Instead of explicitly calling the template this is now all written in meta-annotation. Also, now the return type is a mix of array and Response. What's the gain?

[nickygerritsen]

For me it's twofold:

• The Ajax ones have less if branches
• We are more explicit in the array shape return type

However if the majority doesn't like it I'm fine with not doing it

[eldering]

For me it's twofold:

* The Ajax ones have less if branches

Maybe I'm overlooking something, but which branches?

The difference I basically see it that instead of explicitly calling render and return a Reponse, this is now encoded in annotation and the annotation also declares what template data should be returned.

* We are more explicit in the array shape return type

Well, but that's just written down in the annotation, so now that's written in two places and if you forget to update the annotation, then you still have a bug. So I don't really see the advantage of that.

[nickygerritsen]

For me it's twofold:

* The Ajax ones have less if branches

Maybe I'm overlooking something, but which branches?

See for example here: https://github.com/DOMjudge/domjudge/pull/3145/files#diff-cc71aa6a9b851ee37894e1943a11fd1d6676ae347fac6e088ec93325e4a90e1aL93-R111

The difference I basically see it that instead of explicitly calling render and return a Reponse, this is now encoded in annotation and the annotation also declares what template data should be returned.

This is correct.

* We are more explicit in the array shape return type

Well, but that's just written down in the annotation, so now that's written in two places and if you forget to update the annotation, then you still have a bug. So I don't really see the advantage of that.

Well, that's how PHP works I guess. Instead of arrays we could have data objects everywhere, which makes this 'link' strict, but adds a lot of classes.

Again, I see your point. I still like the new way better, but if you and others disagree we will just close this PR, I'm fine with that.

[meisterT]

I have a slight preference for the new code.

Do we have any checks that the annotations are correct?

[nickygerritsen]

I have a slight preference for the new code.

Do we have any checks that the annotations are correct?

We don't and I wonder how we could do that. We somehow have to know what variables are expected in the Twig template. We could write something ourselves. A quick Google gave me https://github.com/twigstan/twigstan which is '
very experimental'.

[eldering]

I prefer the old version as it's more KISS.

[vmcj]

I think I would like it more if we can return a DTO for it. I like how this forces us to provide the same information to both the AJAX & non-AJAX templates but this should be a PR which removes lines of code but it seems it just adds lines of code.

[nickygerritsen]

Of course most added lines are added because we now specify what types we return. If we replace them with array<string, mixed> this would not be the case.

But I agree that it would be better if we had DTO's (though this would add even more lines).

However this is not possible with the native Symfony way of doing this. We could create a custom event to do this, but then I wonder if it's really worth it.

I'll leave this PR open for now, we can probably discuss in Karlsruhe whether to close it or not.

[vmcj]

But I agree that it would be better if we had DTO's (though this would add even more lines).

Yes, but less lines in the file that I'm editing, but I would get the hint in my IDE.

However this is not possible with the native Symfony way of doing this. We could create a custom event to do this, but then I wonder if it's really worth it.

That would be annoying yes.

I'll leave this PR open for now, we can probably discuss in Karlsruhe whether to close it or not.

I do think it's a good idea as it let's us use the features of the framework which will remove bugs in the end (I hope).