| 5 | | DeepaMehta is made to be extensible by 3rd-party developers. Developers extend DeepaMehta by developing plugins (resp. "modules" resp. "applications" which is all synonymous). This guide teaches you how to develop DeepaMehta plugins. |
| 6 | | |
| 7 | | == Architecture overview == |
| 8 | | |
| 9 | | Plugins play a central role in the DeepaMehta architectural picture. The sole DeepaMehta Core is quite small and contains no domain-specific logic at all. The main responsibility of the DeepaMehta Core is a) to be a runtime environment for DeepaMehta plugins, and b) to coordinate the access to the DeepaMehta database. All domain-specific data models and application logic is contained in plugins. In the diagram below you can see that a DeepaMehta plugin (colored green) can have both, a server-side portion and a client-side portion. |
| 10 | | |
| 11 | | [[Image(wiki:ArchitectureOverview:Architecture.png)]] |
| 12 | | |
| 13 | | A DeepaMehta plugin can have several parts: |
| 14 | | |
| 15 | | * **A data model**. The data model is a collection of domain-specific topic types and/or association types. |
| 16 | | |
| 17 | | * **Server-side logic**. Server-side logic comes in form of a) event handlers, and/or b) service methods. Server-side logic is written in Java. |
| 18 | | |
| 19 | | * **Client-side logic**. Client-side logic runs inside the DeepaMehta Webclient. Client-side logic comes in form of a) event handlers, b) custom renderers, and/or c) public API methods. Client-side logic is written in JavaScript. |
| 20 | | |
| 21 | | Each of these parts is optional. Which parts a plugin provides depends on its purpose. |
| | 5 | DeepaMehta is made to be extensible by external developers. Developers extend DeepaMehta by developing plugins (resp. "modules" resp. "applications" which is all synonymous). This guide teaches you how to develop DeepaMehta plugins. |
| | 6 | |
| | 7 | To see how a DeepaMehta plugin fits in the overall DeepaMehta architecture go to [[ArchitectureOverview|Architecture Overview]]. |
