1.3 Adding CRUD operations and views
When you are building a real application, you will pretty much know what kind of views you want and which objects they will be based on. But, for the purposes of this tutorial, let's pick the “sales order” object to build a list screen for searching sales orders, and a details screen for creating new and editing existing sales orders. This is a reasonably large and complex object to demonstrate different features of the Xomega platform, which can also realistically represent the sales module of our application.
Let's go ahead and open up the imported sales_order_header.xom file, which contains the XML for our Xomega object model. To make reading and browsing this XML much easier, Xomega allows you to collapse it to definitions of different model entities. So go ahead and select the Outlining > Collapse To Definitions in the context menu for that XML to see it better, or just press the Ctrl+M, Ctrl+O shortcut.
Based on the special relationships (with cascading delete) between the SalesOrderHeader table and its child tables (SalesOrderDetails and SalesReason), the latter have been imported as subobjects of the sales order object, and automatically include its keys implicitly. The following picture demonstrates this.

However, the objects' names (highlighted) have been derived from the corresponding tables' names, and may not provide particularly good choices for other entities that will be generated from them. This is especially true for subobjects, since Xomega generators always try to fully qualify them with their parent object’s name.
Therefore, before we move any further, let's rename these objects to make them more succinct, and to work better with the Xomega generators as follows. We will rename "sales order header" to just "sales order" (including the file name), "sales order detail" to "detail", and "sales reason" to "reason". It is important to do it before we add any standard data objects or views to avoid tedious renaming afterwards.
While we're at it, we can also rename some long type names, such as the ones shown below, but it's not that critical, since we can do it at any time later.

Xomega provides standard refactoring capabilities, where you can right click on a type, and pick Rename from the context menu. Along with the Rename dialog, where you supply the new name, the system will also display all references to the current type, which will be renamed as well, as shown in the following picture.

Once all objects are properly renamed, all you have to do is to right-click on the sales_order.xom file and run the Full CRUD with Views generator under the Model Enhancement submenu. This is a configurable and powerful generator that can add various model elements you specify to one or more selected objects.

Here is a high-level view of the different things it added.

As you can see, it added standard create, read, update, delete (CRUD) and read list operations to the objects, defined Xomega data objects for view models, as well as the actual search and details views for the objects and subobjects in the file.
Under the hood it also configured each of these elements properly, so that views are bound to the data objects, and the data objects are tied to the operations, set up as each other children as needed, and have proper links to other views.
Next: 1.4 Building the model >