Using Resources on more than One Page

Can resources be globally set up? We have created some JavaScript Resources on a page for one of our Custom Objects that we would like to be able to reuse without having to recreate them other pages. Can this be done?

If you save your Javascript files as Static Resources,  or save them to an external CDN - then they your resources declaration on each page can just point to these files rather than having to copy the JS files into every page.   For more information see this help file:  http://help.skuidify.com/s/tutorials/m/supercharge-your-ui/l/102514-including-custom-javascript-in-a…


One more idea after talking about this with our Dev Team.  

You should check out the concept of Modules (See this tutorial: http://help.skuidify.com/s/tutorials/m/11720/l/129358-create-a-skuid-module).  Create a Module, and then publish your Javascript files as static resources using the namespace associated with the module.  Then when you create Skuid pages, and select the module that you created, they will inherit the Javascript resources for the module.  No further definition required. 

Hi Rob -

Looking at a way to leverage this type of functionality but for non-managed package (empty namespace). Is there any way to have skuid automatically include static resources for resources that have an empty namespace? Something similar in functionality to the way the builder JS automatically gets included (BuildersJS).

Thanks!

Barry,  The idea of a module  (collection of pages)  is not reserved for managed packages.  You can create one or more modules in your set of random skuid pages and have these call static resources that have the module name prefixed to them.  This might sound like namespacing,  but it is not reserved for managed packages. 

It does mean that new pages would have to be included in the module in order to take advantage of the resources.  You can probably force that by adding a default value to the picklist definitio of the Module field of the Pages object. 

Hope that helps. 

Thanks Rob. Understood regarding modules not reserved for managed packages, we leverage this for our builders using a custom module name. Possibly I’m over-thinking things or missing something obvious (wouldn’t be the first time), but assuming my skuid page is in a module, what’s the convention I would need to use for my static resource names to have them automatically pulled in without having to specify them in the resources area of the page builder for a given page?

For example, to have the builder automatically pulled in my custom components, I have a static resource named BuildersJS.

Thanks!

Dang undocumented features. 

If you have a Module of name “Foo”   Create Static Resources with names as follows: 

“FooJS”
“FooCSS”

These resources will be automatically included in all pages in the Module.


Note:  Edited after Barry pointed out my error below! 

Thanks Rob, I got it working!  

Couple of notes:

1) I named the resources FooJS and FooCSS (no period in-between as it’s invalid character for static resources).

2) I had actually tried this before posting to this thread thinking that was the pattern for naming but it appeared it wasn’t working.  I realized my mistake was that I had cloned a page from the no-namespace module and created the cloned page (exact same content with same pagename) in the foo module.  When hitting the preview button from the builder on the foo namespaced page, the preview was pulling in the non-namespace page instead of the foo namespaced page.  Didn’t realize this and hence thought it wasn’t working.  After changing the name of the page in the foo namespace and hitting preview, presto, auto-include!  The take away here (besides me not paying close enough attention) is that the preview button doesn’t seem to force the namespace of the current page when opening the target window.  Hence, if there is a page name conflict, the wrong page could get pulled in.  Something you guys might want to take a look at :slight_smile:

Thanks again for all your help!

Ack.  Thanks for pointing out the error.  I’ve fixed my comment above for posterity.  FooJS is right… 

We will look into the preview issue.  We’ve known that you could have same page name in different modules.  But the preview confusion is troublesome.