I already know ;) but thx for update on this
Best, KB ----- Ursprüngliche Mail ----- > Von: "Ernesto Reinaldo Barreiro" <[email protected]> > An: "dev" <[email protected]> > Gesendet: Freitag, 30. Oktober 2026 17:37:42 > Betreff: Re: Master branch set for Wicket 11 > Hi, > > On Wed, Feb 4, 2026 at 6:38 AM Korbinian Bachl < > [email protected]> wrote: > >> Hi all, >> >> I had a closer look at what it would mean to base Wicket 11 Ajax on htmx, >> and I wanted to share some early thoughts and open questions. >> >> A possible technical starting point could be something like a >> HtmxPartialPageUpdate extends PartialPageUpdate, >> since Wicket already funnels Ajax rendering through PartialPageUpdate. >> Conceptually, that feels like the right extension point. >> >> However, I’m currently unclear how Wicket would reliably detect an htmx >> request versus a regular request. >> >> According to the htmx documentation (https://htmx.org/docs/#requests) >> htmx issues regular HTTP requests (GET/POST/etc.) and identifies itself >> via a fixed set of request headers. >> As far as I understand, these headers cannot be freely customized (and how >> do we differ from our "wicket htmx" requests and some of the implementing >> developer requests?). >> >> In contrast, Wicket Ajax currently relies heavily on its own custom >> headers and the AjaxRequestTarget abstraction to clearly distinguish Ajax >> requests from normal ones and to control the response format and >> client-side processing. >> >> Another structural concern is partial page updates. >> Wicket allows updating an arbitrary number of components per request. To >> achieve the same with htmx, hx-swap-oob would likely be required almost >> everywhere. While technically feasible, this would fundamentally change how >> responses are rendered and composed. >> >> On top of that, there is the whole ecosystem of: >> >> Ajax behaviors and event bindings >> >> AjaxFormSubmitBehavior and related form-processing semantics >> >> Even if all of this could be reimplemented on top of htmx, there is a >> bigger compatibility question. >> >> How would existing code—especially from wicketstuff, third-party >> components, and private component registries—continue to work? >> >> A lot of existing components rely directly or indirectly on: >> >> Wicket.Ajax client-side code >> the XML-based Ajax response format >> JavaScript callbacks injected via AjaxRequestTarget >> >> Requiring all of that to be rewritten would be a very disruptive change >> for the ecosystem. >> >> This makes me wonder whether a more incremental approach might be >> preferable. >> >> For example: >> >> First, remove the dependency on jQuery and modernize the existing Wicket >> Ajax JavaScript. >> > > This is already implemented in Wicket 11. > > >> Then evaluate the size, complexity, and responsibilities of the remaining >> Wicket JS layer. >> Based on that, explore htmx more deeply and evaluate whether a >> compatibility layer (some form of Wicket.Ajax glue on top of htmx) could >> realistically preserve backward compatibility. >> >> That might give a clearer picture of how much change is actually needed, >> and where htmx genuinely helps versus where it introduces new challenges. >> >> I’m very interested in hearing thoughts on whether such a staged approach >> would make sense, or if people see a cleaner path forward that I’m missing. >> >> Best, >> Korbinian >> >> >> >> >> >> >> ----- Ursprüngliche Mail ----- >> > Von: "Martijn Dashorst" >> > An: "dev" <[email protected]> >> > Gesendet: Montag, 2. Februar 2026 16:15:39 >> > Betreff: Re: Master branch set for Wicket 11 >> >> > I have no concrete plans, but a wishful thinking list: >> > >> > I am considering a marriage between HTMX for client side and Wicket for >> > backend. But nothing concrete (or even in a proof of concept, just an >> idea >> > in my head). >> > >> > There are some hurdles to overcome with that approach: >> > - wicket component identifiers and generated markup ids will prevent most >> > of the currently used morphing algorithms to work properly, and probably >> > also be a blocker for htmx >> > - using htmx as front end assumes htmx is in the lead for issuing >> requests >> > to the backend and wants to have a HTML response (which is not Wicket's >> way) >> > - using hx-swap="append" or similar is not compatible with wicket's >> > listview/dataview components that render everything >> > - using idiomorph for replacing markup in an ajax swap will probably not >> > work due to the new markup ids for components >> > >> > I also want to look to modernise the API and internals, using builders, >> > automatic parameter resolving similar to JAXRS, etc. >> > >> > Make the renderer easier to embed in JAXRS >> > >> > Make Wicket and Quarkus work better together (and native compilation) >> > >> > Make Wicket's stateless support first class. >> > >> > And probably more than I can manage :D >> > >> > Martijn >> > >> > >> > >> > On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl < >> > [email protected]> wrote: >> > >> >> Hi, >> >> >> >> is there any kind of ideas/ roadmap already? >> >> >> >> What serlvet level ist planned? 6.0? or 6.1? >> >> >> >> Will CDI be seen as core requirement? >> >> >> >> What about jQuery dependency and ajax? >> >> >> >> >> >> >> >> >> >> >> >> >> >> ----- Ursprüngliche Mail ----- >> >> > Von: "Andrea Del Bene" >> >> > An: "dev" <[email protected]> >> >> > Gesendet: Samstag, 31. Januar 2026 19:49:17 >> >> > Betreff: Master branch set for Wicket 11 >> >> >> >> > Hi! >> >> > >> >> > I've set master branch to start working on Wicket 11. I've set java >> 21 >> >> > as codebase version and I updated Spring and Junit respectively to >> >> > version 7 and 6. The new branch wicket-10.x will host the code for >> >> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to >> >> > update Java to 21. >> >> > Please let me know if everything is ok with this. >> >> > >> >> > Thank you! >> >> >> > >> > >> > -- >> > Become a Wicket expert, learn from the best: http://wicketinaction.com >> > > > -- > Regards - > Ernesto Reinaldo Barreiro > Apache Wicket Committer > Emerging artist > https://www.instagram.com/reinaldo.barreiro.art/
