You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alec Swan <al...@gmail.com> on 2011/04/27 05:18:08 UTC
Can't get Javascript filtering to work
Hello,
I would like to get my Javascript files filtered and gzipped. I added
the following code in my Application#init():
resourceSettings.setJavascriptCompressor(new DefaultJavascriptCompressor());
However, when I add a resource using the following code, I can still
see comments and white spaces in the Javascript files loaded by the
web pages:
final JavascriptResourceReference resourceRef = new
JavascriptResourceReference(scope, "/common.js");
component.add(JavascriptPackageResource.getHeaderContribution(resourceRef));
What am I doing wrong?
Also, I am struggling to understand the benefits of using shared
resources, e.g. when does it make sense to create a shared resource
for a Javascript file?
Thanks,
Alec
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Alec Swan <al...@gmail.com>.
Martin, I am not sure why you are saying that something is configured
wrong? My settings do override defaults.
Clint, I call resourceSettings.setJavascriptCompressor(new
DefaultJavascriptCompressor()) in MyApp#init() method, not in the
constructor.
Thanks,
Alec
On Fri, Apr 29, 2011 at 3:58 PM, Clint Checketts <ch...@gmail.com> wrote:
> I've seen folks get a misconfigure like this when they make the call
> in the application's constructor instead of the init() method.
>
> On Friday, April 29, 2011, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan <al...@gmail.com> wrote:
>>> Thanks, Andrea. I was running in DEVELOPMENT mode and switching to
>>> DEPLOYMENT mode fixed the problem. I hope this gets documented
>>> somewhere.
>>>
>> You are doing something wrong. MyApp#init() is called after
>> WebApplication#internalInit() so your settings should override the
>> defaults.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Clint Checketts <ch...@gmail.com>.
I've seen folks get a misconfigure like this when they make the call
in the application's constructor instead of the init() method.
On Friday, April 29, 2011, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan <al...@gmail.com> wrote:
>> Thanks, Andrea. I was running in DEVELOPMENT mode and switching to
>> DEPLOYMENT mode fixed the problem. I hope this gets documented
>> somewhere.
>>
> You are doing something wrong. MyApp#init() is called after
> WebApplication#internalInit() so your settings should override the
> defaults.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan <al...@gmail.com> wrote:
> Thanks, Andrea. I was running in DEVELOPMENT mode and switching to
> DEPLOYMENT mode fixed the problem. I hope this gets documented
> somewhere.
>
You are doing something wrong. MyApp#init() is called after
WebApplication#internalInit() so your settings should override the
defaults.
> Martin, are you saying that page rendering will not block waiting for
> the static resource to render while it will block on a component
> resource to render? Maybe I need to learn more about page locking in
> Wicket ...
Yes. The page renders an URL to the shared resource, i.e. a String.
Later the browser makes a request to this URL and this request doesn't
go to any page, so there is no locking.
Be careful to do what is needed to make the resource thread-safe.
Making it stateless is the recommended practice.
>
> Thanks,
>
> Alec
>
> On Wed, Apr 27, 2011 at 3:20 AM, Martin Grigorov <mg...@apache.org> wrote:
>> Static resources are more suitable for the cases when you want to
>> avoid page locking.
>> E.g. when you need to deliver dynamic response and there is a chance
>> that the processing will be slower or there will be more clients for
>> the same resource. Using a normal component for this will suffer that
>> only one request can use one page instance (pagemap in 1.4) at a time.
>>
>> On Wed, Apr 27, 2011 at 11:54 AM, Andrea Del Bene <ad...@ciseonweb.it> wrote:
>>> Hi Alec,
>>>
>>> are you sure you are testing your code in DEPLOYMENT mode and not in
>>> DEVELOPMENT mode?
>>>
>>> To answer your question about benefits of using shared resources, I can say
>>> that they make sense when you need to access a resource (like a picture)
>>> with
>>> an absolute path instead of a relative one (which typically is
>>> "./resource/package.of.class/pictureName.png" ).
>>>
>>>> Hello,
>>>>
>>>> I would like to get my Javascript files filtered and gzipped. I added
>>>> the following code in my Application#init():
>>>> resourceSettings.setJavascriptCompressor(new
>>>> DefaultJavascriptCompressor());
>>>>
>>>> However, when I add a resource using the following code, I can still
>>>> see comments and white spaces in the Javascript files loaded by the
>>>> web pages:
>>>> final JavascriptResourceReference resourceRef = new
>>>> JavascriptResourceReference(scope, "/common.js");
>>>>
>>>> component.add(JavascriptPackageResource.getHeaderContribution(resourceRef));
>>>>
>>>> What am I doing wrong?
>>>>
>>>> Also, I am struggling to understand the benefits of using shared
>>>> resources, e.g. when does it make sense to create a shared resource
>>>> for a Javascript file?
>>>>
>>>> Thanks,
>>>>
>>>> Alec
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Alec Swan <al...@gmail.com>.
Thanks, Andrea. I was running in DEVELOPMENT mode and switching to
DEPLOYMENT mode fixed the problem. I hope this gets documented
somewhere.
Martin, are you saying that page rendering will not block waiting for
the static resource to render while it will block on a component
resource to render? Maybe I need to learn more about page locking in
Wicket ...
Thanks,
Alec
On Wed, Apr 27, 2011 at 3:20 AM, Martin Grigorov <mg...@apache.org> wrote:
> Static resources are more suitable for the cases when you want to
> avoid page locking.
> E.g. when you need to deliver dynamic response and there is a chance
> that the processing will be slower or there will be more clients for
> the same resource. Using a normal component for this will suffer that
> only one request can use one page instance (pagemap in 1.4) at a time.
>
> On Wed, Apr 27, 2011 at 11:54 AM, Andrea Del Bene <ad...@ciseonweb.it> wrote:
>> Hi Alec,
>>
>> are you sure you are testing your code in DEPLOYMENT mode and not in
>> DEVELOPMENT mode?
>>
>> To answer your question about benefits of using shared resources, I can say
>> that they make sense when you need to access a resource (like a picture)
>> with
>> an absolute path instead of a relative one (which typically is
>> "./resource/package.of.class/pictureName.png" ).
>>
>>> Hello,
>>>
>>> I would like to get my Javascript files filtered and gzipped. I added
>>> the following code in my Application#init():
>>> resourceSettings.setJavascriptCompressor(new
>>> DefaultJavascriptCompressor());
>>>
>>> However, when I add a resource using the following code, I can still
>>> see comments and white spaces in the Javascript files loaded by the
>>> web pages:
>>> final JavascriptResourceReference resourceRef = new
>>> JavascriptResourceReference(scope, "/common.js");
>>>
>>> component.add(JavascriptPackageResource.getHeaderContribution(resourceRef));
>>>
>>> What am I doing wrong?
>>>
>>> Also, I am struggling to understand the benefits of using shared
>>> resources, e.g. when does it make sense to create a shared resource
>>> for a Javascript file?
>>>
>>> Thanks,
>>>
>>> Alec
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Martin Grigorov <mg...@apache.org>.
Static resources are more suitable for the cases when you want to
avoid page locking.
E.g. when you need to deliver dynamic response and there is a chance
that the processing will be slower or there will be more clients for
the same resource. Using a normal component for this will suffer that
only one request can use one page instance (pagemap in 1.4) at a time.
On Wed, Apr 27, 2011 at 11:54 AM, Andrea Del Bene <ad...@ciseonweb.it> wrote:
> Hi Alec,
>
> are you sure you are testing your code in DEPLOYMENT mode and not in
> DEVELOPMENT mode?
>
> To answer your question about benefits of using shared resources, I can say
> that they make sense when you need to access a resource (like a picture)
> with
> an absolute path instead of a relative one (which typically is
> "./resource/package.of.class/pictureName.png" ).
>
>> Hello,
>>
>> I would like to get my Javascript files filtered and gzipped. I added
>> the following code in my Application#init():
>> resourceSettings.setJavascriptCompressor(new
>> DefaultJavascriptCompressor());
>>
>> However, when I add a resource using the following code, I can still
>> see comments and white spaces in the Javascript files loaded by the
>> web pages:
>> final JavascriptResourceReference resourceRef = new
>> JavascriptResourceReference(scope, "/common.js");
>>
>> component.add(JavascriptPackageResource.getHeaderContribution(resourceRef));
>>
>> What am I doing wrong?
>>
>> Also, I am struggling to understand the benefits of using shared
>> resources, e.g. when does it make sense to create a shared resource
>> for a Javascript file?
>>
>> Thanks,
>>
>> Alec
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Can't get Javascript filtering to work
Posted by Andrea Del Bene <ad...@ciseonweb.it>.
Hi Alec,
are you sure you are testing your code in DEPLOYMENT mode and not in
DEVELOPMENT mode?
To answer your question about benefits of using shared resources, I can
say that they make sense when you need to access a resource (like a
picture) with
an absolute path instead of a relative one (which typically is
"./resource/package.of.class/pictureName.png" ).
> Hello,
>
> I would like to get my Javascript files filtered and gzipped. I added
> the following code in my Application#init():
> resourceSettings.setJavascriptCompressor(new DefaultJavascriptCompressor());
>
> However, when I add a resource using the following code, I can still
> see comments and white spaces in the Javascript files loaded by the
> web pages:
> final JavascriptResourceReference resourceRef = new
> JavascriptResourceReference(scope, "/common.js");
> component.add(JavascriptPackageResource.getHeaderContribution(resourceRef));
>
> What am I doing wrong?
>
> Also, I am struggling to understand the benefits of using shared
> resources, e.g. when does it make sense to create a shared resource
> for a Javascript file?
>
> Thanks,
>
> Alec
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org