The Properties panel

This brings us to the Properties panel. All components have properties, and the Properties panel is where we view and edit those properties. The Accordion layer of Properties is the primary interface for defining component behavior. Properties shown depend on the selected component in the model, as not all properties are common to all components. Each layer in the accordion groups properties into common categories such as events and style.

Properties can be viewed in Recommended or All mode. In All mode, all properties are shown straight off. In Recommended mode, the properties shown are reduced to the recommended set. The recommended properties are the most commonly used properties. These also tend to be less dangerous if you don't fully understand them. If there are additional properties beyond the recommended ones to be had, you can show them without leaving Recommended mode by clicking on the Show more link at the bottom of the set.

Like components, properties are searchable, and there is a single search editor across the views. Search will find those components not currently shown when in Recommended mode.

Also at the top of the Properties panel is the gear icon used to open a small settings pop-up box. In this box, we have a checkbox used to enable having multiple accordions open at once. The item in this box is a link to open the property publisher dialog. The publishing page properties enable us to have more modular and reusable pages. We will be discussing the use of publishing page properties in Chapter 5, Navigating towards Reusability.

The top layer is the Properties layer, and it contains the core properties of the selected component. Many properties have default values. These properties generally don't need to be considered until customization is desired. Studio auto-generates a name for the component upon creation and setting the name is often helpful, but is not required. Still, nearly all components have a few properties that you must set if the widget is to be effectively functional. These properties have the red asterisk used to mark required fields next to them.

On the far-right margin of each property there is a question mark help link. This opens the in-Studio help dialog for that property. The content shown in these dialogs is from the client-side API reference of the product documentation, or jsref for short. You can browse the JavaScript reference directly at:

http://dev.wavemaker.com/wiki/bin/wmjsref_6.5/WebHome

The Data layer is where we specify any inputs to variables and server calls. These include filters for searches and inputs to function calls. The fields are directly driven by the type of the variable or its operation. If the Data layer is not correct, check the Type and Operation specified in the Properties layer.

In the Style layer are three subtabs: Basic, Styles, and Classes. The Basic tab is used for setting border, padding, and margin. As we learned in the previous chapter, these are properties used by the WaveMaker layout engine and not CSS rules. The Styles and Classes tabs are used to create and apply component-specific CSS.

The Mobile layer is where we'll find mobile-specific properties for components. These properties control on what devices the widgets are shown and are generally only found on widgets due to their visual nature.

The Events layer is the visual interface to dojo.connect(). The Events tab is populated with the most commonly used events for that component. The drop-downs are populated with create options at the top and likely functions in the lower section. Choosing JavaScript creates a new empty event function and brings us into the page source script tab. It is important to understand that we are hardly limited to the tooled choices. A single JavaScript function can be used for multiple events from multiple components. Simply type in the name of an existing page function instead of selecting from the menu to reuse an existing function for an event. DOM events that are not visually tooled are not shown in the events tab, but can also be assigned handlers by calling dojo.connect() manually in the page's start function. The following line of code is an example of adding a mouse over event to a widget named labelMouseOver:

this.connect(this.labelMouseOver.domNode, “onmouseover”, this, “myMouseOverFunction”);

When the user's mouse enters the DOM node for that label, the page function named myMouseOverFunction() is invoked.

A single event can trigger multiple functions. Next to the help link for each event is a plus sign icon. This is the "and then" button. Use it to add "and then" functions to events.

In the Operations layer are not properties, but buttons that perform useful functions on that component. Service calls can be invoked using the updateNow button, for example. Any operations accessible from the right-click menu for widgets, such as Wrap in Panel, are also here.

The last layer in the properties accordion is Docs/Diagnostics. We've already used the Notes tab to add custom notes for aggregation in the documentation tab under the Source tab. We've also seen how the Docs tab displays the JavaScript reference page for that component type. That leaves the Description tab, which is really the diagnostics part of this layer. This area generates a reference of event handlers as well as inbound and outbound bindings. A good use case for this tab is for checking if any other component is using the component under inspection. For example, prior to deleting a component, the diagnostics can confirm that the soon-to-be-deleted component is truly no longer being used.

For a few components, the very last layer is Deprecated. This is where you will find deprecated features of components. You should only need this layer if you have an existing project utilizing deprecated features. In such situations, you should migrate the functionality to non-deprecated methods.