There are a number of different elements to an Acropolis application, and they are:
- part view
- What you see! The user interface portion, and they are sometimes referred to as skins. In the MVC world they were called views.
- In the MVC world, this would equate to a model. This holds the functionality and data for the part view. Therefore this would hold the logic and state. They separate the implementation of their logic and state from their user interface (view).
- child part
- A part can be composed of a number of child parts, mainly to allow functionality to be shared.
- A part that contains one or more child parts that work together to implement a specific function, scenario, or task that the end-user can perform. A form can implement a specific navigational pattern to help the user to accomplish the task that it implements. You can nest Acropolis forms to provide rich user interface structures.
- An application-level capability that implements a specific strategy or provides pluggable functionality, such as logging, event routing, and so on. These can be applied across different parts of course, so provide shared functinality, as well as supplementing their own business logic. They can be customised as well.
- connection point
- A point of communication between a part and other Acropolis components, such as the part’s view, other parts, or services. Connection points come in multiple types including ComponentProperty, ComponentCommand, ComponentNotification, and ServiceDependency.