[Original] Shenma, you are also called Biji? Zhige's God bi-plug-in system

ArticleDirectory

• (2) system execution process and data process
• (1) System Requirements

1. Preface

The title is just for the publisher, but the technology used is very popular. Haha: sharpdevelop4.0 addintree (plug-in architecture depends on it), csla. net, Caliburn. mirco (mvvm), devexpress control group. Well, this is an excellent design. I admit that it relies on these disgusting technologies and the interface of B to highlight x eyes of the review.

Not much.Code? Vomit, not directly connected to the paper.

If you are interested in the code, go to http://kingmon.codeplex.com/( a dozen MB is too big to upload). If you want to get started with sd4.0, csla. net, Caliburn, you can refer to it for a little.

 

2. Interface

First, click the interface to quench your thirst:

Black window start, faster, stronger, and more B.

Ribbon interface, office2010 style, more dazzling and more loaded.

Plug-ins.

This, that style, I admit I use Win98 ....

 

 

 

Task Management plug-in

 

 

Project Structure

3. Thesis

 

 

Abstract: The personal software platform of Agnes is a plug-in architecture that provides unified data presentation interfaces, data processing interfaces, and data storage interfaces, A personal application platform that facilitates other developers to develop plug-ins. Its plug-in kernel is based on the sharpdevelop 4.0 plug-in tree kernel. The interface framework adopts the latest. net interface rendering technology WPF. At the same time, a set of mvvm Based on the WPF three-layer architecture is developed for plug-in developers, which integrates the Caliburn. Micro framework (Vm layer) and csla. NET Framework (model layer. This allows plug-in developers to focus more on the business logic, rather than spending too much effort on the plug-in architecture and interface layout.

Keywords: plug-in architecture; mvvm; WPF; data interface; plug-in development framework; csla; Caliburn;

 

I. Introduction

...... Thousands of nonsense are omitted here

Significance of the system

The plug-in kernel of the system is restructured based on the sharpdevelop4.0 plug-in kernel. sharpdevelop is a well-known open source C # ide compiler. At present, there is a lot of foreign information about the sharpdevelop plug-in tree kernel, but the plug-in system developed using its kernel does not exist. This system uses the sharpdevelop plug-in tree kernel, A plug-in mechanism is re-developed. The Code is also distributed to the Microsoft open-source platform codeplex. Provides an example of the sharpdevelop plug-in kernel development system for other developers.

The system not only applies the sharpdevelop plug-in tree, but also uses Microsoft's latest interface technology WPF and adopts the most popular mvvm architecture for development. The mvvm architecture adopts two open-source frameworks: Caliburn. Micro and csla. net. Therefore, the architecture and design of the entire system also provide a good reference for other developers.

Development goals of the system

Developed a plug-in platform that supports plug-in operations, user-friendly interface, Simple plug-in development methods, and easy to understand.

 

Ii. Feasibility Analysis

(1) system initialization process

Figure 2.1 system initialization Flowchart

Figure 2.1 system initialization Flowchart

Description of the system initialization flowchart:

When the platform starts, it first checks the registry key. If the registry does not have any associated platform solutionProgramTo fix the registry key.

Start the plug-in service on the platform to load the file, search for the addins folder under the installation directory, and the file contains. addin configuration file and. DLL files are loaded into the system and read. the plug-in configuration and plug-in information of The addin file. If the interface to be started with the platform is specified in the plug-in configuration, the plug-in startup code is executed based on the code entry information provided by the plug-in configuration.

After the plug-in is loaded and initialized, the system checks whether the command parameters are included in the startup program. If the command parameters are included, the system determines whether the parameter is the complete solution path, if yes, load the solution. (After you click the solution icon, you can run the platform startup command containing command parameters)

Next, initialize the toolbar service and workspace service on the platform interface, and load the code containing the workspace configuration in the plug-in configuration file.

 

(2) system execution process and data process

Figure 2.2. System Execution Process

Figure 2.2. System implementation process

After the system is initialized in the previous step, the system waits for the user to load the solution. When the user chooses to load the solution, the system will notify each plug-in to read the data in the solution. After the user completes the operation, when the system is shut down, the system will also notify the plug-in solutions to be closed, and each plug-in will save user data. After the plug-in stores data, the system will close the solution, wait for the user to proceed. In this case, you can choose to reload the solution or shut down the system. The entire process is similar to that of the office software.

 

Iii. Requirement Analysis (I) System Requirements

1. use case diagram

This system analysis uses object-oriented analysis and design. The following describes the requirements for the two types of user plug-in developers and end users of this system, as shown in:

Figure 3.1. End-user-oriented use case diagram

Figure 3.1. Face final user case digoal

Figure 3.2. Example for plug-in developers

Figure 3.2. The plugin developers use case digoal

2. use case description

In addition to data storage services, the platform also provides

1. Log Service: plug-in developers can also use the Log service provided by the platform to manage exception information.

2. Plug-in service: plug-in developers can extend their plug-in functions by defining plug-in extension interfaces.

3. entity layer service: plug-in developers can also use the entity layer service to facilitate mvvm development.

4. interface service: plug-in developers can use the interface provided by the system to link self-developed controls to the main interface of the platform.

 

Iv. Outline Design

(1) system top-level package diagram design

Figure 4.1 system package diagram

Figiure 4.1 system package digoal

Description of each package:

1. icsharpcode. Core: this package is transformed Based on the sharpdevelop4.0 kernel and mainly provides plug-in tree loading and maintenance.

2. Agnes. Core: this package is the core of the entire platform. It encapsulates icsharpcode. core,

Provides more convenient plug-in Tree operations. It also provides basic platform services such as Attribute Service, Log service, and solution service. It also provides base classes based on the mvvm plug-in development framework.

3. Agnes. startup: this service mainly calls the Agnes. Core Package and provides startup operations, maintenance of Registry File Association, and other functions.

4. Agnes. Mainframe: the control in devexpress is encapsulated to provide function extension for the entire platform interface of the plug-in.

 

(2) detailed data structure design of Agnes. Core

Figure 4.2 Agnes. Core Package Diagram

Figure 4.2 The Agnes. Core Package digoal

A detailed description of each class:

1. agnesservicemanager: This class integrates all the services on the platform. The plug-in can call this class to obtain information about any service or call a service of a task. It mainly includes: propertyservice, workbenchservice, slnservice, and logservice.

2. agnesworkbenchservice: This service provides an interface for interaction between the plug-in and the platform interface framework.

3. agnesslnservice: a service that enables, disables, creates, and manages a solution.

4. logservice: this service is responsible for log management and storage. The plug-in can call this service to output logs.

5. idocumentpanel: interface of the Document Interface of the interface framework. To add a document view to the interface framework, the plug-in must first provide a class that implements the interface, then, the document view is displayed on the interface through agnesworkbenchserivce.

6. iworkbenchpad: interface of the information interface on the left of the interface framework. To add an Information view to the interface framework, the plug-in must first provide a class that implements this interface, then, the document view is displayed on the interface through agnesworkbenchserivce.

7. agnessln: the entity class of the storage solution

8. screenbase: a base class that encapsulates the viewmodel framework Caliburn. micro.

9. modelbase: it is the base class that encapsulates the model framework csla. net.

 

(3) detailed data structure design of Agnes. Mainframe

Figure 4.3 Agnes. Mainframe package diagram

Figure 4.3 The Agnes. Mainframe package digoal

A detailed description of each class:

1. mainwindow: the WPF Main Window of the entire program.

2. mainframeview: it carries the view of the entire dxribbon framework and is the main interface of the entire platform.

3. mainframeviewmodel: it is the viewmodel of mainframeview and mainly provides a data source. It will call the workbenchservice of Agnes. Core and read the iworkbenchpad and idocumentpanel data of workbenchservice and bind it to the mainframeview interface.

4. newslnview and newslnviewmodel: interfaces and data operations for creating a solution.

5. openslnview and openslnviewmodel: Open the solution interface and data operations.

 

5. Detailed Design

(1) Structure of the Program System

Figure 5.1 program structure

Fig 5.1 the program structure digoal

(2) program module design

1. Plug-in tree

(1) module description

The plug-in tree is the core part of the plug-in mechanism implemented on the entire Agnes platform. It is obtained from sharpdevelop4.0 [1] and modified on it.

(2) module functions

The plug-in tree provides plug-in search, plug-in loading, and plug-in interface management functions for the entire platform.

(3) module process logic

Use charts (such as flowcharts and decision tables) with necessary instructions to express the logical process of the program.

(4) Module Design

Figure 5.2 addintreenode class diagram

Figure 5.2 addintreenode class digoal

Description: addintreenode represents an extension node in the plug-in tree. It is generated from the. addin configuration file. Through its buildchilditem function, you can obtain the objects on the plug-in. This is the main way to call the system plug-in.

Figure 5.3 addintree class chart

Figure 5.3 addintree class digoal

Description: addintree represents the entire plug-in tree, which is composed of addintreenode. With insertaddins, removeaddin can add, delete, and modify the entire plug-in tree.

Figure 5.4 addinmanager class diagram

Figure 5.4 addinmanager class digoal

Description: addinmanager is the plug-in manager, which encapsulates the operations of the plug-in tree. It is mainly used to read the plug-in configuration from the plug-in configuration file and insert it into the plug-in tree.

(5) Module Interface

In the initialization process of the Upper-layer module Agnes. Core (see figure 1), the search plug-in calls this module for plug-in loading.

 

2. Solution Module

(1) module description

The solution is used to store the user data of the entire platform and all plug-ins. It is actually a compressed package. In the compressed package, each plug-in has a data storage folder. This module mainly describes the solution entity class and provides the packaging and package solution methods.

(2) module functions

1. describes the basic information of the solution.

2. Provides compression and decompression solutions.

(3) Module Design

Figure 5.5 agnessln class diagram

Figure 5.5 agnessln class digoal

Description: it is an entity class that uses the csla. Net object framework.

1. Each solution has a tempdir attribute. This attribute refers to the temporary folder to which the solution is extracted after it is opened.

2. Package and unpackage: The Package function compresses temporary folders specified by tempdir into a solution, while unpackage is the opposite. Note that unpackage cannot be decompressed if you need a password. Unless the required password is entered during unpackage decompression.

3. Other attributes:

Fullname: complete solution storage path and file name

Locateddir: solution storage path

Slnname: solution name

Figure 5.6 agnesslnservice class diagram

Figure 5.6 agnesslnservice class digoal

Details: agnesslnservice is a static class that encapsulates agnessln operations. It mainly manages the solutions used in the current running environment.

1. Use currentsln to obtain the solution opened in the current environment. If not, it is null.

2. The plug-in can be notified when the user opens or closes the solution by attaching the event to slncloesdhandler or slnopenedhandler.

3. You can use opensln or closeandsavecurrentsln to open or close the solution.

 

 

3. interface framework module

(1) module description

The interface framework module provides the interface for the plug-in to insert the view required by the plug-in the interface framework.

(2) module functions

1. Read the code about the plug-in to display the view in the framework in the plug-in configuration.

2. interfaces provided for external users to add views to the Framework

(3) Module Design

A. interface framework Description:

The entire interface framework uses the WPF interface development technology [2]. The main interface is shown in:

Figure 5.7 Interface Description

Fig 5.7 Interface Description

: The interface framework is divided into three areas: workbenchpad, toolpad, and documentpanel.

A) workbenchpad: This area is used as a display of some overview information. To add your own views in this area, add the following elements to the. addin configuration file:

