JavaScripting InDesign

Everyone knows what an object is. A document is an object, a text frame is an object, a library is an object; indeed, just about anything you work with in an InDesign session is an object, including the application itself. But other things are equally not objects, for example, your default setting for horizontal measure units is not an object -- it's a property of an object. Palettes are not objects (although windows are). Palettes could be, it's just that palettes are not yet incorporated into the scripting interface.

Is it worth trying to come up with a generalized description of an object when they're all so different from each other?

I confess to mixed feelings about this. One part of my brain screams of course it is, without a formal definition of an object how can you work with them? The other part responds that it is easy. I know what a document is, so I know what I can do with one with my scripts. Similarly for just about any other object.

Indeed, there are some parts of the object model that I'm not particularly familiar with. I've managed without exploring the Table of Contents and Indexing related objects, I have only a minor acquaintance with the XML objects. My understanding of the color management objects is about on a par with my understanding of color management itself.

But these gaps in my knowledge hasn't stopped me creating a lot of useful scripts; I don't spend much time working in those areas represented by the gaps in my knowledge and so I've felt little or no pressure to explore them. Meanwhile, I'm forever creating scripts to help me massage text or adjust the relationships of graphics and their containers and the like.

Still, I have a grasp at a general description of an object. It is an entity (how's that for a nebulous word?) that fits somewhere in the tree of objects rooted in the application object. This tree has limbs that sprout in many directions. Some limbs are short: Application => Libraries => Assets. Some are long and theoretically boundless: Application => Documents => Spreads => Pages => Page Items => Page Items => Page Items ...

Page Items? There's a term you might not be familiar with if you have not scripted. Page Items is the name of an umbrella object type that includes all objects that can live directly on a page. So, rectangles, ovals, graphic lines, text frames and groups are all examples of page items. Graphics is a similar umbrella term for, you guessed it, graphics that can be imported into InDesign documents. Graphics live inside certain kinds of page items.

My sense is that an object is best thought of in these terms:

There are four kinds of objects in the InDesign Object model: the Root Object, Elemental Objects, Generic Objects, and Terminal Objects, to coin three names.

The Root Object

The root object is the application object. It is the base upon which all else builds. It has a very large number of properties, many of which are in fact collections of elemental objects or references to terminal objects.

Elemental Objects

This is the class of the really useful objects, the ones you actually work with: text frames, paragraphs, characters, insertion points, stories, rectangles, paths, pages, sections, libraries, documents, and on and on.

Generic Objects

These provide scripters with a mechanism for working with a variety of similar elemental objects that share a lot of common properties. Their existence is a convenience for scripters. Examples are: page items, graphics, text, and widgets (dialog objects).

Terminal Objects

This is my least favorite name for a class of objects. Perhaps I'll come up with something better. These are objects that have no children. They "terminate" their particular limbs of the object tree. Examples are the many settings, preferences and options objects that exist either as children of the application or of documents.

---------------------------------------------

So that's it for now. I can't say that I'm entirely happy with the label "Terminal" nor even with its definition. By that definition, an asset -- the scripting name for items in a library -- is a terminal object when it is clearly an elemental object. Now why do I say that? Because assets form a collection of elements of their respective library parents while the other kinds of terminal objects are not members of collections.

Well, I don't have to solve every issue at once. Clearly, I need to come back to this issue.