The structure of current web frameworks is such that web developers have to adapt to the framework. Creating add-ons in these frameworks requires a number of things that developers must follow; in addition, developers can only create add-ons that fit the framework structure as well as the framework programming language. So the add-on is created just for the framework; in other words, they are framework-oriented. In this report, we address the various dimensions of a add-on-oriented framework that has been coordinated with mouthpiece development add-ons by applying measures in its structure.
The proposed framework offers a new architecture; the name of the framework architecture is add-ons-oriented.
The .NET Dynamic Server Framework for Microsoft .NET Server has been chosen as the platform for creating this framework. This option allows developers to take advantage of the Elanat framework, as well as take advantage of the .NET server dynamic page framework. For example, a developer could create an add-on in the framework provided that uses both the template and the .NET server dynamic page extensions.
Figure 1 is a comparison of the deployment of templates and add-ons on the Elanat framework and the .NET framework.
Figure 2 shows the add-on call architecture in the Elanat framework compared to the .NET Framework and Interpreter Frameworks.
Each of the different parts of the Elanat framework template is divided into an xml template file. This file allows you to change the design of different places in the framework using the modification method. First, the required add-ons are replaced with the variables in the template file tags, and then the various locations of the template file are aggregated and loaded on the main page.
In this framework, the template is separated from the style. Each template can support multiple styles (css). The template determines the different locations of the frame and the style determines how the different locations of the frame are displayed.
The method of calling aspx pages in Elanat framework is shown in the following images:
Figure 5 shows a full web page.
Figure 6 shows a variable in web page.
Figure 7 shows the contents of the add-on file. The Elanat framework first calls the variable in web page and then replaces the variable value ($ _body_value;) with the content of the add-on file.
It is not possible to change the internal codes of commercial libraries, free of charge and some source code due to strict licensing; it is not possible to change the internal library in compiled frameworks. To make this change, the developer is required to change the code of the previous library method to the code of the new library method. This operation needs to be recompiled in compiled languages. The following problems arise when changing the library:
Requires access to root or server operating system
Require manual change to develop framework
Unable to install the original framework add-ons in the modified framework
In this report, we describe the use of the method of creating an interface library to interact with a variety of commercial libraries, free and open source; the interface library contains only the functions that the framework kernel needs. Creating such a library allows framework developers to interact only with functions in the interface library, and if they need more functions than the main library, they are required to create a function call copy in the interface library. Developers who want to create add-ons in the framework are also required to interact with the functions of the interface library; if the add-ons needs to use more functions that are available in the main library but not in the interface library, it only extends the interface library. Using the interface library includes the following benefits:
Change the library by installing the add-ons with just one click
No need to change the functions of free and open source commercial libraries
Ability to quickly change free commercial libraries and open source code within the framework
Ability to maintain the main library and provide the interface library to the customer
No need to change the framework kernel code
Ability to use multiple libraries, simply by changing the location of the interface library
The interface library creates interface methods only for the methods required by the framework core of the main library.
Example: Ccoder and decoder library
Main library (including coder and decoder methods)
Interface library (including coder and decoder interface methods)
Core Framework (interaction with the interface library)
Note: A separate dll is created for each interface library; the possibility of using multiple libraries is possible only by changing the location of the interface library.
An information file in the add-on directory path specifies how the add-on interacts with the core of the framework; this add-on contains the following information:
add-on name
add-on category
add-on executable file directory path
add-on executable file name
add-on call type
Information that is placed in the header of the main page
Tags that run with the add-on
Internal installation path of the add-on
Internal removal path of the add-on
The main file path of the add-on management
Access paths to add, edit and delete add-on
and etc
Using the provided interface causes the add-on to still be compatible with the framework after updating the framework due to the separation of the add-on and the core of the framework.