<Path name = "Agnes/workbench/workbenchpad">

<Workbenchpad id = "Agnes. mydocslib. mydocslibsmarttreepad"

Class = "Agnes. mydocslib. mydocslibsmarttreepad"/>

</Path>

(1) The element name is a plug-in tree path such as Agnes/workbench/workbenchpad.

(2) the class of this element points to a class inside the plug-in about this view. This class must implement the iworkbenchpad interface.

B) toolpad: This area is displayed as the plug-in toolbar. If you want to add your own toolbar to the toolbar of the interface framework, you must add the following elements in. addin:

<Path name = "Agnes/Mainframe/toolpad">

<Toolpad id = "Agnes. mydocslib. toolpad"

Padstyle = "Other/toolpad/mydocslibtoolpad. XAML"

Baritemskey = "mydocslibbaritems"

Ribbonpagekey = "mydocslibribbonpage"

/>

</Path>

(1) The element name attribute is a plug-in tree path such as Agnes/workbench/toolpad.

(2) The padstyle attribute should point to the XAML code that describes the toolpad.

(3) baritemskey: Specifies the section in the XAML code that contains the detailed layout and control information of the toolpad.

(4) ribbonpagekey: the page of the toolpad to be added.

C) documentpanel: This area is the document view. If the plug-in wants to add a document to the region after the user executes some operations, the plug-in should declare a class that implements idocumentpanel, add the documentpanels set of agnesworkbenchservice to the runtime.

 

