Re: Can't get Javascript filtering to work
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 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 wrote: >> Hi, >> >> On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan 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-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
Re: Can't get Javascript filtering to work
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 wrote: > Hi, > > On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Can't get Javascript filtering to work
Hi, On Thu, Apr 28, 2011 at 9:50 PM, Alec Swan 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 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 >> 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-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 > > -- 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
Re: Can't get Javascript filtering to work
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 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 > 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-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
Re: Can't get Javascript filtering to work
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 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-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
Re: Can't get Javascript filtering to work
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-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
