An XOTclIDE Component is a named persistent set of Classes, Objects, and Tcl Procedure Groups administered by XOTclIDE. When you program in XOTclIDE, a Component is the thing that stores your program. It serves the same purpose as a library in compiled languages or a package in Tcl, providing a name that can be used to locate and load a set of items. A Component only has meaning when an application or program is being loaded - once the program is running, the name of the Component where a proc or Class was originally stored is no longer useful.

XOTclIDE Components are built on top of Tcl packages - each Component has a package name, calls package provide, and has an entry in a pkgIndex.tcl file. A Component can be used in any Tcl or XOTcl program by calling <code>package require</code> with the Component's name. Component are a slightly restricted form of package that contains only proc definitions, Class definitions, Object definitions, and special metadata generated by XOTclIDE. No other Tcl commands are stored in a Component.

Each Component is stored either in one text file named after the Component, or in a Version Control database.

It may be useful to consider how XOTclIDE loads and stores Components. When a Component is loaded, all its proc and instproc names, arguments, and bodies are loaded into the running Tcl/XOTcl interpreter. Classes, Objects and their relationships are also loaded. Imagine that you need to edit the body of a proc found in a Component. When you call up an edit area containing the body, XOTclIDE copies the current body from the Tcl interpreter into an editable window. When you save the edit (Control-s), XOTclIDE copies the body back into the Tcl interpreter (by doing a proc command.) At this point, the new body is available in the Tcl interpreter, and you can test whether it works to your satisfaction. Once you decide that it's good enough, you save the Component that contains the proc. XOTclIDE gets the current proc names, args, bodies, Classes and Objects in the Component from the Tcl interpreter, constructs XOTcl commands that will regenerate the current state of each thing, and stores the commands either in a file or a Version Control database.

One thing to note about this process is that anything other than Classes, Objects, procs, and metadata that was in the Component file will disappear, since the Component stored form is completely rebuilt when XOTclIDE stores the Component. There's no guarantee that a Component file will preserve previous order. The text of a Component file may be edited. and any changes to proc bodies will be available the next time the Component is loaded. The next time XOTclIDE saves the Component, the text file may not look much like it previously did. For example, any comments added to the file that stores a Component will disappear the next time XOTclIDE saves the Component.

Another thing to note is that changes to the heritage of Classes or Objects (is-a relationships) and changes to the bodies of procs that occur while your Component is running under XOTclIDE will be stored persistently. Suppose your Component has a Class apple - if running your component under XOTclIDE adds a new superclass Class familyRose to Class apple, saving the Component will preserve the new superclass relationship. The next time your Component is loaded, apples will be in the rose family.

Nested Classes and Object aggregations (has-a relations) are stored in Components only if they have been defined in a Classes/Objects view. To define a nested class that will be persistently stored, define the class from the menu and give it a name that has the name of the class it's nested in followed by two colons (::) and the name of the new class. Similarly, Objects can have persistent subobjects defined by the programmer. Other subobjects that an Object acquires while running will not be persistent. For example, suppose that your component defines a Class vehicle, and an Object orientExpress of Class vehicle. The Object orientExpress might have many permanent subobjects of Class Wheel. These would appear in the Classes/Objects view as orientExpress::leftFrontWheel, orientExpress::rightFrontWheel, etc. While your program is running, the orientExpress Object might get some passengers and save them as subobjects of Class person. These passengers would not be visible in the Component Browser, although they would be visible in an Object Browser. When XOTclIDE saves your Component, the orientExpress will be saved with Wheel subobjects, but without any passengers.