A Perspective page URL that begins with a parameter, such as /:repartoLineaPosId, captures every single-segment path on the project, including literal pages like /hucreate and /hucreate-multisn. Moving the parameterized entry to the bottom of the Page Configuration list changes nothing, because page URLs are not evaluated in list order. The static part of any page URL that carries parameters must be unique from every other page URL. Give the parameterized page its own literal prefix, for example /pos/:repartoLineaPosId, and the static pages resolve correctly.
Symptom Signature and Where to Read It
The number that matters is the count of literal segments in front of the first parameter. When that count is zero, the page's static part is just /, and it overlaps every other page on the project.
| Quantity | Conflict condition | Where to read it |
|---|---|---|
| Static part of a parameterized URL | Empty or equal to another page's URL or prefix | Designer, Perspective Page Configuration, URL column |
| Segment count of the requested path | Same segment count as the parameterized page | Browser address bar |
| View actually rendered | Parameterized page's primary view instead of the intended view | Session in the browser, or the view's name and path in a debug label |
| Value in the page parameter | Holds a literal like hucreate
|
Primary view's parameter matching the URL token name |
The last row is the fastest confirmation. Bind a label in the parameterized view to its repartoLineaPosId param, then open /hucreate. If the label shows hucreate, the path was captured as a parameter value, not routed to the static page.
Resolution Mechanism: Static Prefix, Not List Order
Engineers coming from client-side routers such as Vue Router expect a ranking step: static segments beat dynamic segments, and ties fall back to declaration order. Perspective page resolution has no such ranking. The Gateway serves Perspective through its Jetty web server, and page routing follows how Jetty layers servlets and path mappings. The Page Configuration list is a set, not an ordered route table. Reordering it is cosmetic.
Under that model, a path pattern whose static portion is / matches anything one segment deep. /hucreate, /hucreate-multisn, and /anything-else all satisfy /:repartoLineaPosId. Which page wins is not something you can control through configuration order. Because this behavior comes from the underlying web server layering, the design rule is the only fix: make the static portion of each parameterized URL unique.
This is routing, not view logic. No script, binding, or view parameter default on the parameterized view can hand the request back to the correct page once the URL has resolved there.
Re-Mapping Procedure
- Open the project in Designer and go to Perspective Page Configuration. Export or screenshot the current URL-to-view mapping before editing.
- List every page URL containing a
:token. For each one, write down its static part, which is every literal segment before the first parameter. - Flag any parameterized URL whose static part is
/, or equal to or a prefix of another page URL. - Rename each flagged URL with a unique literal first segment. For example, change
/:repartoLineaPosIdto/pos/:repartoLineaPosId. The prefixposis only an example; pick one that no other page uses. - Keep the parameter token name unchanged. The page passes URL parameters into the primary view's params by matching names, so renaming the token breaks the value handoff.
- Leave the static pages (
/hucreate,/hucreate-multisn) as they are. - Search the project for every navigation that targets the old pattern and update it. Check navigation actions on components, menu tree and link component targets, scripted navigation, and dock configurations tied to that page.
- Update anything outside the project that encodes the old URL, such as bookmarks, kiosk launch URLs, QR codes on line equipment, and links from MES or other web apps.
- Save and publish the project.
If external systems can't be changed right away, one option is a single root page that dispatches internally, for example an embedded view whose path is chosen from the parameter value. That moves routing into view logic and is harder to maintain. Treat it as a stopgap, not the design.
Verification
- Open a new browser session so no earlier page state carries over.
- Request
/hucreateand/hucreate-multisndirectly in the address bar. Each should render its own configured view. - Request the renamed parameterized page with a real ID, for example
/pos/followed by a valid line position ID. The debug label should show that ID inrepartoLineaPosId. - Request the old pattern with a real ID. It should no longer reach the parameterized view. Confirm it lands on the project's not-found handling, not on a static page by accident.
- Click through every in-project navigation path that previously targeted the parameterized page, then remove the debug label.
Recurring Pitfalls
| Pitfall | Effect | Correction |
|---|---|---|
| Reordering Page Configuration to fix precedence | No change; order is not evaluated | Change the URL's static prefix |
Two parameterized pages sharing a prefix (/line/:a and /line/:b/x) |
Non-deterministic or wrong view selection | Give each its own literal first segment |
Static page URL equal to a parameterized page's prefix (/pos alongside /pos/:id) |
Overlapping static parts | Keep the static page on a distinct path |
| Renaming the URL token while re-mapping | View param stays at its default value | Keep the token name identical to the view param |
| Missed external links after the rename | Operators land on the not-found page | Inventory kiosk, QR, and MES links before publishing |
For new projects, the rule is simple: never start a page URL with a parameter. Put a literal namespace segment in front of each parameterized route from day one, and literal pages stay collision-free as the project grows.
FAQ
Why does /:param in Ignition Perspective override my static page URLs?
Its static part is just /, so it matches every one-segment path, including literal pages like /hucreate. Perspective does not rank static segments above parameters. Prefix the parameterized URL with a unique literal segment such as /pos/:id.
Why doesn't moving a page lower in Perspective Page Configuration change which view loads?
Page URLs are not ordered. Resolution follows the Gateway's Jetty servlet layering, not the list order. Only a unique static prefix on each parameterized URL removes the overlap.
Why does my view parameter stay at its default after I renamed the page URL?
The URL token name must match the primary view's parameter name exactly for the value to pass through. If you changed :repartoLineaPosId while adding the prefix, restore the original token name.
When should I escalate a Perspective page routing problem to Inductive Automation support?
Escalate if every parameterized URL has a unique literal prefix, the project is saved and published, and a fresh session still renders the wrong view for a given path. At that point, contact Inductive Automation support through its official channels with the Page Configuration export, the Gateway version, and the exact URLs that resolve incorrectly.