The story
If you're anything like Joey, you've played with MUM just a little bit and moved on, since MUM looks like any other webapp in the world. I picture him thinking "it looks oh-kay, but it's not as cute as Karen. Man, she's more than cute, she's hot!". That's perfectly understandable. That's why we will undress MUM now.
MUM concepts
Marbles-based web applications use a classic approach to separate different concerns, the MVC model. The View, which is the way we present information to the user, is defined in Freemarker templates. The Model resides as objects in the Tiny Marbles repository, and the MUM Controller is Java code. The specific part of the controller that deals with business logic is implemented as XWork actions.
Model: The Tiny Marbles repository
This one is easy because you'll know how to use Tiny Marbles once you're done with this tutorial. To satisfy your curiosity, I'll tell you that:
- Tiny Marbles is all about data.
- It can deal with most transaction details for you, you only need to commit your changes (if you change anything).
- All your actions get a clean Repository instance to play with.
View: Templates
Templates are located inside the /web/ directory and have names ending in .ftl. There are special templates containing only Freemarker macros that are included automatically in all the other templates. They are located at /web/templates/widget_*.ftl. Avoid them at the beginning, for magic is dangerous to the unprepared mind.
Controller: Webwork actions
All business logic is handled in classes derived from org.mum.action.BasicAction which we call Actions. Basically all of the action's work should be done in the execute method. Interaction between templates and actions are very easy. For a form with an input field named "foo" all you need in the action will be a public setter setFoo. In reverse you can easily access "foo" on the template by creating a getter for it. Please consult the WebWork documentation for further details.
The initial data model
You might have been as baffled as Joey to learn that MUM doesn't come with a "full name" or "display name" for the User objects. That's on purpose! Some people need a single text field for the full name, other people need separate first name and last name, and we didn't want to take sides so bluntly.
"Edit user" screen without the full name
I'll tell you the general steps needed to be taken take use a data model in your interface:
- modify the data model creator so that it adds this attribute when MUM installs
- change one or more templates to use the field
- change some logic to use the field.
This is how it needs to be done. But:
The process is still not as boring as we want it want to be. We want it to be so boring it doesn't deserve a tutorial page. So easy that Joey can do it while 99.999% of his brain is focused on talking to Karen on the phone. We are working on reaching that goal in the near future.
Let's go on, but careful: pointy brackets ahead.