This document represents the documentation for the GFlashy Cards documentation. This documentation will change continuously since it serves also as documentation for the developer.
Overview: Architecture / StructurePlugin-Architecture: have core + plugins which are as much as possible detached from the main application. Each plugin has well defined responsibilities (encapsulates them).
Project structure with responsibilites- CustomUIFramework
Encapsulates the whole UI related stuff such as dynamically loading plugins, parsing their according configuration files and creating the ContributionItems with the according Actions.
- Common
- search/loading/initialization of available plugins
- contains the core domain objects
- (sharing common services with all plugins)
- GFlashyCards
- responsible for applicaton startup
- defines the main UI layout and structure
- Plugins (compiled as dll's and loaded into the project dynamically)
- each plugin encapsulates a well defined responsibility
- doesn't interact with the main GFlashyCards UI interface
- uses classes in Common to access Persistency layer (or go over Business Layer <-- Verify) etc...
Actions (Eclipse Action like style)- different components:
- ContributionItem: UI related stuff (rendering of button etc...)
- Action: non-UI related stuff (Command pattern)
- ActionContributionItem: combining both components
- Global / local action items
- global action items:
loaded initially and always displayed on the main application UI toolbar. Load on toolbar at startup when instantiating the plugin configurations - local action items:
dependent on the currently displayed view. Load them on the toolbar dynamically when the view gets displayed (create a new toolbar?)
Application Start-up Scenario- GFlashyCards WPF app
- PluginLoader retrieves all deployed plugins (dlls) in the application's "Plugin" directory.
- builds the registered actions from the plugin configuration file (plugin.xml)
- For each plugin a main button is added, which (when executed) delegates to a call to the Activator class of the corresponding plugin
- the Activator loads the set of actions for the corresponding plugin
- returns a reference to the main view for being displayed on the main application window
Candidates for Plugins- Import plugin
For loading the dataset into the application from external sources (GDocs, CSV,...) - Quizzer
UI StuffVery simple: On top a list of buttons which change dynamically depending on the context the user is currently in. Some buttons remain static on all contexts In the middle a list with the created/imported flash cards (title + snippet of description smaller below) UML DiagramsSequence DiagramsApplication Startup and Plugin loading(still to be added) MindmapProblems to be handled- Dynamic loading of plugin dependencies
The problem is that a plugin may depend on one or more external (3rd-party) plugins. In that case also these plugins have to be loaded at run-time. The idea could be to separately define these dependencies in the plugin.xml --> however overhead (2x definition). If possible dependencies should be detected and resolved automatically.
Development Links |
|