[Seaside] Seaside best practices

Stephan Eggermont stephan at stack.nl
Sun Feb 10 19:07:41 UTC 2013

On twitter, Van Von Vandelay asked me to elaborate on 
best practices for Seaside, referring to my post of april 2012:
> Create a declarative description of the domain model;
>  Magritte provides a good starting point. You need better
>  descriptions for behavior, relationships, validation.

"You need better" should of course be read as: I have been 
in a situation where I would have liked to have. The context 
was a system with a domain model of somewhat over 
100 domain classes and a similar number of 
WAComponent subclasses. Deltawerken can be seen as 
an extraction of the non-domain specific parts of that application. 

Describing behavior

In NakedObjects (currently Apache Isis), actions are described. 
Zero parameter actions are mapped to buttons for the (view of the) object.
One parameter actions are mapped to drag-and-drop of one object onto the
other. When there are multiple possibilities, a modal dialog is shown
to let the user select the appropriate action. Magritte doesn't focus on 
describing these, but adding description subclasses (MAActionDescription) is easy. 

Describing relationships

Currently, Magritte relationship descriptions only refer to the class of 
acceptable objects, not to a source of acceptable objects. There is also 
no way to describe inverse relationships, where on one side a to-one 
relationship belongs to a to-many on the other class. Being able to 
describe relationships with temporal patterns would be useful too.
There is nothing in Magritte that would it make difficult to add these


Validating objects in Magritte can be complex because you often 
need access to the underlying object, not the memento. 
Unit tests can be used as a way to describe validations.


More information about the seaside mailing list