Pega Upgrade Center cross-browser compliance FAQs
This article lists frequently asked questions regarding Pega Upgrade Center cross-browser compliance.
Questions
- How do I achieve a cross-browser compliant user interface (HTML5 Standards Mode) after upgrading to Pega 7?
- What are the steps for enabling HTML5 in my application?
- Does Pega 7 have any report listing the rules to be modified for HTML5 compliance?
- Are fixed portals supported in Pega 7?
- If my application portal has panel sets, do I need to modify them?
- How can I troubleshoot the WorkArea gadget referenced in my composite portal that is not rendering correctly?
- How can I create a tabbed rendition of my WorkArea using a Dynamic Container?
- Should Flow action rules be upgraded or updated?
- Should the Action Section be upgraded?
- What is a dynamic layout? Should all layouts be updated to dynamic layouts?
- Will deprecated controls work across browsers after upgrade to Pega 7?
- Is there a ready reference that contains details about all deprecated controls?
- What are the different changes required to be made for section rules?
- I have hand-coded CSS, will it continue to work after upgrading to Pega 7?
- Should custom JavaScript be rewritten after upgrade to Pega 7?
- How can I force the portals to render in Standards and Compatible modes of the browser?
- Can I restrict the browser version for rendering a portal?
- My application has many ListView controls, should all be re-implemented?
- How can I achieve List-to-List control capabilities in Pega 7?
- Do I need to rewrite the code where any ActiveX object has been referenced?
- Are there any equivalent objects for each of the existing ActiveX controls that are supported across browsers?
- I have imported my application built in an older release of PRPC into Pega 7. Do I need to follow any additional steps?
Answers
How do I achieve a cross-browser compliant user interface (HTML5 Standards Mode) after upgrading to Pega 7?
The execution of the Revalidate and Save utility for all of the User Interface (UI) rules after upgrading to Pega 7 is a pre-requisite for viewing information in the HTML5 Readiness Landing page.
What are the steps for enabling HTML5 in my application?
The Application rule in Pega 7 has a check box that must be selected to enable the application to render in HTML5 Standards mode. In the definition of the Application rule, select the Include HTML5 document type check box, as displayed in the following image:
The location of the Include HTML5 document type check box
Does Pega 7 have any report listing the rules to be modified for HTML5 compliance?
The HTML5 Application Readiness page lists section rules that contain deprecated layouts and deprecated controls. For more information, see Upgrading deprecated and outdated controls.
The layouts available in versions earlier than Pega 7 are not responsive in nature. For example, SmartLayouts and FreeForm layouts render after upgrading the application to Pega 7 but are not responsive in nature, which makes them unusable to achieve cross-device support across various form factors.
Are fixed portals supported in Pega 7?
Fixed portals in Pega 7 are HTML-gadget based portals. These portals are not recommended to be used after the introduction of composite portals in PRPC 6.x, because they might not render or be fully functional after upgrading to Pega 7.
In Pega 7, these portals have to be re-designed as composite portals.
If my application portal has panel sets, do I need to modify them?
Pega 7 has a layout called a screen layout, which is used for designing portals instead of panel sets. Screen layouts are responsive in nature and display well across form factors. Composite portals developed using panel sets continue to work after upgrading to Pega 7, but are not responsive.
For more details about screen layouts, including the procedure for upgrading panel sets to screen layouts and the procedure for configure and implementing screen layouts, see Harness form - Adding a screen layout.
How can I troubleshoot the WorkArea gadget referenced in my composite portal that is not rendering correctly?
WorkArea is a PRPC gadget used to build traditional portals. This gadget provides the space in portals where work objects or cases are viewed and processed, along with all other user actions associated with work objects.
The WorkArea gadget is deprecated in Pega 7, and has been replaced with a Dynamic Container layout that is more advanced and configurable for building HTML5-compliant portals and the User Interface. Dynamic Containers also offer greater flexibility and improved performance.
Although WorkArea controls render even after upgrading to Pega 7, they have been marked deprecated and it is a best practice to upgrade the WorkArea gadget to instead use a Dynamic Container.
Pega 7 offers an auto-upgrade ability for upgrading a deprecated WorkArea gadget to a Pega 7 Dynamic Container, as displayed in the following image:
Upgrading the WorkArea gadget to a Dynamic Container
For more information about the auto-upgrade capabilities and the different configurations that a Dynamic Container can support, see Upgrading Work Area controls to Dynamic Containers.
How can I create a tabbed rendition of my WorkArea using a Dynamic Container?
Dynamic Containers can be configured as one of the tabs in a tab group. Design a section with a tab group and add the existing tabs in the WorkArea. When all of the tabs are added, add a Dynamic Container as a tab and refer to this section in the harness.
An example of this process is displayed in the following image:
Converting tabbed WorkAreas into tabbed Dynamic Containers
Should Flow action rules be upgraded or updated?
The HTML5 Application Readiness page lists Flow action rules that do not reference section rules, and instead reference HTML rules.
Flow actions referencing HTML
Update the Flow actions listed on the page to use an auto-generated section instead of referencing HTML.
It is recommended to always include a section inside a flow action. If writing custom HTML rules is required, it should be done using HTML5 compliant standard tags and CSS.
For flow actions created prior to PRPC 6.1, there is another option, “Define Form,” available under HTML Generation. These flow actions can be updated by running the Convert Flow Actions utility, available by clicking .
Should the Action Section be upgraded?
Harness rules that are created in releases earlier than PRPC 6.1 reference an older and less flexible Work-.Action section or other action sections. While the PRPC 5.x Work-.Action section (and other standard action sections included in PRPC 6.1) remain functional and supported in Pega 7, the Work-.pyActionArea is recommended to be used as an alternative.
To identify a list of rules where Action references need to be replaced with .pyActionArea, run the utility .pyActionArea conversion opportunities, available by clicking .
What is a dynamic layout? Should all layouts be updated to dynamic layouts?
Dynamic layouts were introduced in Pega 7 for HTML5 compliance and responsive UI. They are responsive and can be rendered on any device.
Smart layouts have been deprecated in Pega 7 and must be updated to dynamic layouts. This conversion can be done automatically. When a section rule is open, click .
A free form layout is not auto-upgradable. It is recommended that you change all existing smart layouts and free form layouts to dynamic layouts for responsiveness.
For more details on dynamic layouts, see:
Using dynamic layouts to create responsive user interfaces
Using layouts to structure content in sections
Will deprecated controls work across browsers after upgrade to Pega 7?
Yes, deprecated controls work after upgrading to Pega 7. However, custom controls (for example: custom ListView JavaScript) might not work in all browsers.
Is there a ready reference that contains details about all deprecated controls?
Yes, for more information, see Upgrading deprecated and outdated controls.
What are the different changes required to be made for section rules?
Section rules require more changes post-upgrade than other UI rules. Layouts and controls must be updated, and inline styles in the layouts must be removed. The following articles cover changes that must be made to section rules:
Upgrading deprecated and outdated controls
Harness and Section forms - About Smart layouts
Upgrading an application to render in HTML5 Document Type
HTML5 Application Readiness landing page
Automatically remove all inline styles
I have hand-coded CSS, will it continue to work after upgrading to Pega 7?
Pega 7 does not recommend usage of inline styles. If it is absolutely necessary, then it is recommended that you use the custom CSS option available in the Skin rule. The custom style after being defined in the skin can be referenced in the cell read-write and read-only classes, as displayed in the following image:
Updating custom CSS
Hand-coded CSS might continue to work (for example, you can specify styles in the Cell inline style), but should be avoided because it is difficult to maintain consistency of styles throughout the application. Additionally, any non-auto-generated CSS in any harness might have issues when rendering in Standards mode.
For additional details on custom CSS, see Upgrading harnesses that contain custom CSS and JavaScript to render in HTML5 Document Type.
Should custom JavaScript be rewritten after upgrade to Pega 7?
Pega 7 provides many controls and events to perform a variety of actions. Custom JavaScript should be evaluated to determine which elements can be replaced with auto-generated Pega 7 features. If all of the elements can be replaced with equivalent Pega 7 features, the relevant text file can be removed from the Scripts and Styles tab in the harness. For more details, see Upgrading harnesses that contain custom CSS and JavaScript to render in HTML5 Document Type.
How can I force the portals to render in Standards and Compatible modes of the browser?
Pega 7 does not recommend specifying the document type in a Harness rule to allow rendering the application in Standards mode and to enable cross-browser or device compatibility. However, there may be situations where there are multiple applications running that are built on different Pega 7 versions and have a single browser version across the enterprise that renders all of them. In such a situation, affected portals must be set to render in Compatibility or Quirks mode, as displayed in the following image:
Rendering portals in Internet Explorer
For more details on this configuration, see Upgrading harnesses that contain custom CSS and JavaScript to render in HTML5 Document Type.
Can I restrict the browser version for rendering a portal?
You can emulate a specific browser version for rendering a portal by selecting the type of the IE Document mode on the Advanced tab of a Harness rule, as displayed in the following image:
Restrict rendering in Internet Explorer
The above setting is useful when Internet Explorer 11 is used as a default browser by users and setting Quirks or Compatibility mode in the browser settings might not be possible.
My application has many ListView controls, should all be re-implemented?
To achieve responsive and dynamic UI, ListViews in sections must be replaced with Repeat Grids, and the data for the Repeat Grid must be configured to load from a Report Definition. Events such as "click" must be reconfigured in the Report Definition.
For more details, see Using a report definition rule as a data source for a Grid layout.
How can I achieve List-to-List control capabilities in Pega 7?
Starting in Pega 7, some OOTB controls that were previously available have been deprecated. One example is the List-to-List control. Functionality of List-to-List controls in Pega 7 can instead be achieved by doing the following:
- Use two Repeat Grids as a Source and Target List, and include Source and Target Data Transforms.
- Add buttons with events configured to copy and remove data from relevant Repeat Grids.
A sample configuration can be found by clicking .
Do I need to rewrite the code where any ActiveX object has been referenced?
ActiveX controls work only with Internet Explorer. To achieve cross-browser compatibility, it is recommended that you do not use ActiveX controls, because the corresponding object would only render and function properly in Internet Explorer. You might want to rewrite any legacy code snippets to make the application work seamlessly across browsers.
Are there any equivalent objects for each of the existing ActiveX controls that are supported across browsers?
To support cross-browser compatibility, Pega 7 is developing equivalent functionality using Microsoft Silverlight instead of ActiveX. However, there are few features that are still dependent on ActiveX and might not work as expected in other browsers.
For a quick reference of all of the available ActiveX controls for Pega 7, see ActiveX controls.
I have imported my application built in an older release of PRPC into Pega 7. Do I need to follow any additional steps?
If an application Rule-Admin-Product (RAP) is bundled in a version prior to Pega 7 and is subsequently imported into Pega 7, then the rules being imported should be revalidated and saved.
Pega 7 provides a utility to perform this automatic Revalidate and Save. For more information, see About the bulk Revalidate and Save tool.
Additionally, the RAP being bundled and imported should not contain any Pega 7 shipped Rule or Data instances, such as Access Group, Operator, and Requestor Type.