Home
Projects
Download
Support
Sponsors
Sponsor Benefits
Buy Gifts
Donate Now
Join Us
Open Cooperation
Contribute
Contributors (26)
Events (1)
Academy
Outsourcing
Contact Us
Outsourcing
Open Cooperation
Sponsor
Others
Recruitment
Ask Us
Chat With Us
About Us
Back to project ezyplatform

Using previousScreen to Link Admin Screens

Updated at 1782054669000
previousScreen is used when a screen is not opened as a standalone page, but from another screen whose navigation context should be preserved.
Common examples:
  • opening a detail screen from a list,
  • opening an edit screen from a detail screen,
  • opening a related screen in another module,
  • returning to the correct previous screen after saving,
  • keeping the sidebar, active menu, breadcrumb, or back URL aligned with the original screen.
Instead of manually passing values such as active menu, parent title, and parent URL everywhere, you can pass previousScreen. The admin runtime uses it to look up the previous screen metadata and restore the proper navigation context.

How It Works

When an admin view request contains the previousScreen query parameter, the admin view decorator reads it before rendering the view.
From previousScreen, the system will:
  • set previousScreen into the view,
  • find metadata for the matching screen name,
  • restore currentOpenParent, currentMenu, currentParentTitle, and currentParentURL from metadata if they are not explicitly provided,
  • append queryString to currentParentURL when available,
  • set previousQueryString so JavaScript can keep forwarding the same context.
flowchart TD
    A[User is on screen A] --> B[Open screen B with previousScreen=A]
    B --> C[Admin view decorator reads previousScreen]
    C --> D[Find metadata for screen A]
    D --> E[Restore menu, parent title, parent URL]
    E --> F[Render screen B using A's context]
    F --> G[JS helper forwards previousScreen to screen C]
    G --> H[Screen C still keeps the return context of A]
Important: previousScreen is a screen name in view metadata, not a URL.
Example:
/ecommerce/payment-services/stripe?previousScreen=ecommerce_payment_services
Here, ecommerce_payment_services is the registered screen name. The system uses it to resolve the parent URL, active menu, and breadcrumb.

Related Parameters

previousScreen
The previous screen name. This is the main parameter.
?previousScreen=ecommerce_payment_services
queryString
The previous screen’s query string, useful when returning to the same filter, search, or pagination state.
?previousScreen=ecommerce_products&queryString=?keyword=phone&page=2
When queryString is present, the system appends it to currentParentURL and stores it as previousQueryString.
currentParentURL
Can be provided directly when the previous screen has a dynamic URL, such as an entity detail page.
?previousScreen=ecommerce_product_details¤tParentURL=/ecommerce/products/123
This is useful when metadata can describe the screen type, but the actual URL depends on runtime data.
currentMenu, currentOpenParent, currentParentTitle
These parameters can be provided directly to override metadata. If omitted, the system tries to resolve them from the previousScreen metadata.

Using It in Templates

When rendering a link from a screen that may already carry a previousScreen context, forward that value to the next screen.
Example link from a list to a detail page:
<a th:href="${'/items/' + item.id
    + (!#strings.isEmpty(previousScreen)
        ? ('?previousScreen=' + previousScreen)
        : '')}">
    View
</a>
If the list screen was opened from another screen, this keeps the detail screen aware of the original context.
This pattern is suitable for simple HTML actions such as:
  • view details,
  • edit,
  • open a child screen,
  • open a related configuration screen.

Using It in JavaScript

The admin frontend provides this helper:
ezyadmin.createUrlWithPreviousScreenParams(
    uri,
    previousScreen,
    previousQueryString
)
The helper creates a URL and automatically appends:
  • previousScreen,
  • queryString when available,
  • or lang when no queryString exists.
Example from detail screen to edit screen: 
ezyadmin.onEditButtonClick = function() {
    window.location = ezyadmin.createUrlWithPreviousScreenParams(
        '/items/' + selectedItemId + '/edit'
    );
}
If the current page already has ezyadmin.previousScreen, the helper forwards it automatically. Therefore, this flow:
List -> Detail -> Edit
can still keep the original list screen as the navigation context.
After saving successfully, use the same helper to navigate back to the proper screen:
success: function () {
    window.location = ezyadmin.createUrlWithPreviousScreenParams(
        '/items/' + selectedItemId
    );
}

Using It in Controller Redirects

For screens opened by a server-side redirect, attach previousScreen directly to the redirect URL.
Example when opening related content from a product detail screen:
return Redirect.to(
    "/posts/" + postId + "/edit" +
    "?previousScreen=product_details" +
    "¤tParentURL=/products/" + productId
);
Here, currentParentURL is provided because the return URL depends on productId.
This pattern is suitable when:
  • redirecting to another module,
  • the parent screen URL is dynamic,
  • breadcrumb or back navigation must point to a specific entity page.

Preserving Filter and Pagination State

If the previous screen has filters, search keywords, or pagination state, pass queryString.
Example:
var previousQueryString = 'keyword=phone&page=2';

window.location = ezyadmin.createUrlWithPreviousScreenParams(
    '/items/123',
    'item_list',
    previousQueryString
);
The helper encodes the query string as:
/items/123?previousScreen=item_list&queryString=keyword%3Dphone%26page%3D2
When rendering the target screen, the admin runtime uses this queryString to build a complete currentParentURL, for example:
/items?keyword=phone&page=2
As a result, the back button or breadcrumb returns not only to the list page, but to the exact list state the user came from.

Example Navigation Flow

sequenceDiagram
    participant List as List
    participant Detail as Detail
    participant Edit as Edit
    participant Runtime as Admin runtime

    List->>Detail: /items/123?previousScreen=item_list&queryString=keyword%3Da
    Detail->>Runtime: Render view
    Runtime->>Runtime: Find metadata for item_list
    Runtime->>Detail: Set currentMenu, currentParentURL, previousQueryString

    Detail->>Edit: createUrlWithPreviousScreenParams('/items/123/edit')
    Edit->>Runtime: Render view
    Runtime->>Runtime: Reuse previousScreen and queryString
    Runtime->>Edit: Breadcrumb/menu still follow item_list

    Edit->>Detail: Save successfully, redirect back to detail with helper

Best Practices

Use previousScreen when the target screen needs to preserve the source screen’s navigation context.
Use currentParentURL when the return URL is dynamic, such as /products/{id}.
Use queryString when the source screen has filters, search, pagination, or tab state that should be preserved.
In JavaScript, prefer ezyadmin.createUrlWithPreviousScreenParams(...) instead of manually concatenating query strings.
In Thymeleaf templates, append previousScreen only when the variable is not empty.
Do not use previousScreen as a URL. It is a screen metadata name. The return URL is resolved from metadata or from currentParentURL.

Conclusion

previousScreen is a small but useful mechanism for linking admin screens while preserving context. It allows detail, edit, or cross-module screens to keep the correct active menu, breadcrumb, parent URL, and return state.
When combined with queryString and ezyadmin.createUrlWithPreviousScreenParams, it supports multi-step navigation flows where users can always return to the exact place they started from.

Table Of Contents