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

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