So we're changing the MVC components, model first. We need to tell MUM that all user objects have a full name attribute. For our logic, it's just some data to display. A full name could have anything, it could even be empty. Heck, even the string "R. Duds" is full enough a name for our purposes.
Meet the creator
We use instances of an interfaced called org.mum.installation.ModelCreator to manipulate the model installation process. It has only two methods:
isUpdateNeeded(Repository repository):boolean:
- returns true if the data model needs changes to be considered complete.
update(Repository repository):void:
- if an update is needed, this method will be called. You can then modify the repository any way you want.
You may already see through this concept. When MUM starts it must somehow consider if the model stored in the database is still up-to-date. This is to be done by isUpdateNeeded(). While extending MUM you must always update isUpdateNeeded() to reflect your changes. It always has to return true if a changed or new model isnīt written to the database.
As you expect, if isUpdateNeeded() returns true, update() will be called which is responsible for updating the model in the database.
Add an attribute
Create a subclass of MUM's basic model creator, a class called org.mum.installation.MumModelCreator. Derive from the naming conventions at your own risk:

First, we want our model creator to complain if the model doesn't have the right attribute, so we override the superclass with the following logic: "If my superclass needs update, I need too. If it doesn't, I need a type User with an attribute fullName".
@Override
public boolean isUpdateNeeded(Repository repository) {
boolean result = super.isUpdateNeeded(repository);
if (!result) {
PType type = repository.getType("User");
result = (type == null || !type.hasAttribute("fullName"));
}
return result;
}
Then we override update to add the attribute we need:
@Override
public void update(Repository repository) throws StorageException {
// create the superclass stuff if necessary
if (super.isUpdateNeeded(repository)){
super.update(repository);
}
repository.loadType("User")
.put("fullName", PAttribute.STRING);
}
The code above creates the basic model, then loads the type and puts a string attribute with name fullName on the User type. It has a potential bug, can you spot it?
Think what would happen if we were ordered by the Greek gods to name all types lowercase and change User to user. The call to loadType would not find a type and throw an exception. My opinion on this matter is don't deal with problems you don't have. If we ever break backward compatibility, we'll tell you in advance, and tell you how to fix it.
Loose coupling, baby
There will never be Java code pointing directly to your model creator. Probably because someone else might want to take your application and build their stuff around it. That someone might be yourself in a few months. But the XWork action that creates the model needs to call your code, so we wrapped it in a Spring configuration.
If you don't know Spring, you don't have to worry about it. All you need to do is edit one line of XML configuration. Open the file /config/ApplicationContext.xml and change the class of the model creator:
<bean
class="org.mum.installation.MumModelCreator"
id="modelCreator"
name="ModelCreator"
singleton="true" />
to look like this:
<bean
class="org.mumtutorial.installation.TutorialModelCreator"
id="modelCreator"
name="ModelCreator"
singleton="true" />
When we start MUM the next time, the code you wrote above will be called and all will be fine.