Content Management Patterns

The hypertexts for content management, perhaps even more than those for con- tent publishing, follow very regular patterns. Indeed, the examples presented in Section 4.3 illustrating the five WebML basic operations already exemplify opera- tion patterns, as they present the typical ways in which content creation, deletion, or modification are specified. In this section we present two further frequently used patterns, which involve multiple operations, organized in transactions.

4.5.1

Create-Connect Pattern

Thecreate-connectpattern is a sequence formed by a create operation followed by an arbitrary number of connect operations, which associate the newly created object to one or more related objects, typically supplied by one or more transport links.

The example in Figure 4.13 illustrates a simple create-connect pattern for creating a new review and attaching it to an artist. The Review page includes the

4.5 Content Management Patterns 157

Review Artist ArtistData ReviewEntry Txt: TextField Auth:AuthorField OK Review Celine Dion Press OK to create Her albums always include some of her most loved hits as well as ... OK CreateReview Review <Text := Txt> <Author := Auth> Connect ArtistToReview ErrorPage KO KO OK J. Smith Review text: Author:

artist’s data, and an entry unit to input the review author and text. When the review data have been introduced, a new review object is created and, subse- quently, connected to the artist object. Note that the link exiting the CreateRe- view unit transports the new object, which is then used by the Connect unit. Because the two operations are part of the same transaction, they are executed atomically: if any of the two fails, the whole transaction fails and no effect is pro- duced on the data.

In Figure 4.13, the KO links exiting from both operations point to the same error page. In this case, an equivalent notation can be obtained by representing one only KO link, going from the transaction box to the error page, meaning that the failure of either one of the two operations leads to the same page.

4.5.2

Cascaded Delete

Thecascaded delete pattern allows you to remove a particular object and all the objects associated with it via one or more relationships. It is a sequence formed by two or more delete operations, one for removing the main object and the others for removing the related objects. In particular, cascaded deletion is used to propagate the deletion of an object to other objects, which are connected to it by a relationship with minimum cardinality 1, and thus could not exist with- out the object they refer to. An example of such a situation is illustrated in Fig- ure 4.14, which shows the use of the cascaded delete pattern for deleting an album and all its tracks. The Album page includes a data unit (AlbumDetails) showing the album to delete, and a multidata unit (Tracks) displaying its tracks. The transaction consists of a sequence of two delete operations, the former deleting the tracks, and the latter deleting the album. The transaction is acti- vated by a link from the AlbumDetails data unit to the DeleteTracks operation, which is associated with a parameter (AlbumOID) holding the OID of the cur- rent album. This parameter is used in the selector of the DeleteTracks operation to cancel all the tracks of the album; if the track deletion succeeds, the OK link is followed and the DeleteAlbum operation is executed. This operation receives the OID of the album to delete from a transport link exiting the AlbumDetails data unit. In this case, the pattern uses a single KO link, exiting from the trans- action box.

The example in Figure 4.14 shows the cascaded delete pattern applied to only one relationship level, but it can be extended to two or more relationship lev- els; for example, an artist can be deleted, together with all his/her albums, and for each album all the contained tracks can be cancelled. Independently of the num- ber of levels, the deletion always starts from the deepest relationship level, and pro-

ceeds by deleting objects backwards along relationships, until the main object is deleted. In the above example, first the tracks are deleted, then the albums.

As will be discussed in Chapter 11, cascaded deletion is a primitive capa- bility of SQL-based relational databases, which offers suitable table definition statements ensuring the propagation of deletions from a “master” object to its sub-components. However, in absence of such a mechanism, the application of the cascaded delete pattern ensures that the state of the data remains consistent after the deletion of an object associated with dependent components. Note that, according to the standard behavior of the delete operation, the relationship in- stances between the deleted album and its tracks need not be explicitly cancelled, but they are implicitly erased: for each deleted track, all the relationship instances in which the track object is involved are automatically removed.1

4.5 Content Management Patterns 159

Album Album AlbumDetails Tracks Track [AlbumToTrack] DeleteTracks Track [AlbumToTrack(AlbumOID)] AlbumOID:OID DeleteAlbum Album [OID = AlbumOID] AlbumOID:OID OK DeletionSuccessfulPage OK DeletionFailedPage KO

Figure 4.14 Cascaded delete pattern for deleting an album and all its tracks.

1_{The behavior of the delete operation is consistent with the usual meaning of the Entity-}

Relationship model, in which an instance of a binary relationship is considered as a pair of key values referencing objects actually existing in the database. If an object is deleted, any relationship instance referencing it becomes invalid and is no longer considered. This “conceptual” characteristic of the Entity-Relationship model can be easily supported in relational databases, as described in Chapter 11.