crossbar.network._web

Attributes

Classes

SiteFlask

The flask object implements a WSGI application and acts as the central

Functions

Module Contents

HAS_HIGHLIGHT = True[source]
class SiteFlask(import_name: str, static_url_path: str | None = None, static_folder: str | os.PathLike[str] | None = 'static', static_host: str | None = None, host_matching: bool = False, subdomain_matching: bool = False, template_folder: str | os.PathLike[str] | None = 'templates', instance_path: str | None = None, instance_relative_config: bool = False, root_path: str | None = None)[source]

Bases: flask.Flask

The flask object implements a WSGI application and acts as the central object. It is passed the name of the module or package of the application. Once it is created it will act as a central registry for the view functions, the URL rules, template configuration and much more.

The name of the package is used to resolve resources from inside the package or the folder the module is contained in depending on if the package parameter resolves to an actual python package (a folder with an __init__.py file inside) or a standard module (just a .py file).

For more information about resource loading, see open_resource().

Usually you create a Flask instance in your main module or in the __init__.py file of your package like this:

from flask import Flask
app = Flask(__name__)

About the First Parameter

The idea of the first parameter is to give Flask an idea of what belongs to your application. This name is used to find resources on the filesystem, can be used by extensions to improve debugging information and a lot more.

So it’s important what you provide there. If you are using a single module, __name__ is always the correct value. If you however are using a package, it’s usually recommended to hardcode the name of your package there.

For example if your application is defined in yourapplication/app.py you should create it with one of the two versions below:

app = Flask('yourapplication')
app = Flask(__name__.split('.')[0])

Why is that? The application will work even with __name__, thanks to how resources are looked up. However it will make debugging more painful. Certain extensions can make assumptions based on the import name of your application. For example the Flask-SQLAlchemy extension will look for the code in your application that triggered an SQL query in debug mode. If the import name is not properly set up, that debugging information is lost. (For example it would only pick up SQL queries in yourapplication.app and not yourapplication.views.frontend)

Added in version 0.7: The static_url_path, static_folder, and template_folder parameters were added.

Added in version 0.8: The instance_path and instance_relative_config parameters were added.

Added in version 0.11: The root_path parameter was added.

Added in version 1.0: The host_matching and static_host parameters were added.

Added in version 1.0: The subdomain_matching parameter was added. Subdomain matching needs to be enabled manually now. Setting SERVER_NAME does not implicitly enable it.

Parameters:
  • import_name – the name of the application package

  • static_url_path – can be used to specify a different path for the static files on the web. Defaults to the name of the static_folder folder.

  • static_folder – The folder with static files that is served at static_url_path. Relative to the application root_path or an absolute path. Defaults to 'static'.

  • static_host – the host to use when adding the static route. Defaults to None. Required when using host_matching=True with a static_folder configured.

  • host_matching – set url_map.host_matching attribute. Defaults to False.

  • subdomain_matching – consider the subdomain relative to SERVER_NAME when matching routes. Defaults to False.

  • template_folder – the folder that contains the templates that should be used by the application. Defaults to 'templates' folder in the root path of the application.

  • instance_path – An alternative instance path for the application. By default the folder 'instance' next to the package or module is assumed to be the instance path.

  • instance_relative_config – if set to True relative filenames for loading the config are assumed to be relative to the instance path instead of the application root.

  • root_path – The path to the root of the application files. This should only be set manually when it can’t be detected automatically, such as for namespace packages.

jinja_options[source]
_USERNAME_PAT_STR = None[source]
app[source]
page_automotive()[source]
page_editor()[source]
page_home()[source]
page_impressum()[source]
page_industrial()[source]
page_privacy()[source]
page_xbr_address(address)[source]
page_xbr_address_query()[source]
page_xbr_channel(channel_adr)[source]
page_xbr_channel_query()[source]
page_xbr_console()[source]
page_xbr_market(market_id)[source]
page_xbr_market_query()[source]
page_xbr_member(member_adr=None)[source]
page_xbr_onboard()[source]
page_xbr_submit_onboard()[source]
page_xbr_verify_action()[source]
parser[source]