Commit 552d7b5a authored by unknown's avatar unknown

README update

parent 686b721f
Pipeline #3354 passed with stage
in 30 seconds
# Backend
## Python - Flask
TODO: remove statics and templates, all presentation logic goes to frontend project .
\ No newline at end of file
# Backend service
Primary purpose of backend container is to provide REST API over server services. Server is
responsible for parsing report, saving, updating and retrieving files.
- <b>conf</b> - Contains uwsgi.ini file, which servers as uWSGI web application server configuration. Do <b>NOT</b> edit settings
directly, instead use script <b>wsgi_init.py</b>, which loads all environment variables passed from
docker and then write settings to uwsgi.ini.
- <b>core</b> - Contains core logic of server. In core folder are primary two classes, core and guesser. Core
class servers as middleware between application and data logic. Purpose of Guesser class is to set
parsing tool automatically.
- <b>logger</b> - In <b>BETA</b> version, servers as logging tool.
- <b>parse</b> - Contains all parsing tools
- <b>resources</b> - Contains version(s) of API. Each version <b>MUST</b> contain particular server
endpoints.
- <b>tests</b> - Contains untit test, which are part of Gitlab CI. Unit tests are powered by Python's
unittest framework.
<pre>
├───conf
├───core
├───logger
├───log_dir
├───parse
├───resources
│ └───v1
│ └───endpoints
├───tests
└───uploaded_files
</pre>
### Extending Backend
As it is described in thesis, adding more parsers to backend service requires to follow some
procedures. First of all, new parser class <b>MUST</b> inherit from GenericParser class. Very basic implementation
of GenericParser is shown below.
- Purpose of register method is to tell GenericParser, that you want to expose your parser. In implementation
of this method, you <b>MUST</b> set tool property. In case it was not set, your parser will not be
available. Tool property is actually object, that holds information about each parser. There are two
necessary and one optional information that are need to be set. First of all, you need to set name
for you ConcreteParser, which will be showed on frontend service. Secondly, you need to set list of
supported extension by you ConcreteParser. Third, optionally property is regex pattern, that will server
use if in incoming request was not specified parsing tool.
- In parse method, parsing is done. Each part of report <b>MUST</b> be saved to Report object. All report
objects then must be saved to pre-defined structure.
<pre>
+------------------+  
|                  |   + tool : Tool
|  Generic     |   -------------------
|  Parser      |   + register() : void
|                  |  + parse()  :void
+------------------+  
ʌ
|
|
|
+------------------+  
|                  |                    
|  Concrete     |   
|  Parser      |   
|                  |                    
+------------------+  
</pre>
\ No newline at end of file
"""
@author Jakub Dolejsi
"""
class ImportClassException(BaseException):
pass
\ No newline at end of file
"""
@author Jakub Dolejsi
"""
class ParseException(BaseException):
......
"""
@author Jakub Dolejsi
"""
class SaveReportException(BaseException):
pass
\ No newline at end of file
"""
@author Jakub Dolejsi
"""
class WrongClassException(BaseException):
pass
\ No newline at end of file
......@@ -24,7 +24,16 @@ For example, request ```http://localhost:8080/api/v1/tools``` will be redirected
and in response you will get all supported report parsing tools.
### Project description
As you can see below, root folder contains also <b>tests</b> folder. Tests are separated into
- <b>backend</b> - backend service, more described in backend README.
- <b>doc</b> - contain main project documentation.
- <b>examples</b> - Examples folder contains basic source codes/report examples, which can demonstrate purpose of this
application.
- <b>frontend</b> - frontend service, more described in frontend README.
- <b>tests</b> Main application tests.
Tests are separated into
two categories.
- <b>System tests</b> - System tests are powered by Python's testing framework called Pytest.
......@@ -36,10 +45,6 @@ two categories.
Selenium framework. Purpose acceptance tests are to test GUI functionality. Each test is based on
Gherkin scenario, which is implemented in <b>steps</b> folder.
Examples folder contains basic source codes/report examples, which can demonstrate purpose of this
application.
<pre>
├───<b>backend</b>
......@@ -60,108 +65,8 @@ application.
</pre>
## Backend service
Primary purpose of backend container is to provide REST API over server services. Server is
responsible for parsing report, saving, updating and retrieving files.
- <b>conf</b> - Contains uwsgi.ini file, which servers as uWSGI web application server configuration. Do <b>NOT</b> edit settings
directly, instead use script <b>wsgi_init.py</b>, which loads all environment variables passed from
docker and then write settings to uwsgi.ini.
- <b>core</b> - Contains core logic of server. In core folder are primary two classes, core and guesser. Core
class servers as middleware between application and data logic. Purpose of Guesser class is to set
parsing tool automatically.
- <b>logger</b> - In <b>BETA</b> version, servers as logging tool.
- <b>parse</b> - Contains all parsing tools
- <b>resources</b> - Contains version(s) of API. Each version <b>MUST</b> contain particular server
endpoints.
- <b>tests</b> - Contains untit test, which are part of Gitlab CI. Unit tests are powered by Python's
unittest framework.
<pre>
├───conf
├───core
├───logger
├───log_dir
├───parse
├───resources
│ └───v1
│ └───endpoints
├───tests
└───uploaded_files
</pre>
### Extending Backend
As it is described in thesis, adding more parsers to backend service requires to follow some
procedures. First of all, new parser class <b>MUST</b> inherit from GenericParser class. Very basic implementation
of GenericParser is shown below.
- Purpose of register method is to tell GenericParser, that you want to expose your parser. In implementation
of this method, you <b>MUST</b> set tool property. In case it was not set, your parser will not be
available. Tool property is actually object, that holds information about each parser. There are two
necessary and one optional information that are need to be set. First of all, you need to set name
for you ConcreteParser, which will be showed on frontend service. Secondly, you need to set list of
supported extension by you ConcreteParser. Third, optionally property is regex pattern, that will server
use if in incoming request was not specified parsing tool.
- In parse method, parsing is done. Each part of report <b>MUST</b> be saved to Report object. All report
objects then must be saved to pre-defined structure.
<pre>
+------------------+  
|                  |   + tool : Tool
|  Generic     |   -------------------
|  Parser      |   + register() : void
|                  |  + parse()  :void
+------------------+  
ʌ
|
|
|
+------------------+  
|                  |                    
|  Concrete     |   
|  Parser      |   
|                  |                    
+------------------+  
</pre>
## Frontend service
Purpose os frontend container is to provide friendly user interface over whole application. Frontend
container also servers as router inside docker subnet. Routing proved Nginx.
- <b>dist</b> In production version, this folder contains compiled & minified version of frontend
service.
- <b>nginx</b> Configuration of Nginx. Here is possible to set additional reverse proxy to another service.
- <b>node_modules</b> - All node modules required by frontend service. Do <b>NOT</b> manually edit.
- <b>public</b> - Favicon icons.
- <b>src</b> - Sources code of frontend project.
<hr>
- <b>assets</b> - Additionally images.
- <b>boots</b> - Vue init and import libraries.
- <b>components</b> - All *.vue components.
- <b>config</b> - Mapping url from docker environment variable to Vue runtime variable.
- <b>css</b> - Global application styles
- <b>helpers</b> - Helper classes.
- <b>pages</b> - All pages of application.
- <b>router</b> - Vue router.
<pre>
├───dist
├───nginx
├───node_modules
├───public
└───src
├───assets
├───boot
├───components
├───config
├───css
├───helpers
├───pages
└───router
</pre>
......
# Quasar App (frontend)
# Frontend service
A Quasar Framework app
Purpose os frontend container is to provide friendly user interface over whole application. Frontend
container also servers as router inside docker subnet. Routing proved Nginx.
## Install the dependencies
```bash
yarn
```
- <b>dist</b> In production version, this folder contains compiled & minified version of frontend
service.
- <b>nginx</b> Configuration of Nginx. Here is possible to set additional reverse proxy to another service.
- <b>node_modules</b> - All node modules required by frontend service. Do <b>NOT</b> manually edit.
- <b>public</b> - Favicon icons.
- <b>src</b> - Sources code of frontend project.
<hr>
### Start the app in development mode (hot-code reloading, error reporting, etc.)
```bash
quasar dev
```
- <b>assets</b> - Additionally images.
- <b>boots</b> - Vue init and import libraries.
- <b>components</b> - All *.vue components.
- <b>config</b> - Mapping url from docker environment variable to Vue runtime variable.
- <b>css</b> - Global application styles
- <b>helpers</b> - Helper classes.
- <b>pages</b> - All pages of application.
- <b>router</b> - Vue router.
### Lint the files
```bash
yarn run lint
```
### Build the app for production
```bash
quasar build
```
### Customize the configuration
See [Configuring quasar.conf.js](https://quasar.dev/quasar-cli/quasar-conf-js).
<pre>
├───dist
├───nginx
├───node_modules
├───public
└───src
├───assets
├───boot
├───components
├───config
├───css
├───helpers
├───pages
└───router
</pre>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment