So far, you've seen how to write code that works with custom content types, properties, aspects, and associations. But the code wasn't tightly coupled to the objects on which it operated. With an action, the business logic is triggered by something-an item in the user interface, a schedule, or a workflow-rather than being bound to the content type or aspect.
As you know, a repository action is a piece of code that can be performed against a node. You don't have one good way of implementing your project. Some argue that the best place to develop your business logic is within repository actions. It's a good approach because it means that you can trigger your action using a rule, via a webscript, or via a Javascript code. I'll go a bit further and I'd say that a repository action should never contain business logic. All the business logic should be encapsulated in a Java service that is called by a repository action, or a webscript. It allows to share...
