to 24.4.2025 klo 8.26 Martijn Dashorst (martijn.dasho...@gmail.com) kirjoitti:
> On Wed, 23 Apr 2025 at 23:26, Martin Terra < > martin.te...@koodaripalvelut.com> > wrote: > > > As long as it doesn't take over Wicket. Roughly it looks like "what do > you > > need wicket for if you decided to go heavy on CDI". > > > The idea is to make such an integration that it would sit along side with > wicket-cdi or such. However if one was to use quarkus and wicket it would > come with some price. > > Thinking out loud: can't you just spin a non wicket CDI handler into a > > different servlet and keep it separate from wicket? > > > I'm not sure how that would help with injection of services in Wicket > components. > Thanks for the perspective. I tried to google for an example with wicket where it makes sense to have cdi within wicket. I assume you have some experience with this. Can you refer to some example or paste some meaningful code sample (hello world is too trivial)? Would help to evaluate if tihs is something we should be looking into. ** Martin > > > > Martijn > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > > > > > > > > ** > > Martin > > > > ke 23.4.2025 klo 22.10 Martijn Dashorst (martijn.dasho...@gmail.com) > > kirjoitti: > > > > > After some soul searching for a while I might have a workable idea for > > > using Quarkus CDI and Wicket, which is probably the biggest hold back > for > > > using these technologies together. > > > > > > I've put my thoughts in this JIRA ticket in the last comment: > > > > > > > > > https://issues.apache.org/jira/browse/WICKET-6917?focusedCommentId=17946818&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17946818 > > > > > > I'll also paste my comment here: > > > > > > The issue is that ARC (the cdi implementation behind quarkus) doesn't > > > support and isn't going to support non-contextual injections as it > wants > > to > > > resolve injections at build time rather than deploy- and runtime. > > Wicket's > > > basic premise is that it is a non-managed framework where you are > allowed > > > to new your components and behaviors and models at will, which all > escape > > > the management of a CDI container. > > > > > > I'm thinking about this a bit for a while, and I figure that it might > be > > > possible to provide some form of integration if we limit some > constructs > > > that are now available for Wicket developers. > > > > > > First we need to make pages managed, and the restored state of pages > > > managed when they are retrieved from the page store. This is probably > > > fairly easy to build using a `@SessionScoped` CDI producer that > retrieves > > > pages either from a factory or from the pagestore if there's state > > > available (i.e. there's a pageid in the request). This also means that > > you > > > are no longer allowed to instantiate pages yourself, but that they must > > > have a default constructor, a pageparameters constructor or a > > > mapper/factory that can instantiate the page based on the provided URL. > > > This allows CDI to perform its injections on the retrieved instance(s). > > I'm > > > sure this would work for instantiating new pages. I'm not so sure about > > > retrieving pages from the page store and getting those managed again > > (about > > > 90% hopeful that it works). This should also work with injected > services > > in > > > the page instances, but not general component instances. > > > > > > Next we need a way to make Panels injectable with CDI beans. This is a > > > hairy one. For now the only way I can foresee this working is to have > an > > > Instance<MyPanel> field in your page and get an instance from that to > add > > > to the page's component hierarchy. I'm open to other suggestions. > > > > > > As for scoping, I'm not 100% sure, but using the @RequestScope for the > > page > > > producers and panel instances might just work. We might need our own > > scope, > > > but I wouldn't know how that differs from the request scope for our > > > purposes. > > > Injection into behaviors and models is something that either needs to > go > > > through the Instance<Behavior> / Instance<FooModel> route or using > > producer > > > methods. My guess is that it is probably easier to use constructor > > > parameters and use the page/panel injected beans as parameters to the > > > models/behaviors. > > > > > > This is all without providing any integration libraries such as a > "Wicket > > > Arc" that would plug into arc for our purposes. It might be possible to > > do > > > all the above automatically given the right integration, but I'm not an > > arc > > > knower, nor a CDI implementation builder. > > > > > > What do y'all think? > > > > > > Martijn > > > > > >
