Awesome! - I think I now got this. So, i need to use IRequestHandler mapRequest(Request request); to handle the incoming request to "decode" the fake path/ part and using Url mapHandler(IRequestHandler requestHandler); I can put in any fake path/ part into the URL that goes to the outside.
Thanks a lot Martin! That saves me from doing any JCR/ Brix related hacking as I can now internally map the pages/ paths as I need it :) ----- Ursprüngliche Mail ----- > Von: "Martin Grigorov" <[email protected]> > An: [email protected] > Gesendet: Montag, 11. Juni 2018 12:38:43 > Betreff: Re: wicket 8 / RootRequestMapper vs CompoundRequestMapper > On Mon, Jun 11, 2018 at 1:33 PM, Korbinian Bachl < > [email protected]> wrote: > >> Hi, >> >> thanks a lot for the clarification. So say I want to do some kind of path >> rewriting/ faking like the apache mod_rewrite does. I then would use a new >> root mapper and have this one handle the request, fake the url and give it >> to the "prior" mappers to resolve as in that case I need to make sure I'm >> the first one in the hierarchy. But where would I then rewrite the >> generated URLs? >> > > The request mappers are hierarchical. > See how CryptoMapper does it. > An encrypted url comes, CryptoMapper decrypts it, pass it to the underlying > mappers, they handle the request, then produce readable urls for the > links/redirect, and finally CryptoMapper encrypts those. > > >> >> Best, >> >> KB >> >> ----- Ursprüngliche Mail ----- >> > Von: "Bas Gooren" <[email protected]> >> > An: [email protected], "Korbinian Bachl" < >> [email protected]> >> > Gesendet: Montag, 11. Juni 2018 12:06:12 >> > Betreff: Re: wicket 8 / RootRequestMapper vs CompoundRequestMapper >> >> > Hi! >> > >> > The Compound mapper is merely a wrapper which can have many child >> mappers. >> > The Root mapper is the mapper that wicket calls to do mapping and reverse >> > mapping. For wicket itself it’s not important whether it is a mapper or >> > compound mapper. >> > >> > The higher up in the mapper hierarchy (root -> compound -> compound -> >> > mapper etc), the earlier it is called. >> > Note that this is not that important, since the compound mapper works >> with >> > scores, but nevertheless if you want to do something like prefixing or >> > postfixing urls, order does matter. >> > >> > This is also why, for example, the https mapper should be installed after >> > all other mappers, and as the root mapper. >> > >> > If you just want to map some pages, just add the mapper and don’t worry >> > about where in the hierarchy it is. As long as it returns a score higher >> > than any other, it will be used. >> > >> > Met vriendelijke groet, >> > Kind regards, >> > >> > Bas Gooren >> > >> > Op 11 juni 2018 bij 11:38:31, Korbinian Bachl ( >> > [email protected]) schreef: >> > >> > Hi, >> > >> > situation: I need to add some "special" URL handling for certain URLs to >> > have product pages and catalog pages on root. As we also use brix we >> > already have at least one compoundRequestMapper already in use. >> > Now, wicket seems to have 2 places for that. A new RootRequestMapper >> e.g.: >> > >> > YourApplication#init(): >> > old = application.getRootRequestMapper() >> > application.setRootRequestMapper(new CustomRequestMapper(old)) >> > >> > or a CompoundRequestMapper e.g.: >> > >> > application.getRootRequestMapperAsCompound().add(new >> > CustomRequestMapper(old)); >> > >> > But what are the pros or cons of using either RootRequestMapper vs >> > CompoundRequestMapper? >> > >> > From my point of view the only difference is that CompoundRequestMapper >> > gets exectued based on score, where max score gets used first and lower >> > scores later as long as the >> > >> > public IRequestHandler mapRequest(Request request) >> > >> > doesnt return null anymore; Did I miss something? >> > >> > >> > Best, >> > >> > KB >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
