You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Doug Leeper (JIRA)" <ji...@apache.org> on 2009/07/09 17:44:15 UTC

[jira] Created: (WICKET-2361) Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window

Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window
--------------------------------------------------------------------------------------------------------

                 Key: WICKET-2361
                 URL: https://issues.apache.org/jira/browse/WICKET-2361
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 1.3.6
         Environment: Wicket 1.3.6
JDK 1.5
Jetty (dev)
Apache / Tomcat (prod)
            Reporter: Doug Leeper


Background:

    * 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???

Current work around is to use the QueryStringUrlCodingStrategy instead of the default BookmarkablePageRequestTargetUrlCodingStrategy via WebApplication.mountBookmarkablePage.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (WICKET-2361) Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-2361.
-----------------------------------

    Resolution: Invalid
      Assignee: Igor Vaynberg

you are doing this in your code:

image1.add(new AttributeModifier("src", true, new Model("images/book_wia.png")));

so you are manually assigning the url - in this case you are responsible for constructing the correct one. the best thing you can do is use ContextImage. you said yourself all your urls are off your context root, this is exactly what ContextImage was built for.

alternatively instead of using an attribute modifier you can add the src attribute using ContextPathGenerator - this is what ContextImage uses.



> Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-2361
>                 URL: https://issues.apache.org/jira/browse/WICKET-2361
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.6
>         Environment: Wicket 1.3.6
> JDK 1.5
> Jetty (dev)
> Apache / Tomcat (prod)
>            Reporter: Doug Leeper
>            Assignee: Igor Vaynberg
>         Attachments: issue2361.jar
>
>
> Background:
>     * 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???
> Current work around is to use the QueryStringUrlCodingStrategy instead of the default BookmarkablePageRequestTargetUrlCodingStrategy via WebApplication.mountBookmarkablePage.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (WICKET-2361) Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window

Posted by "Doug Leeper (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729366#action_12729366 ] 

Doug Leeper commented on WICKET-2361:
-------------------------------------

These issues appear to be related:

https://issues.apache.org/jira/browse/WICKET-1889
https://issues.apache.org/jira/browse/WICKET-1700

However, the fix is for v1.4.x.

We can't move to 1.4.x just yet....any chance the fix will be available in 1.3.7?

> Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-2361
>                 URL: https://issues.apache.org/jira/browse/WICKET-2361
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.6
>         Environment: Wicket 1.3.6
> JDK 1.5
> Jetty (dev)
> Apache / Tomcat (prod)
>            Reporter: Doug Leeper
>         Attachments: issue2361.jar
>
>
> Background:
>     * 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???
> Current work around is to use the QueryStringUrlCodingStrategy instead of the default BookmarkablePageRequestTargetUrlCodingStrategy via WebApplication.mountBookmarkablePage.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WICKET-2361) Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window

Posted by "Doug Leeper (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Doug Leeper updated WICKET-2361:
--------------------------------

    Attachment: issue2361.jar

Here is a quick start that has simplified my situation.

I have included how we are assigning the images.  I was not completely correct in the "static" image reference.  They are static but the src is dynamically assigned.

In any case, when running the application, the following link exemplifies our issue:

http://localhost:8080/quickstart/second.html/wicket:pageMapName/wicket-1/

The wicket:pageMapName/wicket-1 gets appended the URL in our dev/prod environment.  I couldn't recreate the auto appending with this quick start...not sure why it is doesn't happen.

> Static images on on bookmarkable pages not showing up when right click and open a new browser tab/window
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-2361
>                 URL: https://issues.apache.org/jira/browse/WICKET-2361
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.6
>         Environment: Wicket 1.3.6
> JDK 1.5
> Jetty (dev)
> Apache / Tomcat (prod)
>            Reporter: Doug Leeper
>         Attachments: issue2361.jar
>
>
> Background:
>     * 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???
> Current work around is to use the QueryStringUrlCodingStrategy instead of the default BookmarkablePageRequestTargetUrlCodingStrategy via WebApplication.mountBookmarkablePage.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.