Skip to content

Conversation

nickygerritsen
Copy link
Member

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
Copy link
Member

eldering commented Oct 7, 2025

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
Copy link
Member Author

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
Copy link
Member

eldering commented Oct 9, 2025

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
Copy link
Member Author

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
Copy link
Member

I have a slight preference for the new code.

Do we have any checks that the annotations are correct?

@nickygerritsen
Copy link
Member Author

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants