Deprecated: Function set_magic_quotes_runtime() is deprecated in /storage/content/76/1004576/ on line 33 Deprecated: Function split() is deprecated in /storage/content/76/1004576/ on line 95 Deprecated: Function split() is deprecated in /storage/content/76/1004576/ on line 743 dev:attributes [DokuWiki]

This page aims to describe JPatchs Attributes framework.

All classes of objects that the user can manipulate (including objects, faces, edges, points, cameras, motion-curves, etc.) are called Entities and are in the package jpatch.entity (or a subpackage) - this is part of the model/view/controller design (entity = model).

As entities can be modified by the user, Attributes are meant as a wrapper to encapsulate all the user-changeable “attributes” of an entity. Note:I hope “attribute” as a name makes sense, I could also change it to “property” or something else.

Not using e.g. a double field for a cameras focal length or a javax.vecmath.Point3d field for an objects position, but wrapping such fileds into an Attribute object has two key advantages:

  1. There is no class explosion of “Edit” objects, that are used to encapsulate changes in entities (for undo/redo support). Instead of one edit that controls a camera-position change, one edit that controls a vertex-position change and so on there is only one Edit for, e.g., a Point3d Attribute. Similarily, there is only one Edit to control changes of any Double Attribute - not one separate Edit class for changing the camera focallenght, another one for changing a lights brightness, etc.
  2. Using Attributes enables to set-up GUIs for entities in a completely automated way. There is no more need to write a GUI that displays e.g. textfields and sliders to manipulate a camera, and to write a second GUI that displays controls to manipulate e.g. a lightsource, etc. These GUIs can be setup automatically using reflection and a very simple XML file for each entity class (I’ve chosen to use an XML file to keep the entities and the GUI strictly separate). How Attributes can be bound to Swing Components is described next:

Attribute classes exist for all classes that represent user-manipulatable fields of entity classes. This includes most primitives, but also e.g. Tuples (for storing 3D coordinates). In case of primitives they are similar to the Java wrappers (e.g. Double, Integer, etc.). But:

You can register an AttributeListener to each Attribute - it will be notified if the Attribute has been changed. This mechanism is used to e.g. bind an Attribute to a Swing component. An AttributeListener is added to the attribute in question. It will update e.g. the text-value of a textfield whenever the Attribute was changed (e.g. update the position-textfields if an object was moved with the mouse). Standard AWT/Swing event handling is used to listen for e.g. keyboard entries in those textfields to automatically update the corresponding Attributes.

The code that handles the automatic GUI generation mentioned above does all the listener registration in the background. It also unregisters listeners for GUI components that are hidden or disposed automatically.

  dev/attributes.txt · Last modified: 2007/02/20 16:01 by (sascha)