Hooks revisited (1) - model architecture
Entity models and entity persistence are built on a well-established hierarchy of interfaces. For each specific entity name <ENTITY_> we have the model interfaces:
Interfaces are generated from the entity description by the Service Builder, along with the corresponding implementation classes:
Not all persistence classes of the framework are created by the Service Builder though. Dozens of persistence classes exist in the core without explicitly having declared them as models. Their existence is hardly ever noticed because they are somewhat hidden by design. Examples are search expressions, filter rules, or sets of processing parameters that can be stored as portlet preferences. This class category does not even have a proper name. However, according to their role they might well be called persisted queries or query parameters. In several cases they appear as arguments in finder methods. The AssetEntryQuery class will be used to demonstrate their importance.
In technical terms these are application meta-data which are implemented by POJO persistence classes. They have no model, no interface definition and no service wrapper. Without a proper interface they can hardly be injected into generic persistence methods. The application meta-data are probably regarded as insufficiently structured for having a proper data model. This is a design decision which is by no means a necessity.
So how are these "orphaned" classes actually persisted? As a rule, they are stored as XML text in the database. The framework uses specific implementation-only classes for XML mapping that are not visible outside of the portal application context, i.e. not available for any custom plug-ins. Possibilities of extending those "meta-data models" in a custom hook will be discussed in the sequel.