# tagPath URL parameter - best practices?

**URL:** <https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [February 27, 2024, 9:54pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469 "2024-02-27T21:54:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [February 27, 2024, 9:54pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469/1 "2024-02-27T21:54:44Z")

</div>

We use `tagPath` for _everything_ and I'd like to figure out a clean way to pass a tagPath parameter to a page URL such as `/node/:tagPath`. However per the docs and common sense, `/` is a disallowed character in a URL parameter. Any simple ways people have substituted or worked around this?

For now, all our nav is done to views rather than URLs, but I like the representational state aspect of a URL whenever possible.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 27, 2024, 10:02pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469/2 "2024-02-27T22:02:00Z")

</div>

It would have to be [URLencoded](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLEncoder.html#encode(java.lang.String,java.nio.charset.Charset)).

---

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [February 27, 2024, 10:06pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469/3 "2024-02-27T22:06:22Z")

</div>

I mean it's simple to take in a `tagPathEscaped` parameter via URL, then do a simple `replace({view.params.tagPathEscaped},"~","/")` expression to convert to a valid tagPath.

But I can hear you saying "bleghh" to that and I was hoping for a more glamorous solution to escaped urls such as  
`data/perspective/client/project/node/Path~to~tag~right~here`

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 27, 2024, 10:09pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469/4 "2024-02-27T22:09:08Z")

</div>

Yeah, Ignition allows a lot of characters in tag names that aren't legal in URLs. If you use the standardized encode/decode tools, you won't miss anything that will need fixing later. Hmmm?

Not so simple. 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [February 27, 2024, 10:30pm UTC](https://forum.inductiveautomation.com/t/tagpath-url-parameter-best-practices/86469/5 "2024-02-27T22:30:12Z")

</div>

And of course there's already an expression that takes care of that. There's always some new expression to find. [urlEncode | Ignition User Manual](https://docs.inductiveautomation.com/docs/8.1/appendix/expression-functions/string/urlEncode)

`urlEncode('Path/to/tag/right/here')`, used to create a URL nav such as `data/perspective/client/project/node/Path%2Fto%2Ftag%2Fright%2Fhere`  
loads right into `view.params.tagPath` decoded and ready to use.

Not pretty, but representational and back button/bookmark friendly. Now I feel like an amateur for asking this in the first place. There's always expression functions in the banana stand.
