Sorry, I overlooked that part of your original post.

I've been toying with the same idea, since class aliases are bound to cause
problems as projects grow bigger. As long as the aliases are user-generated,
they might not be unique.

So I had a quick look at the source code of WebRequestCodingStrategy, and I
think it should be possible to create a solution for your problem quite

1) subclass WebRequestCodingStrategy, and use it by overriding
newRequestCycleProcessor() in your application, and return a subclasses
WebRequestCycleProcessor which returns your custom WebRequestCodingStrategy
in the call to newRequestCodingStrategy(). Quickest solution is to create an
anonymous inner class for the custom WebRequestCycleProcessor
2) override the,
encode  method which deals with shared resources, and implement "encryption"
(or simply an obfuscated, stable alias for classes)
3) override,
org.apache.wicket.request.RequestParameters) addResourceParameters()  and
implement "decryption"

Sergey Olefir wrote:
> As I briefly mentioned before, class aliases are, IMO, a terribly
> unreliable thing to maintain. Every time someone comes up with new
> component that uses resource reference they must not forget to go and
> register the alias for it. 
> I'm predicting a 100% probability that soon enough someone will forget it
> and it'll go into production -- thus defeating the entire purpose behind
> the encryption/obfuscation :)
> And to comment on what Antoine is saying -- I'm not entirely sure what did
> you mean, but if I tried to implement encryption at
> CryptedUrlWebRequestCodingStrategy, I will have to ensure that encrypted
> URL will have format that will be fully parseable after browser appends
> relative CSS URL to it. This is manageable by, say, encrypting only the
> section of the path containing the class name. But then I'm completely
> unsure as to how properly decode it / fake request for Wicket. The
> existing code only 'fakes' parameters string -- but there are API methods
> that deal with request path as well, and if those are not correct, I'm not
> sure what issues that may cause.
> Bottom line -- it must be possible to do encryption at
> CryptedUrlWebRequestCodingStrategy, but it will take some serious digging
> to make sure all parts fit correctly. It would be far easier to e.g.
> automatically add alias in SharedResources method that deals with
> assigning the name to shared resource -- the only thing it'll require is
> to modify Application class so that e.g. getSharedResources() is not
> final.
> But I'm still hoping for some 'easy' solution that doesn't entail
> modifying Wicket source code to avoid headaches when upgrading.
> bgooren wrote:
>> The easiest way around this is to specify 
>> java.lang.String) class aliases .
>> The upside is that you control the generated URL, the downside is that
>> you have to make sure the alias is unique.

View this message in context:
Sent from the Wicket - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to