Blog entries by Stéphane Bugat [2]
  • Building your URLs in cubicweb

    2012/09/25 by Stéphane Bugat

    Building your URLs in cubicweb


    In cubicweb, you often have to build url's that redirect the current view to a specific entity view or allow the execution of a given action. Moreover, you often want also to fallback to the previous view once the specific action or edition is done, or redirect also to another entity's specific view.

    To do so, cubicweb provides you with a set of powerful tools, however as there is often more than one way to do it, this blog entry is here to help you in choosing the preferred way.

    Tools at your disposal

    The universal URL builder: build_url()

    build_url is accessible in any context, so for instance in the rendering of a given entity view you can call self._cw.build_url to build you URLs easily, which is the most common case. In class methods (for instance, when declaring the rendering methods of an EntityTableView), you can access it through the context of instantiated appobject which are usually given as argument, e.g. entity._cw.build_url. For test purposes you can also call session.build_url in cubicweb shells.

    build_url basically take a first optional, the path, relative to the base url of the site, and arbitrary named arguments that will be encoded as url parameters. Unless you wish to direct to a custom controller, or to match an URL rewrite url, you don't have to specify the path.

    Extra parameters given to build_url will vary according to your needs, however most common arguments understood by default cubicweb views are the followings:

    • vid: the built view __regid__;
    • rql: the RQL query used to retreive data on which the view should be applied;
    • eid: the identifier of an entity, which you should use instead of rql when the view apply to a single entity (most often);
    • __message: an information message to display inside the view;
    • __linkto: in case of an entity creation url, will allow to set some specific relations between both entities;
    • __redirectpath: the URL of the entity of the redirection;
    • __redirectvid: the view id of the redirection.

    __redirectvid and __redirectpath are used to control redirection after posting a form and are more detailed in the cubicweb documentation, chapter related to the edition control (

    Exploring entities associated URLs

    Generally, an entity has two important methods that retrieve its absolute or relative urls:

    • entity.rest_path() will return something like <type>/<eid> where <type> corresponds to the entity type and <eid> the entity eid;
    • entity.absolute_url() will return the full url of the entity http://<baseurl>/<type>/<eid>. In case you want to access a specific view of the entity, just pass the vid='myviewid' argument. You can give arbitrary arguments to this method that will be encoded as url parameters.

    Getting a proper RQL

    Passing the rql to the build_url method requires to have a proper RQL expression. To do so, there is a convenience method, printable_rql(), that is accessible in rset resulting from RQL queries. This allows to apply a view to the same result set as the one currently process, simply using rql = self.cw_rset.printable_rql().

    Getting URLs from the current view

    There are several ways to get URL of the current view, the canonical one being to use self._cw.relative_path(includeparams=True) which will return the path of the current view relative to the base url of the site (otherwise use self._cw.url(), including parameters or not according to value given as includeparams).

    You can also retrieve values given to individual parameters using self._cw.form, eg:

    • self._cw.form.get('vid', '') will return only the view id;
    • self._cw.form.get('rql', '') will return only the RQL;
    • self._cw.form.get('__redirectvid', '') will return the redirection view if defined;
    • self._cw.form.get('__redirectpath', '') will return the redirection path if defined.

    How to redirect to non-entity view?

    This case often appears when you want to create a link to a startup view or a controller. It the first case, you simply build you URL like this:

    self._cw.build_url('view', vid='my_view_id')

    The latter case appears when you want to call a controller directly without having to define a form in your view. This can happen for instance when you want to create a URL that will set a relation between 2 objects and do not need any confirmation for that. The URL construction is done like this:

    self._cw.build_url('my_controller_id', arg1=value1, arg2=value2, ...)

    Any extra arguments passed to the build_url method will be available in the controller as key, values pairs of the self._cw.forms dictionary. This is especially useful when you want to define some kind of hidden attributes but there is not form to put them into.

    And, last but not least, a convenient way to get the root URL of the instance:


    Some concrete cases

    Get the URL of the outofcontext view of an entity:

    link = entity.absolute_url(vid='outofcontext')

    Create a link to a given controller then fall back to the current view:

    • In your entity view:
    self.w(u'<a href="%s">Click me</a>' % xml_escape(
                    arg1=value1, arg2=value2,
    • In your controller:
    def publish(self, rset):
         value1, value2 = self._cw.form['arg1'], self._cw.form['arg2']
         # do some stuff with value1 and value2 here...
         raise Redirect(self._cw.build_url(rql=self._cw.form['rql'],
             __message=_('you message')))

    Create a link to add a given entity and relate this entity to the current one with a relation 'child_of', then go back to the current entity's view:

    entity = self.cw_rset.get_entity(0,0)
    self.w(u'<a href="%s">Click me</a>' % xml_escape(
                    __linkto='child_of:%s:object' % entity.eid,
                    __redirectvid=self._cw.form.get('vid', ''))))

    Same example, but we suppose that we are in a multiple rset entity view, and we want to go back afterwards to this view:

    entity = self.cw_rset.get_entity(0,0)
    self.w(u'<a href="%s">Click me</a>' % xml_escape(
                    __linkto='child_of:%s:object' % entity.eid,
                    __redirectvid=self._cw.form.get('vid', ''))))

    Create links to all 'menuactions' in a view:

    actions = self._cw.vreg['actions'].possible_actions(self._cw, rset=self.cw_rset)
    action_links = [unicode(self.action_link(x)) for x in actions.get('menuactions', ())]
    self.w( u'  |  '.join(action_links))

  • How to create your own forms and controllers?

    2012/09/05 by Stéphane Bugat


    Sometimes you need to associate to a given view your own specific form and the associated controller. We will see in this blog entry how it can be done in cubicweb on a concrete case.

    The case

    Let's suppose you're working on a social network project where you have to develop friend-of-a-frient (foaf) relationships between persons. For that purpose, we use the cubicweb-person cube and create in our scheme relations between persons like X in_contact_with Y:

    class in_contact_with(RelationDefinition):
          subject = 'Person'
          object = 'Person'
          cardinality = '**'
          symmetric = True

    We will also assume that a given Person corresponds to a unique CWUser through the relation is_user.

    Although it is not evident, we would like that any connected person can chose to disconnect himself from another person at any time. For that, we will create a table view that will display the list of connected users, with a custom column giving the ability to "disconnect" with the person.

    Before disconnecting with this particular person, we would like also to have a confirmation form.

    How to proceed

    The following steps were defined to address the above issue:

    1. Define a "contact view" that will display the list of known contacts of the connected user ;
    2. In this contact view, allow the user to click on a specific contact so as to remove him ;
    3. Create a deletion confirmation view, that will contain:
      • A form holding the buttons for deletion confirmation or cancel;
      • A controller responsible for the actual deletion or the cancelling.

    The contact view

    Rendering a table view of connected persons

    To display the list of connected persons to the current person, but also to add custom columns that do not refer specifically to attributes of a given entity, the best choice is to use EntityTableView (see here for more information):

    class ContactView(EntityTableView):
        __regid__ = 'contacts_tableview'
        __select__ = is_instance('Person')
        columns = ['person', 'firstname', 'surname', 'email', 'phone', 'remove']
        layout_args = {'display_filter': 'top', 'add_view_actions': None}
        def cell_remove(w, entity):
            """link to the suppression of the relation between both contacts"""
            icon_url = entity._cw.data_url('img/user_delete.png')
            action_url = entity._cw.build_url(eid=entity.eid,
                    __redirectvid=entity._cw.form.get('__redirectvid', ''))
            w(u'<a href="%(actionurl)s" title="%(title)s">'
                    u'<img alt="%(title)s" src="%(url)s" /></a>'
                    % {'actionurl': xml_escape(action_url),
                       'title': _('remove from contacts'),
        column_renderers = {
                'person': MainEntityColRenderer(),
                'email': RelatedEntityColRenderer(
                    getrelated=lambda x:x.primary_email and x.primary_email[0] \
                            or None),
                'phone': RelatedEntityColRenderer(
                    getrelated=lambda and[0] or None),
                'remove': EntityTableColRenderer(

    A few explanations about the above view:

    • By default, the column attribute contains a list of displayable attributes of the entity. If one element of the list does not correspond to an attribute, which is the case for 'remove' here, it has to have rendering function defined in the dictionnary column_renderers.
    • However, when the column header refers to a related entity attribute, we can easily use the rendering function RelatedEntityColRenderer, as it is the case for the email and phone display.
    • As for concerns the 'remove' column, we render a clickable image in the cell_remove method. Here we have chosen an icon from famfamsilk that is putted in our data/ directory, but feel free to chose a predefined icon in the cubicweb shared data directory.

    The redirection URL associated to each image has to be a link to a specific action allowing the user to remove the selected person from its contacts. It is built using the self._cw.build_url() convenience function. The redirection view, 'suppress_contact_view', will be defined later on. The eid argument passed refers to the id of the contact person the user wants to remove.

    Calling the contact view

    The above view has to be called with a given rset which corresponds to the list of known contacts for the connected user. In our case, we have defined a StartupView for the contact management, in which in the call function we have added the following piece of code:

    person = self._cw.user.related('is_user', 'object').get_entity(0,0)
    rset = self._cw.execute(
            'Any X WHERE X is Person, X in_contact_with Y, '
            'Y eid %(eid)s', {'eid': person.eid})
    self.w(u'<h3>' + _('Number of contacts in my network:'))
    self.w(unicode(len(rset)) + u'</h3>')
    if len(rset) != 0:
        self.wview('contacts_tableview', rset)

    The Person corresponding to the connected user is retrieved thanks to the use of the related method and the is_user relation. The contact table view is displayed inside the parent StartupView.

    Creation of the deletion confirmation view

    Defining the confirmation view for contact deletion

    The corresponding view is a simple View class instance, that will display a confirmation message and the related buttons. It could be defined as follows:

    class SuppressContactView(View):
        __regid__ = 'suppress_contact_view'
        def cell_call(self, row, col):
            entity = self.cw_rset.get_entity(row, col)
            msg = self._cw._('Are you sure you want to remove %(name)s from your contacts?')
            self.w(u'<p>' + msg % {'name': entity.dc_long_title()} + u'</p>')
            form = self._cw.vreg['forms'].select('suppress_contact_form',
                    self._cw, rset=self.cw_rset)
            form.add_hidden(u'eidto', entity.eid)
            form.add_hidden(u'eidfrom', self._cw.user.related('is_user',

    Inside the cell_call() method of this view, we will have to render a form which aims at displaying both buttons (confirm deletion or cancel deletion). This form will be described later on.

    The Person contact to remove is retrieved easily thanks to cw_rset. The Person corresponding to the connected user is here also retrieved thanks to the is_user relation. To make both of them available in the form, we add them at the instanciation of the form using the convenience function add_hidden(key,val).

    Defining the deletion form

    The deletion form as mentioned previously is only here to hold both buttons for the deletion confirmation or the cancelling. Both buttons are declared thanks to the form_buttons attribute of the form, which is instanciated from forms.FieldsForm:

    class SuppressContactForm(forms.FieldsForm):
        __regid__ = 'suppress_contact_form'
        domid = 'delete_contact_form'
        form_renderer_id = 'base'
        def action(self):
            return self._cw.build_url('suppress_contact_controller')
        form_buttons = [
                fw.Button(stdmsgs.BUTTON_DELETE, cwaction='delete'),
                fw.Button(stdmsgs.BUTTON_CANCEL, cwaction='cancel')]

    Specifying a given domid will ensure that your form will have a specific DOM identifier,the controller defined in the action method will be called without any ambiguity. The form_renderer_id is precised here so as to avoid additional display of informations which don't make sense here.

    Defining the controller

    The custom controller is instanciated from the Controller class in cubicweb.web.controller. The declaration of the controller should have the same domid than the calling form, as mentioned previously. The related actions are described in the publish() method of the controller:

    class SuppressContactController(Controller):
        __regid__ = 'suppress_contact_controller'
        domid = 'delete_contact_form'
        def publish(self, rset=None):
            if '__action_cancel' in self._cw.form.keys():
                msg = self._cw._('Deletion canceled')
                raise Redirect(self._cw.build_url(
            elif '__action_delete' in self._cw.form.keys():
                xid = self._cw.form['eidfrom']
                dead_contact = self._cw.entity_from_eid(xid)
                yid = self._cw.form['eidto']
                        'DELETE X in_contact_with Y'
                        '  WHERE X eid %(xid)s, Y eid %(yid)s',
                        {'xid': xid, 'yid': yid})
                msg = self._cw._('%s removed from your contacts') %\
                raise Redirect(self._cw.build_url(

    Retrieving of the user action is performed by testing if the '__action_<action>', where <action> refers to the cwaction in the button declaration, is present in the form keys. In the case of a cancelling, we simply redirect to the contact management view with a message specifying that the deletion has been cancelled. In the case of a deletion confirmation, both Person id's for the connected user and for the contact to remove are retrieved from the form hidden arguments.

    The deletion is performed using an RQL request on the relation in_contact_with. We also redirect the view to the contact management view, this time with another message confirming the deletion of the contact link.