You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Doug Leeper <do...@yahoo.com> on 2009/07/08 23:46:35 UTC
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.
Re: recommended static image/resource strategy
Posted by Doug Leeper <do...@yahoo.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: recommended static image/resource strategy
Posted by Doug Leeper <do...@yahoo.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: recommended static image/resource strategy
Posted by Doug Leeper <do...@yahoo.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: recommended static image/resource strategy
Posted by Doug Leeper <do...@yahoo.com>.
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 <ig...@gmail.com>
To: users@wicket.apache.org; Doug Leeper <do...@yahoo.com>
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<do...@yahoo.com> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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<do...@yahoo.com> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org