Hi Martin, thanks for the details, please see below.
----- Ursprüngliche Mail ----- > > From what I've understood you know just some parts of Wicket and this makes > you think some things are hard or even imposible. > Have you considered using Wicket's mounted resource ? it is something > similar to plain Servlet, but you have access to RequestCycle, Session and > Application. Check > http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/ for some > examples and the "localized" resources at > https://examples9x.wicket.apache.org/mappers/. > You can even go one step further and use WicketStuff RestAnnotations ( > https://github.com/wicketstuff/core/tree/master/wicketstuff-restannotations-parent) > - an integration between Wicket and JAX-RS. > This way your React/Angulat/Vue/... frontend could talk to the backend > without dealing with Wicket.Ajax (and jQuery), which is a convenience for > talking to Wicket behaviors/components (something you seem to not need > anyway) for this use case. I must admit that it may have sounded like that. In reality our main application is still based on the wicket brix cms and works very well with it, even will push it to wicket 9 in the next half year as we gear up for java 11 now (sounds crazy as 17 got released yesterday). Also our backend app is pure wicket. However, now someone needs some improvement here and there and its most often just some additional JS or helpers. If you have to use plain wicket for all (even ajax) its often more cumbersome than to just slap a small react app into it (you need to think of react beeing able to just control a/ some small part(s) of the page - this works nice for things wicket just renders but as soon as you try to enhance forms etc. youll end up in hell (or Im to incompetent for it)). What I really find very inspiring by the rails guys is that they not only see their "product" as not "the silver bullet" but that they see the need to slap together multiple techs (server side rendering like wicket with frontend things like react, vue etc. and so they interoperte instead of seperate). I did know the resource mounting and the header-items (however with the header items I often had nothing but headaches in the past, e.g.: how to prioritize? how to level? how to bundle? etc. etc. - I wont even talk about partial in header and partial off header JS inclusion, problem is here: positions of different parts matter). The RestAnnotations seem to come closer to what I talked about and Im diving deeper into them - at least for my next "BrixTile" they might be used as it will be some kind of product configuration thing. I love wicket - I use it very much and it shelters so much trouble off me as long as Im away of JS with it. Oh and "re"-deploys... if you work with micronaut (or quarkus even I dont like that one) you'll miss the save-file, gets compiled and is live before you even switch to the browser thing.... I hope my last mail didn't come off as pure complaining but to just be a voice how to make wicket better on the frontend side so its still as alive (or even more) in 2030 as it is in 2020 :) Best, KB > > About positioning things in the <head> - have you heard of > <wicket:header-items/> ( > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_header_contributors_positioning) > ? But this won't be needed too if you make Ajax calls to mounted resources. > > And yes, Wicket is not a silver bullet that you should use for all types of > applications! > > Whenever you have specific questons about Wicket please ask at > us...@wicket.apache.org! > We will try to help you or even recommend you another library/framework > when Wicket is not the best solution! > > Martin >
