7 Replies Latest reply: Oct 11, 2012 1:17 PM by Jim.Marion-Oracle RSS

    Portal Branding: Multiple Homepages with different look & feel

      Given a requirement where we'll have a few homepages sporting different looks, like for example: 1 homepage will have menu tabs, others won't; 1 homepage should show the company's logo, others won't; each homepage will have its own Title text shown etc. What's the best way to achieve this?

      Some of the menu tabs will be dynamic as well. That means, depending on the role of the user certain tabs will be shown/hidden.

      Currently we tried to use Portal Themes but ran into some issues with it (i.e. users opening multiple tabs with different homepages then toggling between them and clicking links. this causes incorrect header/menu tabs being loaded). We also tried to override the PORTAL_HP_NEW_HEADER_UNI in the respective homepage CREF (with override i mean adding in a CREF Attribute of PORTAL_HP_NEW_HEADER_UNI and then the customized HTML header object as value) but that doesn't seem to work.

      I have limited exposure to Portal so any input would be appreciated.

      PT: 8.52
      Portal Solutions: 9.1

      Edited by: 964367 on Oct 10, 2012 1:33 AM
        • 1. Re: Portal Branding: Multiple Homepages with different look & feel
          John van der Kooij
          Did you assign your themes to specific roles? If you have multiple roles mixing up themes then your priorities might be the same for that set of roles on those specific themes.

          Information on Assigning Themes to Roles: http://docs.oracle.com/cd/E28003_01/ps91fp1pbr0/eng/psbooks/psbr/htm/psbr09.htm#ge0bf214a544bf14c_ef90c_10e52fc3b52__7c1c
          • 2. Re: Portal Branding: Multiple Homepages with different look & feel
            If I understand correctly, for a specific user logged into PeopleSoft, on one tab the user should see a header with a logo and tabs. For another tab, the user should see no logo and possibly no tabs. If the same user should see different layouts depending on tabs, then role based branding will not satisfy your requirements. HTML Layout overrides through CREF attributes, however, will satisfy your requirements. I have hidden the tab strip in a portal tab by adding the PORTAL_HP_USER_TEMPLATE CREF attribute and using CSS to hide the tab strip. Since the user can access the tab strip from other tabs, I didn't find it necessary to actually remove it, just hide it. The HTML definitions you can override are listed in this very old document: https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?type=DOCUMENT&id=748088.1.

            I have not overridden the header to specify different colors, logos, etc. I'm not sure that is possible through an override. The way I change the header is to override PORTAL_HP_USER_TEMPLATE to add a CSS class to the body element. This allows me to write CSS with a selector specific to that tab. Through CSS I can change the color, location, background image for a logo region, hide the logo, etc.

            Just FYI, making the header the same across all pages and tabs is an intentional design decision by Oracle. The idea is to put common items into a global header and keep it consistent so users always have that common area to execute common tasks.
            • 3. Re: Portal Branding: Multiple Homepages with different look & feel
              @John: No. No role specific themes. The way we did it is that in the Theme we specified a custom header and in that custom header, the menu tabs are dynamically built using a bind variable that calls an application class. The app class checks the role of the user. If the user has say, an Admin role then the corresponding Administration tab gets hidden.

              *The menu tabs are created using CSS similar to http://tinyurl.com/66yugf.

              @Jim: Hi. Happy to see you replying to my question (nice book btw.. have it :)). Yes. We have actually used HTML Layout Overrides in the CREF of some of these homepages but we can't seem to override the PORTAL_HP_NEW_HEADER_UNI. I thought I can do something like:

              Homepage 1: specify an override for PORTAL_HP_NEW_HEADER_UNI -- named PORTAL_HP_NEW_HEADER_HP1 -- that has a static text of say, HOMEPAGE 1, with a company logo and 2 menu tabs (say Home & Administration). There should be some code that will trigger to check if the user has an Admin role. If so, show the Administration tab, else hide it.

              Homepage 2: specify an override for PORTAL_HP_NEW_HEADER_UNI -- named PORTAL_HP_NEW_HEADER_HP2 -- that has a static text of say, HOMEPAGE 2, with a company logo and no menu tabs.

              Homepage 3: specify an override for PORTAL_HP_NEW_HEADER_UNI -- named PORTAL_HP_NEW_HEADER_HP3 -- that has a static text of say, HOMEPAGE 3, no company logo and 3 menu tabs (all of which will be visible to all users).

              ... but as I said, the overrides aren't working. It was showing the peoplesoft delivered look based on PORTAL_HP_NEW_HEADER_UNI (eg the one with the Oracle logo on it etc). We've bounced the Appserver and cleared the cache several times but to no avail.
              • 4. Re: Portal Branding: Multiple Homepages with different look & feel
                We can't seem to override the PORTAL_HP_NEW_HEADER_UNI
                Right. I'm not sure you can override that particular HTML definition. It isn't included in the document at https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?type=DOCUMENT&id=748088.1. There are a couple of ways to override the appearance, structure, etc of a tab. The first is what I mentioned above where you override PORTAL_HP_USER_TEMPLATE to add a CSS class for each tab, and then add CSS to change the appearance (even hide elements, etc). Another way is to use App Classes to insert elements based on the tab identified in the %Request.

                I am very glad you find the book useful!
                • 5. Re: Portal Branding: Multiple Homepages with different look & feel
                  Hi Jim.. just a couple of things:

                  1. Is the link you've given correct? It's pointing to EPI: Payroll Interface COBOL Process performance [ID 610185.1]. :)

                  2. Currently we track the homepage being accessed using a query parameter named tab (and use %Request.getParameter("tab") in the app class). Based on the tab parameter value, we load the corresponding header. Now, since there are links within the homepage, we had to track where those links have been activated, and for that we use a global variable (so that the app knows which header to load/use). All is well until the user loads up 2 or more homepages at any given time (eg multiple tabs or windows). In such a case, the global variable gets populated with the latest tab that was loaded... so when the user goes to another tab/window with a different homepage loaded and clicks on a link, then the wrong header gets loaded (i.e. the header of the recently clicked homepage).

                  I'll try overriding PORTAL_HP_USER_TEMPLATE individually. Hope that will work.

                  Many thanks for the inputs / replies.
                  • 6. Re: Portal Branding: Multiple Homepages with different look & feel
                    PS: the above post was mine. Didn't realize that using a colleague's Oracle Support ID to check the document Jim provided would mean a change in username here too. :)
                    • 7. Re: Portal Branding: Multiple Homepages with different look & feel
                      That is Odd. When I click the link, I get a document titled "PeopleSoft Enterprise Portal 8.8 GUI ConfigurationTips [ID 748088.1]". Anyway... if the link doesn't work, then log into My Oracle Support and search for a document with that name.

                      As far as tracking the last visited homepage tab, I don't think either approach will work. PORTAL_HP_USER_TEMPLATE will only help with home pages. It will have no impact on transaction pages.

                      Here is where the "tab" paradigm breaks down. The tab paradigm is based off the pendaflex/file folder concept. In a filing cabinet, we expect everything within a file folder to be related to that folder. Likewise, in the application, if we start with a particular tab, we expect every link we click to pertain to the tab so that it looks like we are still browsing documents within the same file folder. That is NOT how PeopleSoft was designed to work, and it makes the tab paradigm seem a bit awkward. A tab is really only relevant on the homepage and the filing cabinet analogy only classifies homepages. Once you leave a homepage, you have technically left the filing cabinet. That is why the default portal installation sets all tabs to be inactive once you browse into a transaction. Basically, the PeopleSoft filing cabinet metaphor was designed for grouping pagelets, not transactions/components. The fact that the filing cabinet (tab strip) stays visible after leaving the home page is just for convenience.

                      Now, how to solve the problem...

                      Each time you click "new window" you get a new state block on the web server. You can identify the state block by the _# in the URL. For example, if your site name is ps and you click new window, you will get a URL that has something like ps_1 in the URL. This is what allows you to be in two components at the same time without seeing the "this is not the last component..." error. That state block number will persist until you click the home link or one of the tabs. Once you click a tab, it takes you back to the base state block. This means each time you are on a homepage tab, you will always be at the base state block. What am I saying here? Once you visit an alternate homepage tab in a different window, both windows will be in the same state block and changes to one component will mess up the session state of the other component making one of the windows worthless. If this is not your experience, then you can use the global variable option by converting the variable to an array and using the state block ID from the URL as the index into the array.

                      Here is another option, but it requires a bit of JavaScript hacking. You could add the tab ID to every form post as a hidden form element by adding JavaScript to PT_COMMON or PT_COPYURL (depending on your tools release). This would ensure that the tab ID was there in the request parameters every time the header frame changes.