Decorations

David Shaffer

Basics

Decorations can impact a component in many ways including adding to or modifying the component's rendered content, changing the way in which callbacks are processed, and intercepting component answers. Components keep a reference to the root of (linked) list of their decorations and have several methods related to travering this list. We will go over this in some detail later but first lets look at an example decoration that is already in your image: WAMessageDecoration.

WADecoration subclass: #WAMessageDecoration
	instanceVariableNames: 'message'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Seaside-Components-Decorations'

message: aString
	message _ aString 

renderContentOn: html
	html heading: message level: 3.
	self renderOwnerOn: html.

FIX THE WORDING HERE: presenter vs component vs decoration First we can see that decorations are subclasses of WADecoration. Second we see that decorations can implement renderContentOn: like components. If we just follow the code we see that this decoration renders a heading and then it renders the component that it is decorating (its "owner"). If we look at WAComponent>>addMessage: we can immediately see how to add decorations to a component:

addMessage: aString
	self addDecoration: (WAMessageDecoration new message: aString)

In reality the owner may not be a component but instead another decoration. It is simply the "next" pointer in the linked list. When Seaside wants to render a component it gets that components decoration (the root of the decoration list) and renders it. In the case of decorations they (usually) render themselves and then render the next decoration or component in the chain. The last component in the decoration chain is usually the component to which all of the decorations have been added (there are exceptions to this but it is generally true).

C. David Shaffer

Last modified: Fri Jul 22 17:28:47 EDT 2005