-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support HtmxResponse that isn't a direct return type #127
Comments
Reporting back: Option 3 won't work. Spring selects only one handler. That also means that option 1 won't work. Perhaps option 2 will work. |
@wimdeblauwe How do you feel about PR #128 ? It is working really well for me in my 3 projects that I've migrated to JTE |
Hi @checketts, sorry I forgot about this. If you can just add some documentation, we can merge it and I will create a new release for you. |
I just pulled this into a project and it is working great! |
@checketts Do you have a special implementation in your projects to handle |
@xhaggi Yes. I'll try to upload a sample project (and hopefully push upstream into the JTE Spring module) |
I've working with JTE as my templating engine recently and been very impressed. The templates are statically compiled and work very well with this library.
However there is an advanced use case where the Gradle or maven plugin generates an
interface
that represents your templates, complete with parameters.To leverage these templates I'm returning a
JteModel
in my controller methods, that isn't compatible with this library. I would like to propose a few solutions.1- Support subclassing
HtmxResponse
. I might be able to leverage that so myJteModel
provides the right data.2- Support making
HtmxResponse
an injectable parameter, similar to how you can set the response code when injectingHttpServletResponse
.3- Support a 'provider' approach for
HtmxResponse
. This means my response can implement an interface and provide anHtmxResponse
, allowing the builder to remain the same but making the return type more flexible.I'll start on a PR for option 3. But I'm interested in feedback on any and all of these options.
The text was updated successfully, but these errors were encountered: