A Custom View snippet does not receive any parameters. Instead, it must return an object which defines certain functions. Initialization, rendering of particular Items and cleanup are handled in these functions.

A Custom View Snippet must return an object with the following:

PROPERTIES

alwaysFullRender (boolean): Optional. A value indicating if Items should always be re-rendered. Defaults to false, allowing Items to be cached. Set this value to true to prevent caching. Note that this may result in decreased performance.

FUNCTIONS

setUp (function): Optional. Called whenever the the View is first rendered. For example, when the page first loads, or after switching from one view to another.

Function Parameters:

– list(skuid.ui.List): Used to control and get information about the current Table.

beforeRender (function): Optional. Called when the page first loads, after a pagination event, when edited/deleted records are saved/canceled and when a new record is added to the table. beforeRender is executed just before the currently visible Items are detached from the DOM (if there are any) and the next group of Items are rendered.

Keep in mind that, because this function is called before the prior group of Items have been removed, some of the list’s variables—such as visibleItems and contents—represent the “prior” state of the table. Thus, adding elements to the contents element will have no visible effect (as it will be cleared immediately after this function) and pulling Items from visibleItems may produce unexpected results (or errors, since visibleItems is undefined when first rendering the Table). When implementing beforeRender, it’s recommended that you avoid modifying the contents of the Table.

Function Parameters:

– list (skuid.ui.List)**: Used to control and get information about the current Table.

render (function): Required. This function is responsible for rendering the given Item. It is called the first time the Item appears within the Table and, if alwaysFullRender is false, is not called again unless the View or Page is reloaded.

Function Parameters:

– item (skuid.ui.Item): Used to get information about the current Item within the Table.

renderComplete (function): Optional. Called after all visible Items have been rendered and the Items have been appended to the Table.

Function Parameters:

– list (skuid.ui.List): Used to control and get information about the current Table.

tearDown (function): Optional. Called just before switching to another View. This function provides an opportunity to handle any last-minute cleanup tasks necessary to free up memory, etc. This function is notcalled when the window is closed or the page is refreshed.

Function Parameters:

– list (skuid.ui.List): Used to control and get information about the current Table.

IMPORTANT NOTE: “Rendering” here refers to generating HTML elements. Due to various optimizations within Skuid, there is no guarantee at any point that List or Item elements have been rendered on the screen or even added to the DOM. Some element attributes, such as height and width, may or may not be completely initialized. When building a Custom View, it is best to use standard flow layouts rather than depending on dynamic layout using absolute positioning, etc.

Custom Views are more complicated than most snippets. This example demonstrates how to build a minimally functional Custom View which can then be used as a template for more advanced Custom Views.

To begin, create a new Skuid page with the following properties:

Page Name: SkuidSample_CustomView

Type: Desktop

Template: Object list / tab page

Select Primary Object: Product2

On the new page, ensure that the “Name” field is included in the Products2 Model.

Select the Table component and click “Add Features” then “Add View.”

This will add a new View labeled “Standard List View” (this is a default value). Click the View and change the following properties:

View Type: Custom

View Label: Basic View Template

View Icon: ui-silk-wrench

Snippet Name: SkuidSample.EmptyView.png4

Open the “Resources” tab and create a new Javascript resource with the following properties:

Resource Location: In-Line (Snippet)

Snippet Name: SkuidSample.EmptyView

The code for this example is little more than a shell. It demonstrates one strategy for building the return object which Skuid, in turn, uses to build the Table View.

Using this strategy, each of the functions are defined individually and given names that are meaningful to their context. Shared variables are easily declared and used between them. An object can then be created which references the functions and associates them with names that Skuid will recognize.

Building off the template from the previous example, we’ll now expand the rendering of Items into something a bit more useful.

In this example we’ll create a “Card View.” This view is similar in concept to the standard Photo View, but with much more data on the screen. We’ll also enable editing of the record directly from each card.

To begin, add the following fields to the Product2 Model from Example 1:

To make the jQuery “$” shortcut available to all functions, we’ll declare a single view-scoped variable at the top of the snippet:

1

var$=skuid.$;

In the Standard View, the “Add Row” button is located in the table header. The table header is not rendered in a Custom View, however, so we’ll need to create an “Add Product” button during setup, as encapsulated within the “createAddButton” function:

For this example, though, most of the code will focus on rendering Items as cards.

Each card will have editable fields which can be activated using an “edit” button (just like they can with the row action button). To make the code a bit more succinct, add a helper function for creating fields:

This function creates a skuid.ui.Editor, wraps it in a skuid.ui.Field and then registers it with a skuid.ui.Item. The advantage of creating a Field (over trying to implement everything yourself) is that a lot of the plumbing involved in wiring the editor up to the Model is handled for you. When you enable editing of the Item (which can be done with one line of code), it automatically enables editing for all registered Fields. The Fields allow direct editing of the given skuid.model.Model. When the Model data is changed, the Table is automatically notified and, among other things, the Save/Cancel buttons are enabled. It is significantly easier to use a Skuid Model than it is to try to handle all of this complexity on your own.

The majority of the code in this example is in the render function, named renderCard. It creates the editable fields and HTML elements for the the cards.

As you may have noticed, the styling for the card is expressed via CSS classes (added to our elements via jQuery’s addClass function). For most snippet examples, the styling is relatively minor. For this example, however, there was a great deal of styling to be done. To prevent the snippet from becoming unwieldy, we’ll place the style information for the elements in a CSS resource.

Open the “Resources” tab and create a new CSS resource with the following properties:

For this example, we do not need to provide the “before render,” “render complete” and “tear down” functions. All that’s left is to bundle the two functions we are going to use into an object and then return it to Skuid:

1
2
3
4

return{setUp:createAddButton,render:renderCard};

Now Preview the page and select “Cards” from the Views list.

Rather than seeing the standard table, you can now view and edit your data as cards. Notice that filters and pagination still work. We didn’t have to do anything special for that!