I can see the use case for many of these but can you elaborate on the use case for the app object being available? I don’t have a strong reason to exclude it, just curious.
Being able to access to app object gives a lot of flexibility, for example we could get tosUrl even if no dedicated param is available.
Another quite useful use case is to include links to content like threads without hardcoding the title and URL (which would require updating them if the title or URL changes -> manual maintenance overhead):
Fair enough I know you know what you're doing in particular, but the power it comes with can also be a liability. Our preference is that things like database queries are avoided inside templates as a rule of thumb, but I understand it's a useful escape hatch.
It is incredible useful to be able to call (template valid) public repository methods instead of needing to write a a template listener and inject arguments that way
I'm mostly asking because we might offer more canonical access for common use cases (including the entity manager and repositories) and limit exposure to the entire container in templates at some point in the future. We don't want to be overly restrictive and are happy to accommodate within reason, but some amount of friction is there by design.
Totally understandable even though such a change may require more work (for 3rd party Add-ons) then.
My main complaint right now is that the container is available for public and admin templates, but not email - this restriction doesn't make sense to me.
It should either be available for all template types - or none.