B. iworkbenchpad

Figure 5.8 iworkbenchpad class diagram

Figure 5.8 iworkbenchpad class digoal

Details: This is an interface that any workbenchpad attached to the interface needs to implement.

1. Content: This attribute is the usercontrol of the entire workbenchpad.

2. imageuri: This attribute is the icon before the title of workbenchpad.

3. ishide: indicates whether the workbenchpad is hidden or displayed.

4. Title: The title of workbenchpad.

 

5. workbenchposition: the position of the workbenchpad.

C. idocumentpanel

Figure 5.9 idocumentpanel class diagram

Figure 5.9 idocumentpanel class digoal

 

Description: idocumentpanel is an interface required to add a document view in the document view Gallery of the interface framework.

1. Caption and captionimage: The title and title icons of the document view.

2. content: the content in the document view.

3. isdirty: indicates whether the document content has been modified by the user. This attribute can be used to determine whether to save it.

4. isvaild: indicates whether the document content has been correctly filled in after being modified by the user.

5. Cancel function: Close the view without saving it.

6. previewclose function: This function is triggered before closing the view. You can enter the operations required to close the view in the function.

7. Save function: Save the view

D. agnesworkbenchservice

.

Figure 5.10 agnesworkbenchservice class diagram

Figure 5.10 agnesworkbenchservice class digoal

