mirror of https://github.com/ae-utbm/sith3.git
Finish the report
This commit is contained in:
Skia
parent
13461268d0
commit
3a746d010a
127
Doxyfile
127
Doxyfile
|
|
@ -38,20 +38,20 @@ PROJECT_NAME = Sith
|
|||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER =
|
||||
PROJECT_NUMBER =
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
# quick idea about the purpose of the project. Keep the description short.
|
||||
|
||||
PROJECT_BRIEF =
|
||||
PROJECT_BRIEF =
|
||||
|
||||
# With the PROJECT_LOGO tag one can specify an logo or icon that is included in
|
||||
# the documentation. The maximum height of the logo should not exceed 55 pixels
|
||||
# and the maximum width should not exceed 200 pixels. Doxygen will copy the logo
|
||||
# to the output directory.
|
||||
|
||||
PROJECT_LOGO =
|
||||
PROJECT_LOGO =
|
||||
|
||||
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
|
||||
# into which the generated documentation will be written. If a relative path is
|
||||
|
|
@ -154,7 +154,7 @@ FULL_PATH_NAMES = YES
|
|||
# will be relative from the directory where doxygen is started.
|
||||
# This tag requires that the tag FULL_PATH_NAMES is set to YES.
|
||||
|
||||
STRIP_FROM_PATH =
|
||||
STRIP_FROM_PATH =
|
||||
|
||||
# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
|
||||
# path mentioned in the documentation of a class, which tells the reader which
|
||||
|
|
@ -163,7 +163,7 @@ STRIP_FROM_PATH =
|
|||
# specify the list of include paths that are normally passed to the compiler
|
||||
# using the -I flag.
|
||||
|
||||
STRIP_FROM_INC_PATH =
|
||||
STRIP_FROM_INC_PATH =
|
||||
|
||||
# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
|
||||
# less readable) file names. This can be useful is your file systems doesn't
|
||||
|
|
@ -230,13 +230,13 @@ TAB_SIZE = 4
|
|||
# "Side Effects:". You can put \n's in the value part of an alias to insert
|
||||
# newlines.
|
||||
|
||||
ALIASES =
|
||||
ALIASES =
|
||||
|
||||
# This tag can be used to specify a number of word-keyword mappings (TCL only).
|
||||
# A mapping has the form "name=value". For example adding "class=itcl::class"
|
||||
# will allow you to use the command class in the itcl::class meaning.
|
||||
|
||||
TCL_SUBST =
|
||||
TCL_SUBST =
|
||||
|
||||
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
|
||||
# only. Doxygen will then generate output that is more tailored for C. For
|
||||
|
|
@ -280,7 +280,7 @@ OPTIMIZE_OUTPUT_VHDL = NO
|
|||
# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
|
||||
# the files are not read by doxygen.
|
||||
|
||||
EXTENSION_MAPPING =
|
||||
EXTENSION_MAPPING =
|
||||
|
||||
# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
|
||||
# according to the Markdown format, which allows for more readable
|
||||
|
|
@ -616,7 +616,7 @@ GENERATE_DEPRECATEDLIST= YES
|
|||
# sections, marked by \if <section_label> ... \endif and \cond <section_label>
|
||||
# ... \endcond blocks.
|
||||
|
||||
ENABLED_SECTIONS =
|
||||
ENABLED_SECTIONS =
|
||||
|
||||
# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
|
||||
# initial value of a variable or macro / define can have for it to appear in the
|
||||
|
|
@ -658,7 +658,7 @@ SHOW_NAMESPACES = YES
|
|||
# by doxygen. Whatever the program writes to standard output is used as the file
|
||||
# version. For an example see the documentation.
|
||||
|
||||
FILE_VERSION_FILTER =
|
||||
FILE_VERSION_FILTER =
|
||||
|
||||
# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
|
||||
# by doxygen. The layout file controls the global structure of the generated
|
||||
|
|
@ -671,7 +671,7 @@ FILE_VERSION_FILTER =
|
|||
# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
|
||||
# tag is left empty.
|
||||
|
||||
LAYOUT_FILE =
|
||||
LAYOUT_FILE =
|
||||
|
||||
# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
|
||||
# the reference definitions. This must be a list of .bib files. The .bib
|
||||
|
|
@ -682,7 +682,7 @@ LAYOUT_FILE =
|
|||
# search path. Do not use file names with spaces, bibtex cannot handle them. See
|
||||
# also \cite for info how to create references.
|
||||
|
||||
CITE_BIB_FILES =
|
||||
CITE_BIB_FILES =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to warning and progress messages
|
||||
|
|
@ -741,7 +741,7 @@ WARN_FORMAT = "$file:$line: $text"
|
|||
# messages should be written. If left blank the output is written to standard
|
||||
# error (stderr).
|
||||
|
||||
WARN_LOGFILE =
|
||||
WARN_LOGFILE =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the input files
|
||||
|
|
@ -792,7 +792,7 @@ RECURSIVE = YES
|
|||
# Note that relative paths are relative to the directory from which doxygen is
|
||||
# run.
|
||||
|
||||
EXCLUDE =
|
||||
EXCLUDE =
|
||||
|
||||
# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
|
||||
# directories that are symbolic links (a Unix file system feature) are excluded
|
||||
|
|
@ -809,7 +809,8 @@ EXCLUDE_SYMLINKS = NO
|
|||
# exclude all test directories for example use the pattern */test/*
|
||||
|
||||
EXCLUDE_PATTERNS = */migrations/* \
|
||||
*/admin.py
|
||||
*/admin.py \
|
||||
*env_sith/*
|
||||
|
||||
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
|
||||
# (namespaces, classes, functions, etc.) that should be excluded from the
|
||||
|
|
@ -820,13 +821,13 @@ EXCLUDE_PATTERNS = */migrations/* \
|
|||
# Note that the wildcards are matched against the file with absolute path, so to
|
||||
# exclude all test directories use the pattern */test/*
|
||||
|
||||
EXCLUDE_SYMBOLS =
|
||||
EXCLUDE_SYMBOLS =
|
||||
|
||||
# The EXAMPLE_PATH tag can be used to specify one or more files or directories
|
||||
# that contain example code fragments that are included (see the \include
|
||||
# command).
|
||||
|
||||
EXAMPLE_PATH =
|
||||
EXAMPLE_PATH =
|
||||
|
||||
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
|
||||
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
|
||||
|
|
@ -846,7 +847,7 @@ EXAMPLE_RECURSIVE = NO
|
|||
# that contain images that are to be included in the documentation (see the
|
||||
# \image command).
|
||||
|
||||
IMAGE_PATH =
|
||||
IMAGE_PATH =
|
||||
|
||||
# The INPUT_FILTER tag can be used to specify a program that doxygen should
|
||||
# invoke to filter for each input file. Doxygen will invoke the filter program
|
||||
|
|
@ -863,7 +864,7 @@ IMAGE_PATH =
|
|||
# code is scanned, but not when the output code is generated. If lines are added
|
||||
# or removed, the anchors will not be placed correctly.
|
||||
|
||||
INPUT_FILTER =
|
||||
INPUT_FILTER =
|
||||
|
||||
# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
|
||||
# basis. Doxygen will compare the file name with each pattern and apply the
|
||||
|
|
@ -872,7 +873,7 @@ INPUT_FILTER =
|
|||
# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
|
||||
# patterns match the file name, INPUT_FILTER is applied.
|
||||
|
||||
FILTER_PATTERNS =
|
||||
FILTER_PATTERNS =
|
||||
|
||||
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
|
||||
# INPUT_FILTER ) will also be used to filter the input files that are used for
|
||||
|
|
@ -887,14 +888,14 @@ FILTER_SOURCE_FILES = NO
|
|||
# *.ext= (so without naming a filter).
|
||||
# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
|
||||
|
||||
FILTER_SOURCE_PATTERNS =
|
||||
FILTER_SOURCE_PATTERNS =
|
||||
|
||||
# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
|
||||
# is part of the input, its contents will be placed on the main page
|
||||
# (index.html). This can be useful if you have a project on for instance GitHub
|
||||
# and want to reuse the introduction page also for the doxygen output.
|
||||
|
||||
USE_MDFILE_AS_MAINPAGE =
|
||||
USE_MDFILE_AS_MAINPAGE =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to source browsing
|
||||
|
|
@ -1006,7 +1007,7 @@ COLS_IN_ALPHA_INDEX = 5
|
|||
# while generating the index headers.
|
||||
# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
|
||||
|
||||
IGNORE_PREFIX =
|
||||
IGNORE_PREFIX =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the HTML output
|
||||
|
|
@ -1050,7 +1051,7 @@ HTML_FILE_EXTENSION = .html
|
|||
# of the possible markers and block names see the documentation.
|
||||
# This tag requires that the tag GENERATE_HTML is set to YES.
|
||||
|
||||
HTML_HEADER =
|
||||
HTML_HEADER =
|
||||
|
||||
# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
|
||||
# generated HTML page. If the tag is left blank doxygen will generate a standard
|
||||
|
|
@ -1060,7 +1061,7 @@ HTML_HEADER =
|
|||
# that doxygen normally uses.
|
||||
# This tag requires that the tag GENERATE_HTML is set to YES.
|
||||
|
||||
HTML_FOOTER =
|
||||
HTML_FOOTER =
|
||||
|
||||
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
|
||||
# sheet that is used by each HTML page. It can be used to fine-tune the look of
|
||||
|
|
@ -1072,7 +1073,7 @@ HTML_FOOTER =
|
|||
# obsolete.
|
||||
# This tag requires that the tag GENERATE_HTML is set to YES.
|
||||
|
||||
HTML_STYLESHEET =
|
||||
HTML_STYLESHEET =
|
||||
|
||||
# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user-
|
||||
# defined cascading style sheet that is included after the standard style sheets
|
||||
|
|
@ -1083,7 +1084,7 @@ HTML_STYLESHEET =
|
|||
# see the documentation.
|
||||
# This tag requires that the tag GENERATE_HTML is set to YES.
|
||||
|
||||
HTML_EXTRA_STYLESHEET =
|
||||
HTML_EXTRA_STYLESHEET =
|
||||
|
||||
# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
|
||||
# other source files which should be copied to the HTML output directory. Note
|
||||
|
|
@ -1093,7 +1094,7 @@ HTML_EXTRA_STYLESHEET =
|
|||
# files will be copied as-is; there are no commands or markers available.
|
||||
# This tag requires that the tag GENERATE_HTML is set to YES.
|
||||
|
||||
HTML_EXTRA_FILES =
|
||||
HTML_EXTRA_FILES =
|
||||
|
||||
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
|
||||
# will adjust the colors in the stylesheet and background images according to
|
||||
|
|
@ -1221,7 +1222,7 @@ GENERATE_HTMLHELP = NO
|
|||
# written to the html output directory.
|
||||
# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
|
||||
|
||||
CHM_FILE =
|
||||
CHM_FILE =
|
||||
|
||||
# The HHC_LOCATION tag can be used to specify the location (absolute path
|
||||
# including file name) of the HTML help compiler ( hhc.exe). If non-empty
|
||||
|
|
@ -1229,7 +1230,7 @@ CHM_FILE =
|
|||
# The file has to be specified with full path.
|
||||
# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
|
||||
|
||||
HHC_LOCATION =
|
||||
HHC_LOCATION =
|
||||
|
||||
# The GENERATE_CHI flag controls if a separate .chi index file is generated (
|
||||
# YES) or that it should be included in the master .chm file ( NO).
|
||||
|
|
@ -1242,7 +1243,7 @@ GENERATE_CHI = NO
|
|||
# and project file content.
|
||||
# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
|
||||
|
||||
CHM_INDEX_ENCODING =
|
||||
CHM_INDEX_ENCODING =
|
||||
|
||||
# The BINARY_TOC flag controls whether a binary table of contents is generated (
|
||||
# YES) or a normal table of contents ( NO) in the .chm file.
|
||||
|
|
@ -1272,7 +1273,7 @@ GENERATE_QHP = NO
|
|||
# the HTML output folder.
|
||||
# This tag requires that the tag GENERATE_QHP is set to YES.
|
||||
|
||||
QCH_FILE =
|
||||
QCH_FILE =
|
||||
|
||||
# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
|
||||
# Project output. For more information please see Qt Help Project / Namespace
|
||||
|
|
@ -1297,7 +1298,7 @@ QHP_VIRTUAL_FOLDER = doc
|
|||
# filters).
|
||||
# This tag requires that the tag GENERATE_QHP is set to YES.
|
||||
|
||||
QHP_CUST_FILTER_NAME =
|
||||
QHP_CUST_FILTER_NAME =
|
||||
|
||||
# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
|
||||
# custom filter to add. For more information please see Qt Help Project / Custom
|
||||
|
|
@ -1305,21 +1306,21 @@ QHP_CUST_FILTER_NAME =
|
|||
# filters).
|
||||
# This tag requires that the tag GENERATE_QHP is set to YES.
|
||||
|
||||
QHP_CUST_FILTER_ATTRS =
|
||||
QHP_CUST_FILTER_ATTRS =
|
||||
|
||||
# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
|
||||
# project's filter section matches. Qt Help Project / Filter Attributes (see:
|
||||
# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
|
||||
# This tag requires that the tag GENERATE_QHP is set to YES.
|
||||
|
||||
QHP_SECT_FILTER_ATTRS =
|
||||
QHP_SECT_FILTER_ATTRS =
|
||||
|
||||
# The QHG_LOCATION tag can be used to specify the location of Qt's
|
||||
# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
|
||||
# generated .qhp file.
|
||||
# This tag requires that the tag GENERATE_QHP is set to YES.
|
||||
|
||||
QHG_LOCATION =
|
||||
QHG_LOCATION =
|
||||
|
||||
# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
|
||||
# generated, together with the HTML files, they form an Eclipse help plugin. To
|
||||
|
|
@ -1452,7 +1453,7 @@ MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
|
|||
# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
|
||||
# This tag requires that the tag USE_MATHJAX is set to YES.
|
||||
|
||||
MATHJAX_EXTENSIONS =
|
||||
MATHJAX_EXTENSIONS =
|
||||
|
||||
# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
|
||||
# of code that will be used on startup of the MathJax code. See the MathJax site
|
||||
|
|
@ -1460,7 +1461,7 @@ MATHJAX_EXTENSIONS =
|
|||
# example see the documentation.
|
||||
# This tag requires that the tag USE_MATHJAX is set to YES.
|
||||
|
||||
MATHJAX_CODEFILE =
|
||||
MATHJAX_CODEFILE =
|
||||
|
||||
# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
|
||||
# the HTML output. The underlying search engine uses javascript and DHTML and
|
||||
|
|
@ -1520,7 +1521,7 @@ EXTERNAL_SEARCH = NO
|
|||
# Searching" for details.
|
||||
# This tag requires that the tag SEARCHENGINE is set to YES.
|
||||
|
||||
SEARCHENGINE_URL =
|
||||
SEARCHENGINE_URL =
|
||||
|
||||
# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
|
||||
# search data is written to a file for indexing by an external tool. With the
|
||||
|
|
@ -1536,7 +1537,7 @@ SEARCHDATA_FILE = searchdata.xml
|
|||
# projects and redirect the results back to the right project.
|
||||
# This tag requires that the tag SEARCHENGINE is set to YES.
|
||||
|
||||
EXTERNAL_SEARCH_ID =
|
||||
EXTERNAL_SEARCH_ID =
|
||||
|
||||
# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
|
||||
# projects other than the one defined by this configuration file, but that are
|
||||
|
|
@ -1546,7 +1547,7 @@ EXTERNAL_SEARCH_ID =
|
|||
# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
|
||||
# This tag requires that the tag SEARCHENGINE is set to YES.
|
||||
|
||||
EXTRA_SEARCH_MAPPINGS =
|
||||
EXTRA_SEARCH_MAPPINGS =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the LaTeX output
|
||||
|
|
@ -1607,7 +1608,7 @@ PAPER_TYPE = a4
|
|||
# If left blank no extra packages will be included.
|
||||
# This tag requires that the tag GENERATE_LATEX is set to YES.
|
||||
|
||||
EXTRA_PACKAGES =
|
||||
EXTRA_PACKAGES =
|
||||
|
||||
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
|
||||
# generated LaTeX document. The header should contain everything until the first
|
||||
|
|
@ -1623,7 +1624,7 @@ EXTRA_PACKAGES =
|
|||
# PROJECT_NAME), or the project number (see PROJECT_NUMBER).
|
||||
# This tag requires that the tag GENERATE_LATEX is set to YES.
|
||||
|
||||
LATEX_HEADER =
|
||||
LATEX_HEADER =
|
||||
|
||||
# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
|
||||
# generated LaTeX document. The footer should contain everything after the last
|
||||
|
|
@ -1632,7 +1633,7 @@ LATEX_HEADER =
|
|||
# Note: Only use a user-defined footer if you know what you are doing!
|
||||
# This tag requires that the tag GENERATE_LATEX is set to YES.
|
||||
|
||||
LATEX_FOOTER =
|
||||
LATEX_FOOTER =
|
||||
|
||||
# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
|
||||
# other source files which should be copied to the LATEX_OUTPUT output
|
||||
|
|
@ -1640,7 +1641,7 @@ LATEX_FOOTER =
|
|||
# markers available.
|
||||
# This tag requires that the tag GENERATE_LATEX is set to YES.
|
||||
|
||||
LATEX_EXTRA_FILES =
|
||||
LATEX_EXTRA_FILES =
|
||||
|
||||
# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
|
||||
# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
|
||||
|
|
@ -1740,14 +1741,14 @@ RTF_HYPERLINKS = NO
|
|||
# default style sheet that doxygen normally uses.
|
||||
# This tag requires that the tag GENERATE_RTF is set to YES.
|
||||
|
||||
RTF_STYLESHEET_FILE =
|
||||
RTF_STYLESHEET_FILE =
|
||||
|
||||
# Set optional variables used in the generation of an RTF document. Syntax is
|
||||
# similar to doxygen's config file. A template extensions file can be generated
|
||||
# using doxygen -e rtf extensionFile.
|
||||
# This tag requires that the tag GENERATE_RTF is set to YES.
|
||||
|
||||
RTF_EXTENSIONS_FILE =
|
||||
RTF_EXTENSIONS_FILE =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the man page output
|
||||
|
|
@ -1808,13 +1809,13 @@ XML_OUTPUT = xml
|
|||
# validating XML parser to check the syntax of the XML files.
|
||||
# This tag requires that the tag GENERATE_XML is set to YES.
|
||||
|
||||
XML_SCHEMA =
|
||||
XML_SCHEMA =
|
||||
|
||||
# The XML_DTD tag can be used to specify a XML DTD, which can be used by a
|
||||
# validating XML parser to check the syntax of the XML files.
|
||||
# This tag requires that the tag GENERATE_XML is set to YES.
|
||||
|
||||
XML_DTD =
|
||||
XML_DTD =
|
||||
|
||||
# If the XML_PROGRAMLISTING tag is set to YES doxygen will dump the program
|
||||
# listings (including syntax highlighting and cross-referencing information) to
|
||||
|
|
@ -1891,7 +1892,7 @@ PERLMOD_PRETTY = YES
|
|||
# overwrite each other's variables.
|
||||
# This tag requires that the tag GENERATE_PERLMOD is set to YES.
|
||||
|
||||
PERLMOD_MAKEVAR_PREFIX =
|
||||
PERLMOD_MAKEVAR_PREFIX =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the preprocessor
|
||||
|
|
@ -1932,7 +1933,7 @@ SEARCH_INCLUDES = YES
|
|||
# preprocessor.
|
||||
# This tag requires that the tag SEARCH_INCLUDES is set to YES.
|
||||
|
||||
INCLUDE_PATH =
|
||||
INCLUDE_PATH =
|
||||
|
||||
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
|
||||
# patterns (like *.h and *.hpp) to filter out the header-files in the
|
||||
|
|
@ -1940,7 +1941,7 @@ INCLUDE_PATH =
|
|||
# used.
|
||||
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
||||
|
||||
INCLUDE_FILE_PATTERNS =
|
||||
INCLUDE_FILE_PATTERNS =
|
||||
|
||||
# The PREDEFINED tag can be used to specify one or more macro names that are
|
||||
# defined before the preprocessor is started (similar to the -D option of e.g.
|
||||
|
|
@ -1950,7 +1951,7 @@ INCLUDE_FILE_PATTERNS =
|
|||
# recursively expanded use the := operator instead of the = operator.
|
||||
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
||||
|
||||
PREDEFINED =
|
||||
PREDEFINED =
|
||||
|
||||
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
|
||||
# tag can be used to specify a list of macro names that should be expanded. The
|
||||
|
|
@ -1959,7 +1960,7 @@ PREDEFINED =
|
|||
# definition found in the source code.
|
||||
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
||||
|
||||
EXPAND_AS_DEFINED =
|
||||
EXPAND_AS_DEFINED =
|
||||
|
||||
# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
|
||||
# remove all refrences to function-like macros that are alone on a line, have an
|
||||
|
|
@ -1988,13 +1989,13 @@ SKIP_FUNCTION_MACROS = YES
|
|||
# the path). If a tag file is not located in the directory in which doxygen is
|
||||
# run, you must also specify the path to the tagfile here.
|
||||
|
||||
TAGFILES =
|
||||
TAGFILES =
|
||||
|
||||
# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
|
||||
# tag file that is based on the input files it reads. See section "Linking to
|
||||
# external documentation" for more information about the usage of tag files.
|
||||
|
||||
GENERATE_TAGFILE =
|
||||
GENERATE_TAGFILE =
|
||||
|
||||
# If the ALLEXTERNALS tag is set to YES all external class will be listed in the
|
||||
# class index. If set to NO only the inherited external classes will be listed.
|
||||
|
|
@ -2042,14 +2043,14 @@ CLASS_DIAGRAMS = YES
|
|||
# the mscgen tool resides. If left empty the tool is assumed to be found in the
|
||||
# default search path.
|
||||
|
||||
MSCGEN_PATH =
|
||||
MSCGEN_PATH =
|
||||
|
||||
# You can include diagrams made with dia in doxygen documentation. Doxygen will
|
||||
# then run dia to produce the diagram and insert it in the documentation. The
|
||||
# DIA_PATH tag allows you to specify the directory where the dia binary resides.
|
||||
# If left empty dia is assumed to be found in the default search path.
|
||||
|
||||
DIA_PATH =
|
||||
DIA_PATH =
|
||||
|
||||
# If set to YES, the inheritance and collaboration graphs will hide inheritance
|
||||
# and usage relations if the target is undocumented or is not a class.
|
||||
|
|
@ -2098,7 +2099,7 @@ DOT_FONTSIZE = 10
|
|||
# the path where dot can find it using this tag.
|
||||
# This tag requires that the tag HAVE_DOT is set to YES.
|
||||
|
||||
DOT_FONTPATH =
|
||||
DOT_FONTPATH =
|
||||
|
||||
# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
|
||||
# each documented class showing the direct and indirect inheritance relations.
|
||||
|
|
@ -2236,26 +2237,26 @@ INTERACTIVE_SVG = NO
|
|||
# found. If left blank, it is assumed the dot tool can be found in the path.
|
||||
# This tag requires that the tag HAVE_DOT is set to YES.
|
||||
|
||||
DOT_PATH =
|
||||
DOT_PATH =
|
||||
|
||||
# The DOTFILE_DIRS tag can be used to specify one or more directories that
|
||||
# contain dot files that are included in the documentation (see the \dotfile
|
||||
# command).
|
||||
# This tag requires that the tag HAVE_DOT is set to YES.
|
||||
|
||||
DOTFILE_DIRS =
|
||||
DOTFILE_DIRS =
|
||||
|
||||
# The MSCFILE_DIRS tag can be used to specify one or more directories that
|
||||
# contain msc files that are included in the documentation (see the \mscfile
|
||||
# command).
|
||||
|
||||
MSCFILE_DIRS =
|
||||
MSCFILE_DIRS =
|
||||
|
||||
# The DIAFILE_DIRS tag can be used to specify one or more directories that
|
||||
# contain dia files that are included in the documentation (see the \diafile
|
||||
# command).
|
||||
|
||||
DIAFILE_DIRS =
|
||||
DIAFILE_DIRS =
|
||||
|
||||
# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
|
||||
# that will be shown in the graph. If the number of nodes in a graph becomes
|
||||
|
|
|
|||
|
|
@ -59,8 +59,7 @@
|
|||
|
||||
\tableofcontents
|
||||
|
||||
\chapter*{Introduction}
|
||||
\addcontentsline{toc}{chapter}{Introduction}
|
||||
\chapter{Introduction}
|
||||
\par Il y a longtemps, au début des années 2000, l'Association des Étudiants a mis en place un site internet qui n'a eu de
|
||||
cesse d'évoluer au fil des ans. Grâce aux différents contributeurs qui s'y sont plongés, et qui ont pu y ajouter leurs
|
||||
fonctionnalités plus ou moins utiles, le site possède désormais un ensemble de fonctionnalité impressionnant.
|
||||
|
|
@ -71,6 +70,10 @@ maintenir à l'heure actuelle, et le besoin d'une refonte s'imposait de plus en
|
|||
\par Le choix de technologies récentes, maintenues, et éprouvée a donc été fait, et le développement a pu commencer dès
|
||||
Novembre 2015, avec l'objectif d'une mise en production dans l'été 2016, au moins dans une version incluant
|
||||
l'intégralité des fonctions liées à l'argent, qui sont les plus critiques.
|
||||
\par Soutenant les projets libres, j'ai décidé de placer le projet sous licence MIT, assurant ainsi une pérénité aux
|
||||
source. Si quelqu'un dans le futur souhaite le relicencier sous GPL ou autre, cela reste possible, mais je n'impose au
|
||||
départ que très peu de restrictions \footnote{La seule condition en réalité, est de toujours garder à sa place une copie
|
||||
de la licence originale, à savoir le fichier LICENSE à la racine du site.} .
|
||||
|
||||
\chapter{Les technologies}
|
||||
\label{cha:les_technologies}
|
||||
|
|
@ -480,99 +483,223 @@ comptoirs et des produits, ainsi que des données de comptabilité.
|
|||
\par L'application \emph{Core} est de loin la plus importante de toutes. C'est elle qui gère les utilisateurs ainsi que
|
||||
leurs droits. Le CMS y est aussi définit pour tout ce qui est pages de Wiki, pages statiques, ou l'ajout du filtre
|
||||
\verb#markdown# pour les templates.
|
||||
|
||||
\subsection{Liste des modèles}
|
||||
\label{sub:liste_des_mod_les}
|
||||
\begin{itemize}
|
||||
\item \textbf{Group} \\
|
||||
Ce modèle se subdivise en deux: RealGroup et MetaGroup, décrivant respectivement un vrai groupe géré à la main
|
||||
dans la liste des groupes, et un meta-groupe, géré automatiquement, en général par les clubs, ou bien par les
|
||||
cotisations.
|
||||
\item \textbf{User} \\
|
||||
Le modèle des utilisateurs, qui est ensuite décliné ou référencé dans beaucoup d'applications pour les
|
||||
utilisations spécifiques. C'est toutefois ici que sont déclarés les fonctions de gestion des droits des
|
||||
utilisateurs, afin de pouvoir les utiliser partout ailleurs.
|
||||
\item \textbf{AnonymousUser} \\
|
||||
Cette classe n'est pas un modèle stocké en base, puisqu'elle sert à instancier la variable \verb#user#
|
||||
lorsqu'aucun utilisateur n'est connecté au site.
|
||||
\item \textbf{Page} \\
|
||||
Décrit une entité page, servant dans le Wiki ou pour les pages statiques du site. Cette classe s'occupe des
|
||||
méta-données de la page, comme ses droits, mais son contenu est en réalité stocké dans un objet \verb#PageRev#.
|
||||
\item \textbf{PageRev} \\
|
||||
Décrit une révision de page. Utiliser une autre classe avec une \verb#ForeignKey# permet de gérer facilement un
|
||||
historique des révisions.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{La gestion des droits}
|
||||
\label{sub:la_gestion_des_droits}
|
||||
\par La gestion des droits est implémentée de manière globale dans l'application Core.
|
||||
\par On trouve en effet dans \verb#views/__init__.py# un certain nombre de mixins \footnote{Un mixin est, en
|
||||
\emph{Django}, un terme désignant une classe abstraite qui ne peut pas servir de parente seule. Elle permet de
|
||||
surcharger certaines méthodes d'une autre classe abstraite afin de l'adapter à un comportement plus spécifique, mais
|
||||
reste totalement inutile quand elle est seule. La gestion des droits est un bon exemple puisqu'elle ne s'occupe pas
|
||||
vraiment de traitement des données comme les autres vues le ferait, elle permet simplement d'ajouter une condition à une
|
||||
autre classe où cette dernière renverrait un \emph{403 Forbidden} } s'occupant de cela, en se basant sur
|
||||
un modèle général permettant de rendre compatible rapidement n'importe quel modèle que l'on voudrait protéger. Il suffit
|
||||
alors de déclarer dans la classe une certain nombre de méthodes et/ou d'attributs, le reste étant simplement déjà pris
|
||||
en charge par les mixins suivants:
|
||||
\begin{itemize}
|
||||
\item \textbf{CanCreateMixin} \\
|
||||
Cette classe est à mettre en parente d'une classe héritant de \verb#CreateView#, afin d'empêcher quelqu'un
|
||||
n'ayant pas les droits de créer un objet.\\
|
||||
Méthode correspondante à créer dans les modèles: \\
|
||||
\verb#def can_be_created_by(user):# \\
|
||||
(Attention, ce n'est pas une méthode prenant \verb#self# en premier paramètre!)
|
||||
\item \textbf{CanEditPropMixin} \\
|
||||
Cette classe protège l'objet pour l'édition avancée. Par exemple: éditer les droits sur une page, ou éditer les
|
||||
droits accordé à un utilisateur. \\
|
||||
Attribut correspondant à créer dans les modèles: \\
|
||||
\verb#owner_group = models.ForeignKey(Group, # \\
|
||||
\verb# related_name="owned_user", default=settings.SITH_GROUPS['root']['id'])# \\
|
||||
Méthode correspondante à créer dans les modèles: \\
|
||||
\verb#def is_owned_by(self, user):# \\
|
||||
\item \textbf{CanEditMixin} \\
|
||||
Cette classe protège l'objet pour l'édition non avancée. Par exemple: éditer une page, ou éditer le profil d'un
|
||||
utilisateur. \\
|
||||
Attribut correspondant à créer dans les modèles: \\
|
||||
\verb#edit_groups = models.ManyToManyField(Group, # \\
|
||||
\verb# related_name="editable_user", blank=True)# \\
|
||||
Méthode correspondante à créer dans les modèles: \\
|
||||
\verb#def can_be_edited_by(self, user):# \\
|
||||
\item \textbf{CanEditPropMixin} \\
|
||||
Cette classe protège l'objet pour la vue. Par exemple: consulter une page, ou voir le profil d'un utilisateur. \\
|
||||
Attribut correspondant à créer dans les modèles: \\
|
||||
\verb#view_groups = models.ManyToManyField(Group, # \\
|
||||
\verb# related_name="viewable_user", blank=True)# \\
|
||||
Méthode correspondante à créer dans les modèles: \\
|
||||
\verb#def can_be_viewed_by(self, user):# \\
|
||||
\end{itemize}
|
||||
\par Pour savoir si l'on doit implémenter les méthodes, les attributs, ou les deux, il faut simplement se poser la
|
||||
question de savoir si l'objet en question requiert une gestion des droits à l'échelle de la classe ou à l'échelle de
|
||||
l'objet, et si cette gestion peut être calculé par de la logique.
|
||||
\par Si on a besoin d'une gestion pour la classe, ou si du code peut être implémenter pour déterminer qui peut avoir tel
|
||||
droit, alors la méthode suffira. Mais si on a besoin d'une gestion au niveau de l'objet, alors il faudra certainement
|
||||
recourir aux attributs.
|
||||
\par Exemples:
|
||||
\begin{itemize}
|
||||
\item Les comptes en banques sont gérés uniquement par les personnes faisant partie du groupe \verb#admin-compta#.
|
||||
Ils ont donc tous les même droits, c'est une gestion au niveau de la classe, donc les méthodes suffisent.
|
||||
\item Les classeurs de comptabilité sont gérés par les trésoriers des clubs, ils n'ont pas tous les même droits,
|
||||
mais cela peut tout de même se calculer en fonction des postes dans les clubs correspondants. On a donc besoin
|
||||
des méthodes uniquement.
|
||||
\item Les pages n'appartiennent pas forcément à un club, ni à une quelconque entité, mais ont tout de même besoin de
|
||||
gestion des droits au niveau de l'objet. L'ajout des attributs est donc nécessaire pour pouvoir gérer cela au
|
||||
cas par cas.
|
||||
\end{itemize}
|
||||
|
||||
\section{Subscription}
|
||||
\label{sec:subscription}
|
||||
\subsection{Résumé}
|
||||
\label{sub:r_sum_}
|
||||
\par Cette application étend le modèle \verb#User# pour y ajouter le support des cotisations. Elle fournit également les
|
||||
interfaces de cotisation.
|
||||
|
||||
\subsection{Liste des modèles}
|
||||
\label{sub:liste_des_mod_les}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Subscriber} \\
|
||||
Un modèle proxy de \verb#User# fournissant les méthodes pour rapidement savoir si l'utilisateur est cotisant ou
|
||||
non.
|
||||
\item \textbf{Subscription} \\
|
||||
Un modèle cotisation, pour stocker ces dernières. Cette classe fait automatiquement les calculs de début et de
|
||||
fin de cotisation en fonction de la date du jour, du type de cotisation, et de la durée en semestre de
|
||||
cotisation.
|
||||
\end{itemize}
|
||||
|
||||
\section{Accounting}
|
||||
\label{sec:accounting}
|
||||
\subsection{Résumé}
|
||||
\label{sub:r_sum_}
|
||||
\par Cette application sert à gérer à la comptabilité. Elle est architecturée de façon hiérarchique, avec en haut, les
|
||||
comptes bancaires réels, qui contiennent eux des comptes de clubs, permettant de les diviser en plusieurs petits comptes
|
||||
en interne, et enfin les classeurs de trésorerie, propres à chaque compte club, permettant de faire les comptes en
|
||||
triant par semestre.
|
||||
\par De plus, cette application définit un nouveau type de champ dans la base de donnée: le champ \verb#CurrencyField#,
|
||||
permettant de stocker de valeurs monétaires.
|
||||
|
||||
\subsection{Liste des modèles}
|
||||
\label{sub:liste_des_mod_les}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{BankAccount} \\
|
||||
Le modèle des comptes bancaires.
|
||||
\item \textbf{ClubAccount} \\
|
||||
Le modèle des comptes clubs.
|
||||
\item \textbf{GeneralJournal} \\
|
||||
Le modèle des classeurs de comptabilité, généralement semestriels, mais ils peuvent toutefois fonctionner en
|
||||
année pour les activités plus longues comme le Gala.
|
||||
\item \textbf{AccountingType} \\
|
||||
Le modèle pour stocker les types comptables, servant à remplir les opérations.
|
||||
\item \textbf{Operation} \\
|
||||
Le modèle des opérations, servant à remplir les classeurs comptables. Un opération peut être un débit ou un
|
||||
crédit, et permet ensuite d'éditer des factures, par exemple.
|
||||
\end{itemize}
|
||||
|
||||
\section{Counter}
|
||||
\label{sec:counter}
|
||||
\subsection{Résumé}
|
||||
\label{sub:r_sum_}
|
||||
\par Cette application s'occupe de la gestion des comptoirs. Elle définit ainsi des produits, et ajoute également le
|
||||
support du compte AE pour les utilisateurs.
|
||||
|
||||
\subsection{Liste des modèles}
|
||||
\label{sub:liste_des_mod_les}
|
||||
\begin{itemize}
|
||||
\item \textbf{Customer} \\
|
||||
Ce modèle étend l'utilisateur pour lui rajouter un compte AE. Il est lié à la classe \verb#User# par un
|
||||
\verb#OneToOneField#.
|
||||
\item \textbf{ProductType} \\
|
||||
Ce modèle ajoute des types de produits afin de catégoriser ces derniers.
|
||||
\item \textbf{Product} \\
|
||||
Ce modèle décrit les produits pouvant être vendus dans les différents comptoirs.
|
||||
\item \textbf{Counter} \\
|
||||
Ce modèle décrit les comptoirs, qui permettent de générer des recharges de compte et des ventes de produits.
|
||||
\item \textbf{Refilling} \\
|
||||
Ce modèle permet de stocker les rechargements de compte.
|
||||
\item \textbf{Selling} \\
|
||||
Ce modèle permet d'enregistrer toutes les ventes de produits.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Club}
|
||||
\label{sec:club}
|
||||
\subsection{Résumé}
|
||||
\label{sub:r_sum_}
|
||||
\par Cette application permet de générer les clubs et les adhésions des utilisateur à ceux-ci.
|
||||
|
||||
\subsection{Liste des modèles}
|
||||
\label{sub:liste_des_mod_les}
|
||||
\begin{itemize}
|
||||
\item \textbf{Club} \\
|
||||
Le modèle des clubs.
|
||||
\item \textbf{Membership} \\
|
||||
Le modèle des adhésions. Stocker cela dans un modèle à part permet de conserver un historique des personnes
|
||||
ayant eu un rôle quelconque dans un club quelconque.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\chapter*{Conclusion}
|
||||
\addcontentsline{toc}{chapter}{Conclusion}
|
||||
\chapter{Conclusion}
|
||||
\par Encore une fois, ce rapport ne se veut absolument pas exhaustif sur quoi que ce soit.
|
||||
\par Concernant \emph{Python}, \emph{Django}, ou \emph{Jinja}, les documentations respectives sont toujours très bien
|
||||
faites, et permettront de répondre à toutes les questions techniques concernant les technologies.
|
||||
\par Concernant le projet \emph{Sith} en lui-même, ce rapport n'est pas non plus exhaustif. Pour cela, lire le code des
|
||||
différentes sections sera le meilleur moyen de comprendre le fonctionnement des différentes fonctions. Pour obtenir plus
|
||||
rapidement un résumé à jour des sources, le fichier \verb#Doxyfile# présent à la racine du site permet de regénérer de
|
||||
la documentation exhaustive rapidement à l'aide de \emph{Doxygen} (voir la section correspondante dans le README).
|
||||
\par J'espère toutefois que même s'il n'est pas complet, ce rapport permettra à tout futur contributeur de rentrer plus
|
||||
rapidement dans le projet.
|
||||
\par L'idéal serait également de maintenir à jour ce rapport du mieux possible en même temps que le développement
|
||||
avance, même si je ne me fais guère d'illusions en pratique.
|
||||
|
||||
\appendix
|
||||
\addtolength{\textheight}{60mm}
|
||||
\part*{Annexes}
|
||||
\addtolength{\topmargin}{-50mm}
|
||||
\definecolor{gray75}{gray}{0.75}
|
||||
\newcommand{\hsp}{\hspace{20pt}}
|
||||
\titleformat{\chapter}[block]{\Huge\bfseries}{\thechapter\hsp\textcolor{gray75}{|}\hsp}{0pt}{\Huge\bfseries}[\vskip -2em]
|
||||
\section{Pour le futur...}
|
||||
\label{sec:pour_le_futur}
|
||||
\par En l'état actuel des choses, un grand nombre d'éléments sont encore manquants au site:
|
||||
\begin{itemize}
|
||||
\item Une API REST pour pouvoir facilement intégrer d'autres outils autour du site.
|
||||
\item Du CSS, pour qu'il soit un peu plus joli à regarder.
|
||||
\item Du Javascript, et particulièrement de l'AJAX pour améliorer l'ergonomie de certaines pages.
|
||||
\item Un grand nombre de vues pour aider à gérer les données plus efficacement, ou à les gérer tout court dans
|
||||
certains cas.
|
||||
\item Quelques applications utiles à qui existent sur le site actuel, mais que je n'ai pas encore eu le temps de
|
||||
développer: un forum, une galerie de photos, une gestion basique des fichiers pour uploader des documents dans
|
||||
les pages ou le forum, un système de news, une newsletter (Weekmail), une gestion des sondages et des élections,
|
||||
etc...
|
||||
\end{itemize}
|
||||
|
||||
% \chapter{Classe python}
|
||||
% \label{python_class}
|
||||
% \begin{figure}[H]
|
||||
% \begin{lstlisting}[language=python,morekeywords={True,False}]
|
||||
% host_to_host = Table("host_to_host", Base.metadata,
|
||||
% Column("cluster_id", Integer, ForeignKey("host.host_id"), primary_key=True),
|
||||
% Column("node_id", Integer, ForeignKey("host.host_id"), primary_key=True)
|
||||
% )
|
||||
% class Host(Base):
|
||||
% __tablename__ = 'host'
|
||||
% host_id = Column(Integer, primary_key=True, nullable=False)
|
||||
% groups = Column(String(30), ForeignKey("env.name"))
|
||||
% name = Column(String(30), unique=True, nullable=False,
|
||||
% default="UNKNOWN HOST")
|
||||
% address = Column(String(30), nullable=False, default="0.0.0.0")
|
||||
% alias = Column(String(30), nullable=True, default="")
|
||||
% state = Column(String(10), nullable=False, default=0)
|
||||
% num_services = Column(Integer, nullable=False, default=0)
|
||||
% num_services_crit = Column(Integer, nullable=False, default=0)
|
||||
% num_services_unknown = Column(Integer, nullable=False, default=0)
|
||||
% num_services_warn = Column(Integer, nullable=False, default=0)
|
||||
% scheduled_downtime_depth = Column(Integer, nullable=False, default=0)
|
||||
% _json_extra = Column(Text, nullable=True)
|
||||
% _last_time = Column(DateTime, server_default=func.now(),
|
||||
% onupdate=func.current_timestamp())
|
||||
% _location = Column(String(4), nullable=True)
|
||||
% _nodes = relationship("Host",
|
||||
% backref="_clusters",
|
||||
% secondary=host_to_host,
|
||||
% primaryjoin=host_id==host_to_host.c.cluster_id,
|
||||
% secondaryjoin=host_id==host_to_host.c.node_id,
|
||||
% )
|
||||
% \end{lstlisting}
|
||||
% \caption{Classe python}
|
||||
% \end{figure}
|
||||
% \par
|
||||
% On voit bien que l'on définit les attributs de la classe à la manière des colonnes d'une table dans une base de
|
||||
% donnée.
|
||||
% \par
|
||||
% On met aussi ici en place une relation \emph{Many To Many} entre les Hosts à l'aide de la table de jointure définie
|
||||
% juste avant: \emph{host\_to\_host}.
|
||||
\section{Apports personnels}
|
||||
\label{sec:apports_personnels}
|
||||
\par Même s'il est vrai que j'ai beaucoup appris en développement ce site, cela reste avant tout un travail de quantité
|
||||
plus que de qualité: on définit des modèles, puis les vues correspondantes en terminant par les templates, et on répète
|
||||
l'opération pour l'application suivante.
|
||||
\par Mais j'ai tout de même pu mettre en place de l'intégration continue pour ce projet, ce qui a été certes, très
|
||||
rapide, mais toutefois très enrichissant, étant donnée que ces méthodes sont très en vogue ces derniers temps.
|
||||
\par J'ai également pu me familiariser d'avantage avec le fonctionnement d'un ORM, et la magie noire que cela permet de
|
||||
faire \footnote{Je trouve toujours magique de pouvoir faire une requête SQL au milieu d'un template sans que cela
|
||||
paraisse affreux :)}.
|
||||
\par Enfin, j'espère que ce projet va, en plus d'être correctement mené au bout, pouvoir être repris par la suite par
|
||||
les futurs membres de l'équipe info de l'AE, et pourquoi pas par d'autre contributeurs...
|
||||
\vskip 3em
|
||||
\emph{Skia <skia@libskia.so> - 2016}
|
||||
|
||||
\end{document}
|
||||
|
||||
%s/ \(SQLalchemy\|SQLite\)/ \\emph{\1}/
|
||||
|
|
|
|||
Loading…
Reference in New Issue