Re: recommended static image/resource strategy
My issue appears to be not new... https://issues.apache.org/jira/browse/WICKET-1889 https://issues.apache.org/jira/browse/WICKET-1700 But the fix is for v1.4.x not v1.3.6 -- View this message in context: http://www.nabble.com/recommended-static-image-resource-strategy-tp24407111p24415044.html 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
Re: recommended static image/resource strategy
My issue appears to be not new... https://issues.apache.org/jira/browse/WICKET-1889 https://issues.apache.org/jira/browse/WICKET-1700 But this only applies to v1.4. -- View this message in context: http://www.nabble.com/recommended-static-image-resource-strategy-tp24407111p24415043.html 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
Re: recommended static image/resource strategy
I have added a quick start to exemplifies the issue at hand. Please see https://issues.apache.org/jira/browse/WICKET-2361 for those that are interested. Thanks -- View this message in context: http://www.nabble.com/recommended-static-image-resource-strategy-tp24407111p24413328.html 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
Re: recommended static image/resource strategy
Thank Igor. Bug report has been created (WICKET-2361) Note: I was able to "work around" this issue by using QueryStringUrlCodingStrategy instead of the BookmarkablePageRequestTargetUrlCodingStrategy via the WebApplication.mountBookmarkablePage() method. From: Igor Vaynberg To: users@wicket.apache.org; Doug Leeper Sent: Thursday, July 9, 2009 10:13:05 AM Subject: Re: recommended static image/resource strategy it seems like a bug in ServletWebRequest#getRelativePathPrefixToWicketHandler(), you might want to subclass that, check for those two params in the url, and add an additional ../.. as a hack for right now. also open a jira issue for us to fix it. -igor On Wed, Jul 8, 2009 at 2:46 PM, Doug Leeper wrote: > Our app has been working great this past year but we recently encountered a > strange behavior and wanted to get the communities input on how to proceed. > > Background: > >* Wicket 1.3.6 >* JDK 1.5 >* Jetty (dev) / Apache and Tomcat (prod) >* The URL to our app follows this structure http://mydomain.com/APP > where APP is the web app name. >* We have our img src tags in our HTML utilize relative pathing, i.e. > "images/check.gif". >* Our images are contained in our web app off the root webapp > directory, i.e. "images". >* Some of our pages are bookmarkable utilizing > BookmarkablePageRequestTargetUrlCodingStrategy. >* We have turned on > getPageSettings().setAutomaticMultiWindowSupport(true) in our > Application.init() method >* FireFox 3.5 (is where we are seeing the odd behavior) > The recent change was the bookmarkable pages to produce "pretty URL's" such > as http://localhost:8080/APP/myPage.html. However, we have noticed that in > some cases, i.e. open link in new tab, the bookmarkable page URL changes to > http://localhost:8080/APP/myPage.html/wicket:pageMapName/wicket-1/. The > problem we are having now is that our images are not showing up. Viewing the > source the img src shows "images/check.gif" still. > > > I understand that our URL path has changed and that is why the gif does not > show up. But what is the best approach in handling static images/resources > and with our current configuration. Should we do one or more of the > following? > > >1. Don't use setAutomaticMultiWindowSupport (we really want this > feature so back button works as expected when new browser tab or window is > opened) > >2. Use absolute path for images (FYI...we want our war to be a single > deployable unit which includes the images...by doing this, would it require > the static information (images/css/js) to be deployed differently/separately? >3. Use a different mounted resource strategy? If so, which one? > BTW...no page parameters are needed on the mounted pages in question (they > can be ignored) > >4. Have all static resources be "wicketized" by using an resource > strategy, i.e. ContextRelativeResource. (this would require a lot of code > changes...not ideal) >5. Other???Thanks in advance, > - Doug > > BTW...My gut is pointing to #3 is the solution.
Re: recommended static image/resource strategy
it seems like a bug in ServletWebRequest#getRelativePathPrefixToWicketHandler(), you might want to subclass that, check for those two params in the url, and add an additional ../.. as a hack for right now. also open a jira issue for us to fix it. -igor On Wed, Jul 8, 2009 at 2:46 PM, Doug Leeper wrote: > Our app has been working great this past year but we recently encountered a > strange behavior and wanted to get the communities input on how to proceed. > > Background: > > * Wicket 1.3.6 > * JDK 1.5 > * Jetty (dev) / Apache and Tomcat (prod) > * The URL to our app follows this structure http://mydomain.com/APP > where APP is the web app name. > * We have our img src tags in our HTML utilize relative pathing, i.e. > "images/check.gif". > * Our images are contained in our web app off the root webapp > directory, i.e. "images". > * Some of our pages are bookmarkable utilizing > BookmarkablePageRequestTargetUrlCodingStrategy. > * We have turned on > getPageSettings().setAutomaticMultiWindowSupport(true) in our > Application.init() method > * FireFox 3.5 (is where we are seeing the odd behavior) > The recent change was the bookmarkable pages to produce "pretty URL's" such > as http://localhost:8080/APP/myPage.html. However, we have noticed that in > some cases, i.e. open link in new tab, the bookmarkable page URL changes to > http://localhost:8080/APP/myPage.html/wicket:pageMapName/wicket-1/. The > problem we are having now is that our images are not showing up. Viewing the > source the img src shows "images/check.gif" still. > > > I understand that our URL path has changed and that is why the gif does not > show up. But what is the best approach in handling static images/resources > and with our current configuration. Should we do one or more of the > following? > > > 1. Don't use setAutomaticMultiWindowSupport (we really want this > feature so back button works as expected when new browser tab or window is > opened) > > 2. Use absolute path for images (FYI...we want our war to be a single > deployable unit which includes the images...by doing this, would it require > the static information (images/css/js) to be deployed differently/separately? > 3. Use a different mounted resource strategy? If so, which one? > BTW...no page parameters are needed on the mounted pages in question (they > can be ignored) > > 4. Have all static resources be "wicketized" by using an resource > strategy, i.e. ContextRelativeResource. (this would require a lot of code > changes...not ideal) > 5. Other???Thanks in advance, > - Doug > > BTW...My gut is pointing to #3 is the solution. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
recommended static image/resource strategy
Our app has been working great this past year but we recently encountered a strange behavior and wanted to get the communities input on how to proceed. Background: * Wicket 1.3.6 * JDK 1.5 * Jetty (dev) / Apache and Tomcat (prod) * The URL to our app follows this structure http://mydomain.com/APP where APP is the web app name. * We have our img src tags in our HTML utilize relative pathing, i.e. "images/check.gif". * Our images are contained in our web app off the root webapp directory, i.e. "images". * Some of our pages are bookmarkable utilizing BookmarkablePageRequestTargetUrlCodingStrategy. * We have turned on getPageSettings().setAutomaticMultiWindowSupport(true) in our Application.init() method * FireFox 3.5 (is where we are seeing the odd behavior) The recent change was the bookmarkable pages to produce "pretty URL's" such as http://localhost:8080/APP/myPage.html. However, we have noticed that in some cases, i.e. open link in new tab, the bookmarkable page URL changes to http://localhost:8080/APP/myPage.html/wicket:pageMapName/wicket-1/. The problem we are having now is that our images are not showing up. Viewing the source the img src shows "images/check.gif" still. I understand that our URL path has changed and that is why the gif does not show up. But what is the best approach in handling static images/resources and with our current configuration. Should we do one or more of the following? 1. Don't use setAutomaticMultiWindowSupport (we really want this feature so back button works as expected when new browser tab or window is opened) 2. Use absolute path for images (FYI...we want our war to be a single deployable unit which includes the images...by doing this, would it require the static information (images/css/js) to be deployed differently/separately? 3. Use a different mounted resource strategy? If so, which one? BTW...no page parameters are needed on the mounted pages in question (they can be ignored) 4. Have all static resources be "wicketized" by using an resource strategy, i.e. ContextRelativeResource. (this would require a lot of code changes...not ideal) 5. Other???Thanks in advance, - Doug BTW...My gut is pointing to #3 is the solution.
