ShowTable of Contents
This article discusses one possible custom portal theme profile, for use with Web Experience Factory portlets that leverage the Dojo framework, and suggests where to look for more information on what theme modules are available for use in your own custom profiles. While this article uses the current release (IBM WebSphere Portal version 8.5), the techniques are applicable to the last several releases of WebSphere Portal (since 126.96.36.199) and you should refer to the product documentation provided with the particular version of portal that you are planning to deploy to.
Portal Theme Modules and Profiles
As described in the portal documentation, the module framework
documentation for more information and details on modules and profiles and what portal provides out of the box for these configurable extensions.
Full Profile - and why to avoid it
Portal provided a theme profile named "Full" in versions 188.8.131.52 through 8.0.0.x. This loaded as many modules up front as possible, to help people get started quickly without JS errors due to missing components. Unfortunately, this could lead to loading a lot of unnecessary artifacts up front that were never used by the page. Because it was so simple to get going with this profile, it made it not just possible, but likely that developers would forget to go back and create a more optimized profile later for production use (and related FVT/UAT cycles).
The Full Profile should not really be used for production use (or even past initial prototype, in my personal opinion), given that most portlets do not require or leverage many of the components used by the full profile.
As of IBM WebSphere Portal version 8.5, to avoid such accidental inefficient profile use, the Full profile is no longer provided with the out of the box theme profiles, which makes it even more important to learn about your options in this space.
WebSphere Portal v8.5 Profiles and Dojo
WebSphere Portal version 8.5 provides an out of the box set of theme profiles
which define modules typically used by portal pages associated with such profiles.
Looking through the documentation for those "Included Profiles", you will notice that there is a matching set of profiles with and without Dojo (eg, Deferred with Dojo
, Basic Content with Dojo
, Lightweight with Dojo).
Other profiles (specifically Deferred, Basic Content, Lightweight), do not load Dojo in the page by default, when used as the profile for a given portal page.
While the descriptions for those profiles state that they "include Dojo" what that really means is that it includes the Dojo core module which defines Dojo itself, not that it loads all the Dojo modules that your portlet applications may leverage. These profiles provide a good starting point for testing your prototypes (and are smaller than the prior release's "Full" profile) but using them can result in your portal pages requiring many more http requests to complete, in order to load all the individual Dojo classes used by your portlets. So again, while you may use these profile(s) to get started testing your first prototype portlets, it is best to configure a custom profile for your application that loads the modules necessary, no more and no less.
I suggest that if you are building portlets that leverage the Dojo framework (as most Web Experience Factory portlets do) that you familiarize yourself with the list of Dojo modules available for use in Portal Theme Profiles
for the particular version of IBM WebSphere Portal that you plan to deploy to.
A Custom Portal Theme Profile
For this particular example, I'm using a typical Web Experience Factory portlet that leverages Dojo for smart refresh (partial page refresh), input field widgets and field validation, paging controls and some layout. Not all Web Experience Factory portlets leverage the same exact set of Dojo classes, so the actual modules and actual profile you should use may vary from the example used in this article.
For example purposes, assume I started with the Deferred with Dojo
profile that my application team has identified as having likely capabilities needed by my portal application.
I see that Dojo was loaded successfully and that the Dojo widgets on the page (paging dropdown menu, input fields input field validation etc) are working correctly, but when I force a full page refresh, I see that there are literally dozens of http requests required to complete the page, in part due to the individual Dojo classes being loaded as separate requests.
Determine Which Modules To Add
I then look through the list of Dojo classes provided by the Dojo modules
in the portal product documentation and compare that info against the list of Dojo classes loaded via individual http requests in my browser debugger's network tab, to determine which modules I should add to a custom profile to include the loading of those classes in the portal's resource aggregation request for portal pages using my custom profile. I make a note of that list of Dojo modules and hang onto it for later.
For example: dojo_dom, dojo_app, dojo_fmt, dijit, dijit_app, dijit_menu, dijit_form, dijit_editor, dijit_layout_basic, dijit_layout_ext, dijit_tree, dojox_layout_basic, dojox_html_basic, dojox_layout_ext
Make a Customized Profile
For this example, since my team identified "Deferred with Dojo" as the profile to start with, I use a WebDav tool to download and make a copy of profile_dojo_deferred.json from /fs-type1/themes/Portal8.5/profiles/ and I name this copied file profile_more
dojo_deferred.json because it will include more dojo modules than the original profile that it was copied from.
Opening this copy in editor, I see that it defines the list of modules in JSON format at the top of the file like this:
In this section, I then add the additional Dojo modules identified in the above step to the existing list of moduleIDs
, ensuring that I add a comma to the existing last module, before adding the additional modules:
I then search for the name and description for this profile further down in this copied profile_moredojo_deferred.json file and change both to a custom name (for my simple example, I change only the English version of the name and description, but you can see from the existing values how you would do the same for other languages).
I then upload (via my WebDav tool) this new customized profile, to the same location that I had downloaded profile_dojo_deferred.json from.
For Portal version 8.5, refer to the product documentation on Adding or removing a module from a profile for information on how to invalidate the resource aggregator cache, so that it will pick up your changes to profiles and then refer to Specifying profiles with the user interface for information on how to tell it to use your new custom profile for particular portal page(s).
For Portal 8.5 CF3 AND later, please note that CF3 removed "wp_one_ui_dijit" from the module dependencies that get pulled in with "Deferred with Dojo" and possibly other "with Dojo" profiles, but that module includes CSS styles that are required for many Dojo widgets (used by Web Experience Factory and other portlets leveraging Dojo). Because of that change in the default profiles as of 8.5 CF3 and later, you should also add wp_one_ui_dijit to the list of modules that your custom profile depends on, if you are using Dojo with your WEF portlets.
For Portal 8.5 CF6 and later, you may need to add wp_one_ui module dependency to your custom theme profile, depending on which of the core portal profiles you're creating a custom profile from (in addition to wp_one_ui_dijit as mentioned above), if you are using the Web Experience Factory Split Pager (paging links/dropdown at the top/bottom of a multi--page tabular layout) as the split pager styles rely on the wp_one_ui styles which have been removed from default profiles in recent CFs, to further tune the out of the box portal experience for those that don't need those styles.
For Portal version 8.0.0.x, refer to the product documentation on Adding or removing a ready-to-use module to a theme for information on creating a new profile and incorporating its use in your portal pages by Specifying profile files in the resourceaggregation.profile page metadata
Testing the Page
I'm not going to use any absolute numbers (of http requests) here because the number will vary based on which Dojo classes the portlet(s) use, and may vary due to portal and/or WEF fixpacks and/or feature packs introduced by the time you read this article. For the particular sample orders portlet used in preparing this article, it started out incurring many dozens of http requests with the Deferred with Dojo profile and was reduced by several dozen http requests with the new custom profile (roughly half of the number that I had started with, with the out of the box 8.5 profile).
This introduction to customizing your portal theme profiles is intended to help customers do the right thing and build efficient optimized web sites rather than living with the out of the box configuration which may be set up to get things going quickly but may not be optimized for every use case. The example custom profile provided here is only an example for one particular portlet and may not be appropriate for all customers and all portlets. Start with the minimum out of the box profile for your use case and leverage the portal documentation and your browser's debugger/inspector to determine what additional modules to add to avoid additional http requests and provide no more and no less artifacts to the page than is required by your application.
IBM WebSphere Portal 8.5
Understanding the Portal v8.5 Modularized Theme
The Module Framework
Dojo Classes provided by the Dojo Modules
Adding or removing a module from a profile
IBM WebSphere Portal 8.0
Understanding the Portal 8.0 modularized theme
The Module Framework
Specifying Profile Files
Adding or removing a ready-to-use module to a theme