Details: agnesworkbenchservice is the main class to implement this module. This class contains the workbenchpad, toolpad, and documentpad of all the plug-ins currently running. The Agnes. Mainframe module also reads various interface information from the class and binds the information on the interface. The plug-in adds the interface to be displayed to the corresponding attribute through this class. It is an important bridge between plug-ins and interfaces.

Important attributes:

1. baritems: the control on the toolpad.

2. bottompads, rightpads, and leftpads: in fact, they are all displayed on workbenchpad in different locations.

3. focuseddocumentpanel: The documentpanel with the current focus

 

4. Log Service

(1) module description

Log Service uses the open-source log4net logging module to provide the plug-in or platform with a way to record information when an error occurs. It displays the log information in two places: files in the log folder under the console and installation directory.

(2) module functions

1. provides an interface for the plug-in to output logs.

2. Display logs in real time in the console window

3. Save logs to files when the system is disabled

(3) Module Design

Log4netservice

Figure 5.11 log class diagram

Figure 5.11 log class digoal

Description: This type provides the log output function. You can directly call the log output information at the following levels: Debug, error, fatal, info, and warn.

It must be noted that log4netloggingservice is integrated into agnesservicemanager. Therefore, to use Log service, you need to manage the service.

 

5. Plug-in development framework

(1) module description

The plug-in development framework encapsulates the operations of the csla. Net [3] and Caliburn. Micro [4] Open-source frameworks that implement the mvvm architecture, facilitating and unifying plug-in development.

(2) module functions

1. Provide the encapsulation base class screenbase Of The Caliburn framework at the VM layer in the plug-in development framework.

2. Provide the model layer Entity Framework csla encapsulation base class modelbase in the plug-in development framework.

(3) Module Design

A. screenbase

Figure 5.12 screenbase class diagram

Figure 5.12 screenbase class digoal

 

Screenbase is inherited from the screen in Caliburn and encapsulates and simplifies some of the operations.

Some functions are described as follows:

1. createview (): This function needs to be implemented by sub-classes. It mainly returns the view instance corresponding to this viewmodel.

2. getview (): You can use this function to find the usercontrol WPF view [5] based on a model instance.

3. onmodelchanged (): this function is triggered when model1 changes.

4. tryclose (): this function is triggered when the user closes or logs out the corresponding view.

 

B. modelbase

Figure 5.13 modelbase class diagram

