Jetspeed 2
  1. Jetspeed 2
  2. JS2-347

a portal cannot mix different layout decorations w/o problems

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-FINAL
    • Fix Version/s: 2.0-FINAL
    • Component/s: Aggregation
    • Labels:
      None

      Description

      While testing the changes in the content server, Juan and myself detected that
      one of the css included in the page, and all the images, have the same name for every decorator.
      Namely content/css/styles.css

      This produces strange interactions with caching whenever there are fragments
      using two different layout decorations in the same page, or the user switches pages.

      The icons and styles are taken apparently randomly from both stylesheets, which
      plays havoc with the decoration.

      It looks like a solution for this would be to have the decoration name in the resource,
      like:
      now: content/images/edit.gif -> content/THEME/images/edit.gif
      now: content/css/styles.css and content/THEME/css/styles.css -> content/THEME/css/layout-styles.css and content/THEME/css/portlet-styles.css

      Not sure if it was a bug or intended in the last batch of changes by Scott, so I just post here for clarification.
      Scott?

      1. content.patch
        2 kB
        Santiago Gala

        Issue Links

          Activity

          Santiago Gala created issue -
          Hide
          Scott T Weaver added a comment -

          Santiago,

          This a bug. Though I think this has always been true as the last batch of content server fixes only targeted dealing with cache controls for browsers correctly and did not touch the resource resolution code. This has probably been an issue since the advent of the content server and could probably be solved by correctly "namespacing" the the css's like you suggest.

          When I first put together the content server, there was no support for nested layouts and hence no need to worry about this isssue. Now that we have nested layouts, we need to revist the way we are doing things.

          Regards,
          -Scott

          Show
          Scott T Weaver added a comment - Santiago, This a bug. Though I think this has always been true as the last batch of content server fixes only targeted dealing with cache controls for browsers correctly and did not touch the resource resolution code. This has probably been an issue since the advent of the content server and could probably be solved by correctly "namespacing" the the css's like you suggest. When I first put together the content server, there was no support for nested layouts and hence no need to worry about this isssue. Now that we have nested layouts, we need to revist the way we are doing things. Regards, -Scott
          Hide
          Randy Watler added a comment -

          Ate, DST, and myself all voted +1 on the theme name in the content url approach to solving this issue. We would ideally like to add the feature in a way that existing decorators work unchanged, (if at all possible), providing there is only one decorator and/or assets have unique file names.

          Show
          Randy Watler added a comment - Ate, DST, and myself all voted +1 on the theme name in the content url approach to solving this issue. We would ideally like to add the feature in a way that existing decorators work unchanged, (if at all possible), providing there is only one decorator and/or assets have unique file names.
          Hide
          Santiago Gala added a comment -

          I had a look into implementing this, and couldn't make it work.

          I'm thinking that trying to outsmart tomcat (or other http server like apache) is not exactly a good idea,
          and I can't find benefits that can't be reaped by a URI scheme that includes the theme name in it.

          for instance, decorations' resources could go under:

          webapps/content/THEME/images css scripts, and we would just use a conventional static webapp
          to serve them.

          for decorations, a simple copy of the content skipping declared templates would be enough to get us going,
          and tomcat would take care of those resources, with all the benefits of a standard implementation of
          HTTP/1.1

          Show
          Santiago Gala added a comment - I had a look into implementing this, and couldn't make it work. I'm thinking that trying to outsmart tomcat (or other http server like apache) is not exactly a good idea, and I can't find benefits that can't be reaped by a URI scheme that includes the theme name in it. for instance, decorations' resources could go under: webapps/content/THEME/images css scripts, and we would just use a conventional static webapp to serve them. for decorations, a simple copy of the content skipping declared templates would be enough to get us going, and tomcat would take care of those resources, with all the benefits of a standard implementation of HTTP/1.1
          Hide
          Scott T Weaver added a comment -

          I am currently working on a possible solution for this right now. Give me a day or two and I should be able to tell whether or not we can make this work.

          Show
          Scott T Weaver added a comment - I am currently working on a possible solution for this right now. Give me a day or two and I should be able to tell whether or not we can make this work.
          Hide
          Santiago Gala added a comment -

          This is how far I arrived, Scott, just in case it saves some time there.

          It was working for the css generation. images and/or scripts and other content is missing and trickier, specially the img src of the action gifs.

          Show
          Santiago Gala added a comment - This is how far I arrived, Scott, just in case it saves some time there. It was working for the css generation. images and/or scripts and other content is missing and trickier, specially the img src of the action gifs.
          Santiago Gala made changes -
          Field Original Value New Value
          Attachment content.patch [ 12311951 ]
          Hide
          Santiago Gala added a comment -

          I forgot to say that this requires renaming of portlet/html/THEME/css/styles.css to -> portlet-styles.css, which actually looks like a good idea. I didn't change the styles.css in layout to layout-styles.css, though it looks like a good idea to lower the confusion levels.

          Show
          Santiago Gala added a comment - I forgot to say that this requires renaming of portlet/html/THEME/css/styles.css to -> portlet-styles.css, which actually looks like a good idea. I didn't change the styles.css in layout to layout-styles.css, though it looks like a good idea to lower the confusion levels.
          Hide
          Scott T Weaver added a comment -

          I like the naming policy. It does make things much clearer for those looking at htings for the first time.

          Show
          Scott T Weaver added a comment - I like the naming policy. It does make things much clearer for those looking at htings for the first time.
          Hide
          Michael Lipp added a comment -

          I think my problem is related with this. Currently, the error, info etc. icons are not displayed. The styles.css references them as e.g. "url(content/tigris/images/icon_info_sml.gif)". When I debug, I find that SimpleContentLocator evaluates a real path that contains tigris twice (".../tigris/tigris/..."). And of course the icons are not found. Is this related to the issue dicussed here? Or should I open a new issue?

          Show
          Michael Lipp added a comment - I think my problem is related with this. Currently, the error, info etc. icons are not displayed. The styles.css references them as e.g. "url(content/tigris/images/icon_info_sml.gif)". When I debug, I find that SimpleContentLocator evaluates a real path that contains tigris twice (".../tigris/tigris/..."). And of course the icons are not found. Is this related to the issue dicussed here? Or should I open a new issue?
          Hide
          Santiago Gala added a comment -

          Don't know how the hell one can change the fix release of a jira bug, but I'm -1 on releasing 2.0 without this one fixed.

          Show
          Santiago Gala added a comment - Don't know how the hell one can change the fix release of a jira bug, but I'm -1 on releasing 2.0 without this one fixed.
          David Sean Taylor made changes -
          Assignee Scott T Weaver [ weaver ]
          Fix Version/s 2.0-FINAL [ 10940 ]
          Affects Version/s 2.0-M4 [ 11186 ]
          Affects Version/s 2.0-FINAL [ 10940 ]
          Scott T Weaver made changes -
          Link This issue depends upon JS2-398 [ JS2-398 ]
          Hide
          Ate Douma added a comment -

          This one has been fixed long time ago.

          Show
          Ate Douma added a comment - This one has been fixed long time ago.
          Ate Douma made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]

            People

            • Assignee:
              Scott T Weaver
              Reporter:
              Santiago Gala
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development