‘AppleScriptObjC Explored’:
Table Changes

Many of the projects in 'AppleScriptObjC Explored' are built around tables, because they are a common requirement. But there have been some changes in tables in the past few revisions of the OS, and you need to be aware of them to understand why what is described in the book, or in the book's projects, will not initially match what you see in new Xcode projects.

Historically, tables consisted of a table view containing table columns, and each column contained a cell. These cell were usually instances of NSTextFieldCell, or some other cell class. The term cell here is not a reference to the fact that it is used as a cell in a table, but rather that they are cells that all controls have to do much of a control's work.

In OS X 10.7, Apple introduced a new way of constructing tables. Instead of using cells in tables, you could use views. The two types of table were designated cell-based and view-based.

The samples used in 'AppleScriptObjC Explored' are cell-based tables. For several releases after 10.7, when you added a table to a project, you were provided with a cell-based table. If you wanted to create a view-based table, you had to make changes. View-based tables behave differently, and use bindings differently.

Over time, view-based tables have received more prominence. In Yosemite, cell-based tables were deprecated in their favor. What does this mean? It means that Apple believes view-based tables are a better solution, and that they would prefer people to use them in new projects. But it does not mean that cell-based tables are going to disappear any time time. They may, one day, but they are used so widely that it's not a change likely to happen suddenly.

But perhaps more significantly for readers of my book, when you drag a table into a project in a recent version of Xcode, what you get is a table set up as view-based.

In an ideal world, I would probably revise my book to use view-based tables. But the changes required would mean a virtual rewrite, and there just isn't the economic justification for such a project. It is, however, relatively easy to change table views you drag into a project to be cell-based.

If you look at the first screenshot below, you will see the project from chapter 4. You can see that the Content Mode is Cell Based, and you can see the hierarchy of items in the Dock area on the left: Table View, Table Column, Text Cell.

If you create a new project in a recent version of Xcode and drag in a table, and set it to single column, you will get something like the second screenshot. The Content Mode is set to View Based, and the hierarchy on the left is more complex: Table View, Table Column, Table Cell View, Table View Cell, Table View Cell. The naming is confusing, because only the last is a cell. And you will see that there is also a Text Cell listed under this, but still belonging to the Table Column.

To convert this table to be cell-based involves two simple steps:

* In the Attributes Inspector, change the table view's Content Mode to Cell Based.

* For each column, delete the Table Cell View and its subviews. This will leave the Text Cell, and your table will appear like the one in the first screenshot.

You need to do this with each table-based project in the book. If you don't, the projects will not run as intended.

Above is what you see if you open the existing Lister project.

Above is what you see if you drag a new table view into a project.