Pega Upgrade Center cross-browser compliance FAQs
This article lists frequently asked questions regarding Pega Upgrade Center cross-browser compliance.
- 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?
- 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?
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.
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
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.
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.
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.
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
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.
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 .
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:
Yes, for more information, see Upgrading deprecated and outdated controls.
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:
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.
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
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.
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.
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.
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.