Warning
Starting from CubicWeb version 4.0 all code related to generating html views has been moved to the Cube cubicweb_web.
If you want to migrate a project from 3.38 to 4.* while still using all the
html views you need to both install the cubicweb_web cube AND add it to
your dependencies and run add_cube('web')
.
cubicweb_web can be installed from pypi this way:
pip install cubicweb_web
We donât plan to maintain the features in cubicweb_web in the long run; we are moving to a full javascript frontend using both cubicweb_api (which exposes a HTTP API) and @cubicweb/client as a frontend javascript toolkit.
In the long run cubicweb_api will be merged inside of CubicWeb.
Publisher#
What happens when an HTTP request is issued ?
The story begins with the CubicWebPublisher.main_publish
method. We do not get upper in the bootstrap process because it is
dependant on the used HTTP library.
What main_publish does:
get a controller id and a result set from the path (this is actually delegated to the urlpublisher component)
the controller is then selected (if not, this is considered an authorization failure and signaled as such) and called
then either a proper result is returned, in which case the request/connection object issues a
commit
and returns the resultor error handling must happen:
ValidationErrors
pop up there and may lead to a redirect to a previously arranged url or standard error handling appliesan HTTP 500 error (Internal Server Error) is issued
Now, letâs turn to the controller. There are many of them in
cubicweb_web.views.basecontrollers
. We can just follow the
default view controller that is selected on a view path. See the
Controllers chapter for more information on controllers.
The View controllerâs entry point is the publish method. It does the following:
compute the main view to be applied, using either the given result set or building one from a user provided rql string (rql and vid can be forced from the url GET parameters), that is:
compute the vid using the result set and the schema (see cubicweb_web.views.vid_from_rset)
handle all error cases that could happen in this phase
do some cache management chores
select a main template (typically TheMainTemplate, see chapter Templates)
call it with the result set and the computed view.
What happens next actually depends on the template and the view, but in general this is the rendering phase.
CubicWebPublisher API#
- class cubicweb_web.application.CubicWebPublisher(repo, config, session_handler_fact=<class 'cubicweb_web.application.CookieSessionHandler'>)[source]#
the publisher is a singleton hold by the web frontend, and is responsible to publish HTTP request.
The http server will call its main entry point
application.handle_request
.- main_handle_request(req)[source]#
Process an HTTP request req
- Parameters
req (web.Request) â the request object
It returns the content of the http response. HTTP header and status are set on the Request object.
You have to provide both a repository and web-server config at initialization. In all in one instance both config will be the same.
- core_handle(req)[source]#
method called by the main publisher to process <req> relative path
should return a string containing the resulting page or raise a NotFound exception
- Parameters
req (web.Request) â the request object
- Return type
str
- Returns
the result of the pusblished url
- critical(msg, *args, **kwargs)#
Log âmsg % argsâ with severity âCRITICALâ.
To pass exception information, use the keyword argument exc_info with a true value, e.g.
logger.critical(âHouston, we have a %sâ, âmajor disasterâ, exc_info=True)
- debug(msg, *args, **kwargs)#
Log âmsg % argsâ with severity âDEBUGâ.
To pass exception information, use the keyword argument exc_info with a true value, e.g.
logger.debug(âHouston, we have a %sâ, âthorny problemâ, exc_info=True)
- error(msg, *args, **kwargs)#
Log âmsg % argsâ with severity âERRORâ.
To pass exception information, use the keyword argument exc_info with a true value, e.g.
logger.error(âHouston, we have a %sâ, âmajor problemâ, exc_info=True)
- exception(msg, *args, exc_info=True, **kwargs)#
Convenience method for logging an ERROR with exception information.
- get_session(req)[source]#
Return a session object corresponding to credentials held by the req
May raise AuthenticationError.
- info(msg, *args, **kwargs)#
Log âmsg % argsâ with severity âINFOâ.
To pass exception information, use the keyword argument exc_info with a true value, e.g.
logger.info(âHouston, we have a %sâ, âinteresting problemâ, exc_info=True)
- log_handle_request(req)[source]#
wrapper around _publish to log all queries executed for a given accessed path
- main_handle_request(req)[source]#
Process an HTTP request req
- Parameters
req (web.Request) â the request object
It returns the content of the http response. HTTP header and status are set on the Request object.
- redirect_handler(req, ex)[source]#
handle redirect - comply to ex status - set header field - return empty content
- warning(msg, *args, **kwargs)#
Log âmsg % argsâ with severity âWARNINGâ.
To pass exception information, use the keyword argument exc_info with a true value, e.g.
logger.warning(âHouston, we have a %sâ, âbit of a problemâ, exc_info=True)