On 24. 03. 23 10:26, Stephane Epardaud wrote:
>
>
> On Thu, 23 Mar 2023 at 15:05, Martin Kouba <
mko...@redhat.com
> <mailto:
mko...@redhat.com>> wrote:
>
> On 22. 03. 23 16:20, Stephane Epardaud wrote:
> > This is very cute :)
> >
> > I wonder exactly what use-case it fills.
> > It certainly makes it much easier for templates that take zero
> > parameters from their controllers.
> > I've a number of those in my Renarde
> > apps. I wonder if there's a way we can combine them.
>
> You could combine them. But at the moment you would need to "hide" the
> templates that should not be served by this extension with a regex:
>
https://quarkiverse.github.io/quarkiverse-docs/quarkus-quteserverpages/dev/index.html#quarkus-qsp_quarkus.qsp.hidden-templates <
https://quarkiverse.github.io/quarkiverse-docs/quarkus-quteserverpages/dev/index.html#quarkus-qsp_quarkus.qsp.hidden-templates>
You don't need a tag for this. You can do just
{cdi:vertxRequest.getParam('foo')} or {cdi:vertxRequest.path}.
> Perhaps draw a
> line at deserialisation?
> But for any page that requires DB access or worse: actions (like sending
> mail or writing to a DB), do you think this would be appropriate?
So the idea was to use the QSP for the "view", i.e. to serve the content
for GET requests, not for handling POST requests. For these interactions
you'd need to use a custom route or JAX-RS resource.
As for the DB access - the aforementioned qsp-panache-example [1] shows
how easy it is to use a panache repository directly in your template.
[1]
https://github.com/mkouba/qsp-examples/tree/main/qsp-panache-example
> I'm wondering where is the line we draw between QSP and JAX-RS+Qute.
I don't think we need a line but in general, QSP is a good fit if you
need to visualize some data. Not so much to build a "complex" webapp,
where "complex" means a lot of user interactions with complex
validation, etc.
And it could be also combined with technologies such as HTMX [2] to add
AJAX, WebSockets/SSE functionality.
[2]
https://htmx.org/
> --
> Stéphane Épardaud