diff options
Diffstat (limited to 'docs/design.md')
| -rw-r--r-- | docs/design.md | 41 |
1 files changed, 40 insertions, 1 deletions
diff --git a/docs/design.md b/docs/design.md index 4ab2e887..aff49183 100644 --- a/docs/design.md +++ b/docs/design.md | |||
| @@ -49,6 +49,39 @@ Use-case specific controllers are used to operate on the data. Controllers allow | |||
| 49 | Rather than splitting controllers by domain type (e.g. an email controller, or a calendar controller), we specifically write controllers for specific usecases (e.g. an email editor), that exposes all required actions. That way we ensure that the API's a UI is working with is always clear an consice, and that we have all domain logic captured in the domain logic layer, rather than the UI layer. | 49 | Rather than splitting controllers by domain type (e.g. an email controller, or a calendar controller), we specifically write controllers for specific usecases (e.g. an email editor), that exposes all required actions. That way we ensure that the API's a UI is working with is always clear an consice, and that we have all domain logic captured in the domain logic layer, rather than the UI layer. |
| 50 | Of course controllers will need to share functionality internally as soon as an action is available from more than one place. | 50 | Of course controllers will need to share functionality internally as soon as an action is available from more than one place. |
| 51 | 51 | ||
| 52 | ### Email Domain Logic | ||
| 53 | * Folder list | ||
| 54 | * Folder List Controller | ||
| 55 | * Move mail to folder | ||
| 56 | * Move/Copy/Delete folder | ||
| 57 | * Synchronize folder | ||
| 58 | * Folder List Model | ||
| 59 | * Mixes akonadi next queries and subqueries (folder list with smart folders) | ||
| 60 | * name | ||
| 61 | * statistics | ||
| 62 | |||
| 63 | * Mail list | ||
| 64 | * MailListController | ||
| 65 | * Mark as read | ||
| 66 | * Flag as important | ||
| 67 | * Move to trash | ||
| 68 | * MailListModel | ||
| 69 | * subject | ||
| 70 | * date | ||
| 71 | * sender | ||
| 72 | * folder | ||
| 73 | * ThreadModel | ||
| 74 | * thread leader (otherwise like maillist model) | ||
| 75 | * number of mails in thread | ||
| 76 | |||
| 77 | * Mail Viewer | ||
| 78 | * MailViewController | ||
| 79 | * reply | ||
| 80 | * forward | ||
| 81 | * move to trash | ||
| 82 | * MailModel | ||
| 83 | * subject, date, sender, folder, content, attachments | ||
| 84 | |||
| 52 | ## Infrastructure | 85 | ## Infrastructure |
| 53 | 86 | ||
| 54 | The infrastructure layer interfaces with the rest of the system. It is the place where we can integrate with various native infrastructure parts. | 87 | The infrastructure layer interfaces with the rest of the system. It is the place where we can integrate with various native infrastructure parts. |
| @@ -59,8 +92,14 @@ Note: The infrastructure blocks will use only types provided by the domain logic | |||
| 59 | ### Akonadi Next | 92 | ### Akonadi Next |
| 60 | Akonadi Next is used for primary data access and handles all synchronization. | 93 | Akonadi Next is used for primary data access and handles all synchronization. |
| 61 | 94 | ||
| 95 | Interactions with Akonadi Next involve: | ||
| 96 | * Adding/removing/configuring resources | ||
| 97 | * Triggering synchronization | ||
| 98 | * Querying of data | ||
| 99 | * Creating/Modifying/Removing entities | ||
| 100 | |||
| 62 | ### Configuration | 101 | ### Configuration |
| 63 | Configuration as traditionally store in config files in ~/.kde | 102 | Configuration as traditionally stored in config files in ~/.kde |
| 64 | 103 | ||
| 65 | ### Notification | 104 | ### Notification |
| 66 | Notifications for the system. | 105 | Notifications for the system. |