The Puma domain model
Having an understanding of the Puma domain models will make it much easier to write your own plugins. Not that Puma is a particurly difficult to understand application, or that CMSs in general have obscure domain models, but just that every one is so different you’re not likely to want to waste your time translating SQL into understanding.
In case you’ve forgotten your UML, here’s a brief reminder of UML syntax:
- Class names go on the top line of the box (like Page, User, etc).
- Abstract class names are written in italics and represent classes that shouldn’t be directly instantiated.
- Attributes go in the middle of the box (date, time, etc). The name comes first, then the type.
- Methods go in the bottom box (authorized, etc).
- Static methods are underlined and don’t need to be called on an instance.
- Types followed by types in angle brackets (List) are generics. List means “A list whose elements are of type Page”.
That’s the brief rundown. You don’t need to be a UML expert to see what’s going on up there.
Gross anatomy
A Puma website is a single tree of Page objects and a set of Users. The pages are versioned; each page has at least one Version object associated with it that contains the contents of the page for a particular version of the page. Each User has a permission level which is compared with a given page’s permissions to determine whether that user can edit or view the page. There’s a special user that corresponds to an anonymous user of the website; it’s named Anonymous appropriately enough.
Most pages in a Puma website are HtmlPages, whose versions contain raw HTML. Other subtypes of Page are useful for other purposes—HiddenPages, for example, shouldn’t be listed on any public-facing portion of the website, so you can hide administrative pages like Copyright beneath a HiddenPage.