RPCL Overview
Summary: An overview of using the RPCL for application development.
This section introduces:
- RPCL Architecture
- RPCL Components
- Working With Components
Contents |
RPCL Architecture
RPCL is an acronym for the RadPHP Component Library, a set of visual components for rapid development of PHP applications. RPCL contains a wide variety of visual, non-visual, and utility classes for tasks such as application building, web applications, database applications, and console applications. All classes descend from Object . Object introduces methods that implement fundamental behavior like construction, destruction, and message handling.
RPCL Components
RPCL components are a subset of the component library that descend from the class Component . You can place components on a form or data module and manipulate them at designtime. Using the Object Inspector, you can assign property values without writing code. Most components are either visual or nonvisual, depending on whether they are visible at runtime. Most components appear on the Tool Palette.
Visual Components
Visual components, such as Form and Button, are called controls and descend from Control . Controls are used in GUI applications, and appear to the user at runtime. Control provides properties that specify the visual attributes of controls, such as their height and width.
NonVisual Components
Nonvisual components are used for a variety of tasks. For example, if you are writing an application that connects to a database, you can place a DataSource component on a form to connect a control and a dataset used by the control. This connection is not visible to the user, so DataSource is nonvisual. At designtime, nonvisual components are represented by an icon. This allows you to manipulate their properties and events just as you would a visual control.
Other RPCL Classes
Classes that are not components (that is, classes that descend from Object but not Component) are also used for a variety of tasks. Typically, these classes are used for accessing system objects (such as a file) or for transient tasks (such as storing data in a list). You cannot create instances of these classes at designtime, although they are sometimes created by the components that you add in the Form Designer.
Working With Components
Many components are provided in the IDE on the Tool Palette. You select components from the Tool Palette and place them onto a form or data module. You design the user interface of an application by arranging the visual components such as buttons and list boxes on a form. You can also place nonvisual components, such as data access components, on either a form or a data module. At first, RadPHP components appear to be just like any other classes. But there are differences between components in RadPHP and the standard class hierarchies that many programmers work with. Some differences are:
- All RadPHP components descend from Component .
- Components are most often used as is. They are changed through their properties, rather than serving as base classes to be subclassed to add or change functionality. When a component is inherited, it is usually to add specific code to existing event handling member functions.
- Properties of components contain runtime type information.
- Components can be added to the Tool Palette in the IDE and manipulated on a form.
Using Events
Almost all the code you write is executed, directly or indirectly, in response to events. An event is a special kind of property that represents a runtime occurrence, often a user action. The code that responds directly to an event, called an event handler, is a RadPHP procedure.
The Events page of the Object Inspector displays all events defined for a given component. Double-clicking an event in the Object Inspector generates a skeleton event handling procedure, which you can fill in with code to respond to that event. Not all components have events defined for them.
Some components have a default event, which is the event the component most commonly needs to handle. For example, the default event for a button is OnClick. Double-clicking on a component with a default event in the Form Designer will generate a skeleton event handling procedure for the default event.
You can reuse code by writing event handlers that respond to more than one event. For example, many applications provide speed buttons that are equivalent to drop down menu commands. When a button performs the same action as a menu command, you can write a single event handler and then assign it to the OnClick event for both the button and the menu item by setting the event handler in the Object Inspector for both the events you want to respond to. You can also create similar event handlers for JavaScript events.
This is the simplest way to reuse event handlers. However, action lists provide powerful tools for centrally organizing the code that responds to user commands.
Setting Component Properties
To set published properties at design time, you can use the Object Inspector and, in some cases, property editors. To set properties at runtime, assign their values in your application source code.
When you select a component on a form at design time, the Object Inspector displays its published properties and, when appropriate, allows you to edit them.
When more than one component is selected, the Object Inspector displays all properties—except Name—that are shared by the selected components. If the value for a shared property differs among the selected components, the Object Inspector displays either the default value or the value from the first component selected. When you change a shared property, the change applies to all selected components.
Changing code-related properties, such as the name of an event handler, in the Object Inspector automatically changes the corresponding source code.