Malte, I'm new to this CR and form generation stuff, but...
I believe Dave's statements are accurate. I have spent several hours with the simulation package and, while it's exploratory, it does tie the UI (and selections made therein) to several different content types. Javascript is used to adjust the display of the primary object (item) definition form in response to user selections, both in presenting appropriate attributes, and providing option lists for these attributes that are themselves defined with the CR relations facility.
From what I've seen, simulation does not use the CR folder, template, or context facilities.
Most all that is related to form generation is localized in sql/postgresql/simulation-content-types-create.sql and www/citybuild/object-edit.tcl if you want to have a look.
/R
Here are some of the notes I made while looking at the simulation package
Simulation package CR-use description
Simulation creates its datamodel upon package installation which includes top-level simulation table to track individual simulations. It allows the CR, through direct CR SQL API and TCL API calls, to create and manage type-specific tables and their content. It uses the bcms package API to manage CR content items and relations between CR items (images, stylesheets, etc).
Citybuild/object-edit, the heart of the simulation package object manipulation UI, utilizes the form builder's ad_form wrapper to dynamically generate a form which is presented to the user. This form is a general-purpose interface for the user to define and edit all objects used within the system. The form makes use of a javascript snippet that reconfigures the form each time a selection is made to any 'select'-type form element (excluding textarea input type-selector elements). The first (and primary) form element is a radio selector widget that sets the basic object Type (or content_type). Selecting a Type dynamically reconfigures the the basic form to contain all of the Type's editable fields, some of which are select widgets containing a selection of other object Types.
Object-edit.tcl defines a static TCL structure that contains object and element invariant properties (aka 'metadata') such as: item and relationship labels (Logo, Letterhead, Resides at, etc) and content input methods (textarea, richtext, etc). In addition to this static TCL structure, this same 'metadata' is converted into an indexed array representation which is accessed by two local helper procs to retrieve these invariant properties when required. This functionality is stated to be 'prototype' and, as indicated, would more appropriately be placed in the TCL library.
Simulation uses just a few system-defined datatypes (boolean, integer, text, string, I believe), so there is no need to extend the available types (see template::data::validate::*). ATS datatypes and widgets are associated with attribute types through the use of two static TCL array structures: form_datatype and form_widget. These structures are used to indirectly define the ad_form element widgets and validation, based on the attribute datatype defined in content_type__create_attribute calls contained in simulation-content-types-create.sql.
Simulation makes no use (that I could find) of the CR's ability to associate and provide form display templates along with a content_type or individual content item.
All-in-all, simulation provides a good solid example of many of the built-in capabilities of the oacs core to manipulate dynamic form content, though my impression is that there are several areas that come up short. These areas are mostly identified by self-proclaimed hacks (see code comments). It is also my impression that there is considerable work (as in CPU-cycles) required to make use of this oacs subsystem, which leads me to believe that this approach may not be appropriately scalable to many simultaneous connections. I saw no direct indication or comment regarding any built-in content caching ability, which could bothersome.
