PDF viewer in a model window - Cosmos

Hi Experts,

I have a business requirement to preview multiple PDF documents as shown in the attached image. User select the document from the left side and the preview should render the PDF file in the right side panel. Note that this is a cosmos DS requirement and seek your support to implement it with OOTB.

Thanks

Hi @Lakpriya

I analyzed your requirement using only out-of-the-box capabilities available in Constellation. Let’s break the scenario into functional blocks and evaluate feasibility.


Requirement Breakdown

From the screenshot, the UI consists of three logical sections:

  1. Employee selector (tabs at top) — switching employee context
  2. Payslip list (left panel) — selectable list per employee
  3. PDF preview panel (right) — renders selected document with viewer controls

Part 1 — Employee Tabs

You want a dynamic tabbed layout where each tab represents an employee.

In Constellation, dynamic tabs can only be driven by a data source (Data Page) and not directly from an embedded Page List property.

Therefore:

  • If employees are stored inside the case as an embedded list, tabs cannot be generated directly OOTB
  • To enable dynamic tabs, you must:
    • Create a Data Page
    • Pass Case ID as parameter
    • Load employee list from case
    • Bind tabs to this Data Page

This approach works correctly and aligns with constellation rendering rules.


Part 2 — Payslip List per Employee

For each employee tab, you want to display that employee’s payslips.

Here’s the constraint:

  • Tab content renders as a partial view context
  • Partial views operate in a read-only data context
  • Dropdown / card selection requires state change
  • State change requires editable clipboard context

Even if you configure the Data Page as editable, selection still fails because:

The UI context is bound to a Data Page, not the primary case page

Therefore:

Selecting a payslip from a list inside a tab rendered from a Data Page is not supported OOTB.


Conclusion So Far

The exact UI shown (tabs + selectable cards + preview pane) cannot be implemented fully OOTB in Constellation today.


Available Implementation Options

Option 1 — Full fledge Custom DX Component

Build the entire layout using a custom component.

Pros

  • Full flexibility
  • Exact UI replication

Cons

  • Higher development effort
  • Maintenance overhead

Option 2 — Hybrid Approach

Instead of tabs + cards, redesign slightly while keeping UX intuitive.

Suggested pattern:

Employee table (or list) → grouped rows → payslip entries
Each payslip row includes Preview action

When user clicks preview:

  • Opens the PDF in modal (or)
  • Open the PDF in drawer on the right hand side (or)
  • Open the PDF in popup window or in new tab

This is achievable with:

  • OOTB table/list view
  • Custom URL-type field component for preview

Suggested Generic Preview Component Design

To maximize reusability, build one configurable preview component with parameters:

Parameter Purpose
Preview Mode Modal / Drawer / Popup window / New tab
Content Type URL / Base64 encoded string
Source Property reference / Data Page
Trigger Link / Button / Icon

Benefits:

  • Reusable across application
  • Configurable from rule form
  • No code change for new use cases
  • Centralized enhancement later

Note: When you go with custom component, be sure to work closely with UI developer and ensure that you take utmost care related to security constraints, accessibility, localization, styling aspects so that it is PROD ready.


Final Recommendation

For maintainability + scalability + minimal customization:

Best architecture choice
→ OOTB table/list + reusable preview component

This approach:

  • Avoids unsupported UI patterns
  • Keeps logic in platform
  • Minimizes custom code surface
  • Provides future flexibility

Closing Statement

I created a proof of concept using the preview drawer approach and verified that this hybrid pattern works reliably while staying within Constellation constraints.

I’d also welcome additional perspectives from others on alternative design approaches that remain compliant with OOTB capabilities.

Hope this helps

Regards

JC

Thank you so much for your detailed resolution. This makes sense, and we have already experimented alternaives. This is a strict OOTB implementation, and we wanted to seek a possible scalable solution.

This requirement is for Cosmos, but you have extended it further, which is highly appreciated.

Again! Thank you!