This software is an add-on-oriented CMS-Framework; the possibility of add-on-oriented software puts it in the category of frameworks and the possibility of presenting content on the web puts it in the category of content management systems.
The framework allows programmers, developers, and software designers to limit themselves to just software requirements and prevent multiple replications in the system production process.
Different people can have different definitions of a framework, perhaps calling a portal or content management system a framework, or naming software delivery facilities a framework.
Each system is a set of several add-ons that interact with each other. There is a column called the add-on category for each of the add-ons; specifying the category name with the same system name allows the system to be displayed in the frame with better access.
The mechanism that frameworks create to enable end-users to meet their needs more quickly is called an add-on. Some features that the user wants for the framework and are not available in the framework core can be added to the framework in an add-on format. The add-on allows all end users to meet their needs without programming knowledge. An add-on can add new features to the framework.
In this CMS-Framework, 8 types of add-ons are supported:
Component
Module
Plugin
Extra helper
Editor template
Fetch
Page
Patch
Separating the add-on from the core of the framework is called add-on-oriented.
The component can have different definitions in each system. Here we call the pages that only the administrator has access to the component. Plugins, modules, etc and even the component itself each has a component management page.
Add-ons that, in addition to being able to display, provide separate management for the add-on, are called modules. For example, RSS display with the ability to adjust the display of the number of contents as well as the cache duration is a module.
Add-ons that are purely visual are called plugins. For example, the add-on display of the user's IP or the add-on display of the number of turbine rotations in the last minute are divided into plugins.
Add-ons that are only enabled on the software management page and are available to software administrators. Changing the html content to xml writeable content is an example of an extra helper.
Pre-prepared templates to create new content. Like a text format as a slider or a template for displaying multiple photos as a slide.
An add-on to display the values obtained from the database through a query and list them in each part of the web pages.
Dynamic and static pages for display on the website.
A type of add-on that installs new features to Elanat by installing them, these features can be security patches or things like feed and sitemap xml for the website.
It is not possible to change the internal codes of commercial libraries, free of charge and some other cases due to the strict permission of the recipient; 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 with 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 the Elanat CMS, by using the interface library mechanism, including sockets and connectors, we provided the possibility of interacting with a variety of commercial, free and open source code libraries; 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-on in the framework are also required to interact with the functions of the interface library; if the add-on 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-on 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
Connector is an interface library between the socket and the external library.
Socket is a library and creates interface methods only for the methods required by the core of the framework library.
In CodeBehind framework the standrd syntax will also be created in the aspx files and the standrd syntax will be automatically determined from the Razor syntax. In addition, it is not possible to combine standard syntax and Razor syntax.
The standard syntax in CodeBehind is very similar to the aspx page syntaxes of Microsoft's former Web-Forms in ASP.NET Standard and classic asp pages, but in some cases there may be slight differences.
only View is the method of developing a part of the system, only with the aspx page without Controller and Model.
When you create a project under the CodeBehind framework, all classes (including Controller and Model) are compiled in a dll file; but aspx pages are rendered and compiled into one class when the project is first run.
ReCompile is a term related to the CodeBehind framework, which is the process of creating the final View class from aspx pages.
The final View class is built from rendering and separating server-side code from static values (like HTML).
The CodeBehind framework supports several attributes for view pages. Page attributes determine things like Layout and Controller for pages.
Return Template is a structured mechanism to improve code readability introduced by Elanat in the CodeBehind framework.
Using the Return Template separates the server-side code from the display part (such as HTML), so it fully complies with the Code-Behind pattern.
In CodeBehind, the physical executable pages (aspx) are placed in the root path, and this makes the program structured. CodeBehind supports web parts; web parts are like other parts of the project and include aspx files.
To add the web part in CodeBehind, just put the project files in the root. In CodeBehind, you can run web parts that make changes to aspx files. You can edit all aspx files during project execution and responding to users.
In CodeBehind, the structure of web-parts is the same as the structure of the main project; your main project includes aspx pages, dll files, and other client-side files (css, js, images, etc.); web parts in CodeBehind also include aspx pages, dll files and other client side files.
A layout is a top-level template for views in an application, which defines a common layout for pages, providing a consistent user experience as users navigate between pages. Layouts are particularly useful for web applications with shared UI elements, such as headers, navigation menus, and footers. By using layouts, you can reduce duplicate code in views and maintain a consistent look and feel across multiple pages in your application.
Section is a attribute that applies to aspx pages. Section is a feature whose activation makes all paths after the aspx path refer to the current aspx path. Section is one of the revolutionary ideas of the Elanat. Enabling section in aspx pages gives you full control over the paths.
Code-behind is a programming pattern that separates the presentation logic from the HTML code that allowing for a cleaner separation of concerns. It involves creating a separate class file for the code, which can help with maintainability and readability. Code-Behind contribute to maintaining code quality and readability.
The Elanat team introduces the framework created by itself as CodeBehind and calls the coding structure for the complete separation of the server part codes from the design part Code-Behind (uses the dash character to separate Code and Behind). If the name CodeBehind is confusing for you, you can call it Elanat CodeBehind or Elanat CodeBehind framework!
Common people usually know Code-Behind with Microsoft web-form. Please note that the CodeBehind framework is one of the most powerful and modern back-end frameworks and its structure has nothing to do with Microsoft's former web-form.
Action Controls are WebFormsJS received codes that are received in INI format. WebFormsJS automatically detects whether the server response has Action Controls or not. If the server's response is based on the structure of an INI file that starts with "[web-forms]", it will process the Action Controls, otherwise it will replace the server's response in the form of AJAX on the page.
Action Controls are received in the form of an INI file format. In the first line of the response there is the word [web-forms] and each of the following lines is an action control.
The first two characters determine the action code. For example, things like adding styles and removing tags can be obtained from action codes. Usually the first two letters stand for actions and indicate that an action must be performed.
After the first two letters, there are 6 status types that specify the tag. Then the equal character is placed and after that the values are placed.
Pre Runners are added before Action Control values. Each Pre Runner usually consists of one character, followed by the values of the Pre Runner, and then ends with the closing parenthesis ()) character.
WebFormsJS allows you to create web-forms tags on pages. The web-forms tags must have one of the src and ac attributes or both of them.
The ac attribute has the Action Controls value. The src attribute takes the value of a URL path.
