You trying to recreate the skuid builder here?  (Grin)

It’s for a dynamic menu system I’m building for a client. I’ve got it working, but it would be even better to add this polish to the experience. The icons and object are using a text field. I’d prefer to set them up with the same user experience as the page builder.

The Object selector is just a lookup field with uses the standard “type ahead” renderer. 

The icon picker is more customized.  It could be replicated using a variant of the custom table view that JD documented here: http://help.skuidify.com/m/11720/l/211114-table-component-custom-views    Here you could add the Icons,  and a row action to add them to the record you were interested in. 

"The Object selector is just a lookup field with uses the standard “type ahead” renderer. "

I don’t have an object called “Objects” to create a lookup to.

"The icon picker is more customized.  It could be replicated using a variant of the custom table view that JD documented here: http://help.skuidify.com/m/11720/l/211114-table-component-custom-views    Here you could add the Icons,  and a row action to add them to the record you were interested in. "

Same deal. There is no object called “Skuid Icons” where I can query it to get what I need.

I can create the custom view for the table once I have an object to connect to.

^^bump^^ no solution to this yet. I’m stumped on how to proceed with either piece.

Ok, I have all the secrets behind Skuid icons. A little background first though. Also, this can get really complicated very quickly.

–

Icons are, for most intents and purposes, wholely associated with Skuid themes. They are a collection of css classes that will change the background, width, height, and/or content of the html element they are assigned to in order to appear properly as a nice looking icon. The two currently used icon sets, as you know, are silk and fontawesome. However, we replace the typical class names for these iconsets with our own prefixes and suffixes to keep everything running smoothly when you change themes. So, if you wanted an icon in you’re page, you could use the html

<span class="ui-button-icon-primary ui-icon sk-icon-config sk-icon inline"></span>

And just replace “config” with whatever suffix you wanted.

–

That all being said, the full list of available icons for each theme is stored in the theme’s theme definition file. In order to get to this file, you can either enter the url in your browser to download it and take a look, or do an ajax request in Javascript to the correct URL, and then read the icons from the returned object.

Here are the URLs for the JSON definition files of the 3 basic themes

• your Salesforce URL]/resource/1/SkuidThemeModern/skuid_theme.json
• oyour Salesforce URL]/resource/1/SkuidThemePaper/skuid_theme.json
• oyour Salesforce URL]/resource/1/SkuidThemeClassic/skuid_theme.json

So. Once I have this JSON I can then parse it into object and iterate through icons to build my icon selector. Seems like quite an implementation challenge since I don’t nearly enough experience creating HTML elements from javascript. Is this otherwise the solution as it’s build into the page builder?

I also would still like to know how to do the object selection as it’s done when selecting an target object for a model.

You are no longer a “Like” virgin.

Haha, thanks Pat, and yeah it’s quite the implementation challenge.

And yes, this is the way we do it in the page builder. I’m sure there are some other creative ways you could go about getting the icons definitions into a Salesforce object, or there are some other Javascript shenanigans that you could do, but ultimately, and unfortunately, it becomes pretty complicated any way you look at it.

And unfortunately, I’m not quite sure about the object selection, I still have some learning to do pertaining to that.

Any chance you can share any code for the icon selector? I’m sure I’m not the only one who could benefit from this. 

Unfortunately I don’t think I can. It has dependencies upon parts of the Skuid API that are not exposed to user facing pages, so it would be a pretty sad snippet of code if it were to be orphaned. And as a general rule of thumb we try not to share source code. Partly because of company privacy, and partly because we would not be prepared to offer support on such code.

Although, if you think this is a useful feature for a wide variety of users, you could submit it as a feature request.