Page localization - global "include" of labels

  • 1
  • Question
  • Updated 4 years ago
  • Answered
Beyond defining labels as a resource on a page, is there a way to trigger labels that are needed to be loaded by Skuid?  For example, some "global always load a defined set of labels" approach akin to the <ModuleName>JS & <ModuleName>CSS static resource concept? 

Here's the use case - We've built a framework that sits on top of skuid and our runtime requires the use of localizable strings (e.g. messages - we have lots of these).  Since our runtime is included on all of our skuid pages (we have over 100 and counting), as I understand it, the only way to ensure that the label is made available on the skuid page itself would be to define the label on each page.  In our case, that would mean repeating the same label definition on each and every one of our skuid pages.  If there was a way to have a global "include" concept, this would allow our runtime labels to be included everywhere and then only page specific labels would need to be included in the builder on the specific page.

Possible solutions assuming something like this isn't available out of the box:
1) Write a custom component that would be the first component on every page. Would need to do this instead of document.ready to ensure the labels are always available before any UI elements are rendered. This component would make a sfdc api call (metadata api I'm guessing) to obtain all the labels required and then "add" them to skuid.label object.  The downside here is that this component needs to live on every page where it would otherwise not be required.
2) On the VF page that contains the skuid page, build up json server side then parse client side and "add" to skuid.label using the custom component approach.  This would perform better but the downside is that that every VF page would require it (could be wrapped in a custom VF component so code only lives in one place).
3) Controller extension that would expose remote method that could be called by a custom component.  It would return JSON and client code would then "add" to skuid.label.

Insights, thoughts are appreciated!
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb

Posted 4 years ago

  • 1
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
Barry, there is a way to do this, will get back to you soon with a full explanation.
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
Awesome news Zach, very glad to hear.  Thank you!
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
There are two main ways to accomplish this:

(1) (NOTE: You must install Skuid Superbank Patch 6 for this to work, there were bugs with this prior to Patch 6) Declare these Custom Labels as dependencies of components in a Component Pack. This approach would work if there are already certain Components that will be included on all of your Skuid Pages where these global labels are needed, and if this is true, this is our recommended approach. 

(2) Create a custom Skuid Apex component that requests labels to load. This component would have to be included on every page that you want these labels on, and should probably be the first component on each page. It does not need to have a JavaScript runtime representation at all, it's only purposes would be to request Custom Labels server-side at page load time.

Here's how to do (1):

In your Component Pack's runtime manifest file (probably called skuid_runtime.json), add a "customLabelDependencies" array at the global level, e.g.

{
   id: "acme",
   customLabelDependencies: ["all_reps","all_stages","basic_information","clone_line_item"]
}

Where "all_reps", "all_stages", "basic_information", and "clone_line_item", are the API Names of Salesforce Custom Labels defined in your org.

See Josh's Component Packs tutorial for more explanation of the Manifest file syntax.

For (2), create a new Apex Class (or if you already have an existing Skuid Apex Class that defines a Component that you include on every page, as I believe you do, Barry [your synchronous page include component], you can just extend it to include this code) that requests the Custom Labels you want on your page, like this:

global with sharing class CommonLabels extends skuid.SkuidponentImpl {

   global override void generate(){

     // Add in requested labels

     this.customLabels.addAll(new Set<String>{

        'all_reps',

        'all_stages',

        'basic_information',

        'clone_line_item'

     });

   }

}


If you have an existing class that implements skuid.SkuidponentImpl that has other content in the generate() method, you would just need to add in the this.customLabels.addAll(...) bit into the generate() method. Either way, the class must be global.


Whether you used (1) or (2), you are going to need to add one Component to every Skuid page in order for this functionality to apply --- in method (1), you just need some Component from your Component Pack to be added to every Skuid Page, it doesn't matter which Component. In Method (2), you will need to add the <commonlabels/> component to every Skuid Page's XML --- to make this easier for Method 2, you should declare a Builder for the <commonlabels/> component so that it is easy to drag this in to every Skuid Page you have. Barry again I think you already have a Component that you include in every Skuid Page, so I think you can just piggy-back on this Component.


Photo of Barry Schnell

Barry Schnell, Champion

  • 18,076 Points 10k badge 2x thumb
Hi Zach -

Thanks for the reply and information, extremely helpful. As you mention, we already have a component that we include on every page (and it's the first component on each page) so implementing #2 above will work for us.  It's similar in concept to the options I was thinking in my original post but avoids all the client side interaction since it's all wrapped up nicely on the server side.

I was hoping that there would be a way to do this without requiring a component on each page.  In our case, since we already have one, it's easy enough.  I was framing my original question more generically for the broader audience who wouldn't normally already have a custom component on each page.  There's been discussion previously regarding introducing the concept of a "master page" or "page template" to Skuid and defining labels would be another great benefit of having that type of concept.  Food for thought as you guys consider the master/template page concept.

Thanks again!