Figure 5.13 modelbase class digoal

Modelbase is inherited from the business base class in csla. It can manage object states, perform multiple revocation, data verification, and other functions.

Some of the functions are described in detail:

1. createaschild (): This function requires subclass implementation. Subclass mainly adds the default field for object initialization in this function.

2. fetchaschild (): This function requires sub-class implementation. The sub-class mainly loads objects based on parameters in this function. The parameters are generally of the xelement type.

3. Rewrite the Save method in the subclass: savetoxml () to save the object to XML.

 

Vi. operation instructions

1. Program directory description

Figure 7.3 program directory

Fig 7.3 The program directory

Shows the entire program directory:

A. addins Folder: Mainly stores plug-ins and plug-in configurations. The mainframe folder under it stores the system interface framework plug-ins, while the app folder stores the application plug-ins of the entire platform.

B. Bin: main directory of the program.

C. Data: information configuration files of the entire platform

D. Log: stores log files.

 

2. Start

Run bin \ agnes.exe directly. You can see that the program runs from the console ,:

Figure 7.4 program startup Console

Figure 7.4 program to start the Console

 

After a series of initialization, you can see the entire interface framework:

Figure 7.5 main interface framework

Fig 7.5 main interface framework

This is an original UI framework without any plug-ins. Next we will start to install the plug-ins.

 

4. Install the plug-in

Next we will install the document library management plug-in. First, we will put the compiled plug-in library mydocslib. dll and the plug-in configuration file mydocslib. addins into the addins \ app \ mydocslib folder in the program directory.

Restart the program and you can see that the view and toolbar added by the plug-in are displayed on the main interface framework, as shown in:

Figure 7.6 UI framework after plug-in

. Fig. 7.6 in accordance with the plug-in interface framework

 

5. Solution Management

Click Start to go to solution management, as shown in:

Figure 7.7 start button

Fig 7.7 the start button

 

The following is the solution creation interface:

Figure 7.8 New Solution

Figure 7.8 New Solutions

 

Enter relevant information and click Create solution. After the solution is created, the system automatically opens the solution. If encryption is not required, leave the solution blank.

It should be noted that, during the use of the platform, if the input information does not comply with the specifications, a verification error occurs and the button is disabled, as shown in:

Figure 7.9 solution page after error information is entered

Fig 7.9 input errors after SOLUTION INTERFACE

 

Second, you can select the Open tab to open the solution, as shown in:

Figure 7.10 open the solution page

Fig 7.10 The Open SOLUTION INTERFACE

6. View logs

In the log folder of the installation directory, there is a log file for each running program. Open it in a text editor and you can view it. As shown in:

Figure 7.11 log folder

Fig 7.11 The log folder

 

Open a file, as shown in:

Figure 7.12 log files

Fig 7.12the Log File

Each section above represents a log, from which you can see the log trigger time, exception level, a class, and other information.

 

VII. Summary and prospects

After more than half a year of research, design, and coding, the system finally achieved its goal. Although the entire system is in use, there are still some operations that are inconvenient and difficult to understand. In terms of plug-ins, due to the time relationship, the entire system is still not allowed to intelligently manage the plug-ins. Therefore, you must install and uninstall the plug-ins according to the instructions, these two points are shortcomings and need to be improved.

During the development process, we also encountered many difficult problems. For example, the sharpdevelop plug-in system has less information in China and many are incomplete. As a result, it took a lot of effort to understand the plug-in tree and plug-in mechanism. In the end, you can only download sharpdevelop from the official website.Source code. After a long period of research, I finally had a deep understanding of the entire plug-in tree mechanism and developed a plug-in mechanism for my own platform based on my own needs. Second, the understanding of csla. net. It is also because almost no one in China can find complete information on csla research and application, which leads to inaccurate understanding at the beginning. Finally, the developed platform found many defects in csla, for example, the data revocation and rollback functions can only communicate with the original author on the official website, thus solving this problem.

For future prospects, the entire system architecture has been developed and the plug-in development framework is mature. In the plug-in development framework, our team members also developed two plug-ins with practical functions. It proves the feasibility of the entire development framework and plug-in architecture. The architecture and design of this system will be of great reference value and practical significance for both commercial and other software development in the future.