cubicweb #2105837 Official API to transmit argument to a view in an url [deprecated]


Cubicweb web views can be called from python code of another view or from an HTTP request. Some views allow (or even require) extra parameters.

Python call example:

self.wview('table-seating', elephants_rset, ..., special_guest='babar')

HTTP call example:'babar'

When called from other view code, parameters are usually given as keyword parameters in an entry point call and processed by __init__ or render function of the View. When called through an HTTP request the babar parameter is available in self._cw.form and retrieved from there.

Using self._cw.form in a view is fragile. self._cw.form exists in the request scope and has therefore a much wider scope than the view's . Views do not know if compatible parameters in self._cw.form are intended for their use of not.

Moreover having multiple mechanisms to transmit arguments is suboptimal. People usually add the mechanism they need when writing the function and extra work is needed to implement the second mechanism. Having a single standard mechanism to transmit view parameters will help to have a consistent base of reusable views.


The two ways of calling a view with arguments MUST remain the same. We need the HTTP and the python way for that. My proposal covers the way arguments are processed and transmitted to the view.

On the view side of the API, I suggest to drop the self._cw.form way to retrieve arguments and to focus on the pythonic keyword argument way to transmit extra arguments.

Arguments received through HTTP requests populate the self._cw.form mapping. Those arguments are related to the HTTP request and, in my opinion, it is the controller's duty to process them. Views should not have to care about such processing. I suggest creating a dedicated "namespace" in HTTP argument dedicated to view parameters. For example, the special_guest argument will become varg:special_guest. Controllers calling views will be in charge of processing those parameters and transmitting them to the view. Arguments will only be transmitted to top level views called by the controller itself. Views will be in charge of recursively transmitting parameters or not.

New HTTP call example:'babar'

Having the controller remove vargs entry from the request form is to be discussed.

The way of calling views from python code is not affected. Deciding what in the view is in charge of processing parameter is not in the scope of this ticket. I don't know if parameters should be passed to view's initargs or to render kwargs.

done in<not specified>
load left0.000
closed by<not specified>
patch[view] Official API to transmit argument to a view in an url (closes #2105837) [rejected]