Ok, scratch that comment too...

I see Antoine dug up an old thread of yours where you already found out
about the possibility to override WebRequestCodingStrategy.

I also see that Antoine created WICKET-2731 and that it has been closed as
resolved/fixed, so there should be some hooks available in wicket 1.4.7
(which is to be release shortly according to the dev mailing list).

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 
>> http://wicket.apache.org/docs/1.4/org/apache/wicket/SharedResources.html#putClassAlias(java.lang.Class,
>> 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 Nabble.com.

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to