Hey Alec,
I think Martin was referring to his earlier reply on Sep 06, 2012; 2:02pm from
the thread when he asked you to try and extend PackageResourceReference and
then mount your resources as:
mountResource("/global", new MyPackageResourceReference())
Give that a try and let us know how it works out :)
~ Thank you,
Paul Bors
PS: Martin would know better, he's a developer on Wicket's team (you can tell
from his e-mail address).
I'm just another fellow Wicket-er.
-----Original Message-----
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Wednesday, September 12, 2012 11:04 AM
To: users@wicket.apache.org
Subject: Re: Wicket 1.5 migration questions
Hi Alec,
See my previous response. Try it and then come back.
On Wed, Sep 12, 2012 at 5:43 PM, Alec Swan <alecs...@gmail.com> wrote:
> Paul, I looked at IResource and ResourceReference classes but still
> can't figure out how to implement an alternative to putClassAlias.
>
> In 1.4 you could do putClassAlias(GlobalResourceScope.class, "global")
> and after that all new ResourceReference(GlobalResourceScope.class,
> "relative/path/file.js") would automatically be accessible from
> http://../global/relative/path/file.js. So, I could easily call
> response.renderJavaScript(new
> JavaScriptReference(GlobalResourceScope.class,
> "relative/path/file.js")) anywhere in the code without mounting
> relative/path/file.js explicitly in Application#init.
>
> In 1.5 I have three options: mountResource, mountPackage and
> mount(IRequestMapper).
>
> mountResource requires me to mount each individual resource file in
> Application, which is not what I want because we have a lot of
> resource files and we add them often.
> mountPackage works with pages only, but reflects the concept that I
> need to implement for resource files.
> mount(IRequestMapper) - I think I should be able to use this method to
> implement what I want. I noticed that there are a few IRequestMapper
> implementations, which one should I extend?
>
> Thanks,
>
> Alec
>
> On Tue, Sep 11, 2012 at 2:32 PM, Paul Bors <p...@bors.ws> wrote:
>> I never said that, I just gave you an alternate way of achieving the
>> same thing :)
>>
>> I'm not familiar nor did I ever use the
>> SharedResources#putClassAlias() method, but given the API for
>> SharedResources it seems to have been moved or removed.
>>
>> Wicket 1.4.x (has it at):
>> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/SharedResource
>> s.html# putClassAlias(java.lang.Class, java.lang.String)
>>
>> Wicket 1.5.x (does not list it, at least not in the same class name):
>> http://wicket.apache.org/apidocs/1.5/org/apache/wicket/SharedResource
>> s.html
>>
>> If adding the resources to the root of the war works, why bother?
>> Unless you're packaging a reusable component or you use dynamic
>> resources, but having a static URL might indicate otherwise.
>>
>> Take a look at IResource and the many different implementations of it
>> and see which one can help you most, or implement your own either
>> from scratch or extending an existing one :)
>> http://wicket.apache.org/apidocs/1.5/org/apache/wicket/request/resour
>> ce/IRes
>> ource.html
>>
>> ~ Thank you,
>> Paul Bors
>>
>> -----Original Message-----
>> From: Alec Swan [mailto:alecs...@gmail.com]
>> Sent: Tuesday, September 11, 2012 11:42 AM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket 1.5 migration questions
>>
>>> I take it by global you mean http://myServer:###/myWebApp/global?
>> Yes.
>>
>>> If so, why don't you just add the folder to the root of your war?
>> Good point, I could do that, but I'd rather keep my current folder
>> structure.
>>
>> So, does it mean that putClassAlias functionality is gone in 1.5?
>>
>> Thanks,
>>
>> Alec
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
