Skip to main content

Is it possible to have skuid automatically append query string parameters to all the hyperlinks it builds on a page (e.g. hyperlink to a reference field within a field editor)?

Our skuid page will take a url parameter (eg. color) that we would like to be “passed” through to each hyperlink and action skuid builds on a page.  One thought I had was to use jQuery to append the url parameter on each anchor tag but I’m hopeful that there is a better way as this isn’t 100% reliable and not having css class on each page element (e.g. field in field editor) results in more of a brute force approach across all anchor tags instead of just the ones skuid builds.

The use case behind is that our users have a default setting that controls page rendering but they can select a different value on any given page that we want to carry with them to the next page but not other tabs/windows that they might open from outside of a link that is specifically on rendered elements of the skuid page (this rules out using a cookie as a mechanism).

Thanks!

There’s no built-in functionality in Skuid that helps with this.

It might be better to store the value of this parameter in a Cookie, or in a Custom Object / Custom Setting, that you can then retrieve on each page you need access to it from.


Custom Field Renderers would get you at least part of the way there. You’d be able to render hyperlinks in Tables and Field Editors this way. Links generated via templates would still be a problem, though.

If you are looking for a CSS class, I believe that all of our field-based hyperlinks (including those generated by templates) are contained within a DIV with the “nx-field” class applied to it. So you could use a CSS selector like “.nx-field A”

A major problem you will run into, though, is that fields are re-rendered at various times, such as when switching between edit and read mode, or when moving to the next page of a table. Any changes you’ve made to the anchor tags via jQuery will be lost in those circumstances.


Thanks guys!

The cookie/custom setting won’t work for us unfortunately in this case.  The value we want to be able to override is a Custom Setting currently.  The user has a “default setting value” in the custom setting.  When the page loads, it grabs the custom setting and applies conditions, filters, etc.  What we want is to ensure that a user can have multiple browser tabs open simultaneously one using their custom setting default and another using an override.  Clicking on a link on either of those pages should carry that “context” over to the resulting page.  If we use the custom setting or cookie to drive the resulting page, we’d always end up with the resulting page being built based on the last data value we persisted which could be different than the page they clicked the link on.

JD brings up a very good point regarding the re-rendering as it relates to the jQuery solution.  It looks like my only quasi-reliable option would be a custom renderer but this doesn’t solve 100% of the situations and it’s a lot of code overhead given the number of fields we have that have hyperlinks.

Just to recap, here is the scenario:

  • Custom Setting that contains favorite color (red)

  • Custom Setting value (red) is retrieved on page load and used throughout page for “preferences”

  1. User opens Tab A and custom setting red is applied

  2. User opens Tab B and custom setting red is applied

  3. On Tab B, user changes “color” to a green and Custom Setting value is persisted

  4. From Tab A, user clicks a link and takes them to a new page.  The new page checks the custom setting and builds the page using green.  This is where we want the page to be built using red because that was the setting value on Tab A from which the user clicked the link

Disclaimer: The scenario above is simplified from our actual situation.  In our actual situation, the Custom Setting value represents a “system context” and that when the user clicks a link on a page that is in “Context A” they are going to expect to remain in “Context A” and not be switched to “Context B.”  Context defines filter values for model conditions, lookup filters, etc.

Trigger any other creative ideas??