wuttafarm.web.views.farmos.master

Base class for farmOS master views

class wuttafarm.web.views.farmos.master.FarmOSMasterView(request, context=None)

Base class for farmOS master views

get_template_context(context)

Collect the “complete” context for rendering the current template. This is called from render_to_response().

The default logic should be suitable for many cases but subclass is expected to override if needed.

This one method is used for index, create, view, edit, etc. The actual template file is not known at this point, so cannot be inspected. But you can inspect listing, editing (etc.) instead, or even inspect e.g. the request matched_route for the “best” clue as to which template is involved.

This adds several things to the context, but the caller-provided context values are always preferred. In all cases these are added if not already present:

• master - reference to the current master class instance

• route_prefix - value from get_route_prefix()

• index_title - value from get_index_title()

• index_url - value from get_index_url()

• model_title - value from get_model_title()

• model_title_plural - value from get_model_title_plural()

• config_title - value from get_config_title()

If the context already contains an instance value, several more things may be added:

• instance_title - value from get_instance_title()

• url_view_instance - URL to view the instance

• instance_editable - whether to show the Edit button

• url_edit_instance - URL to edit the instance

• instance_deletable - whether to show the Delete button

• url_delete_instance - URL to delete the instance

Note

The templates generally expect an “instance” to be the “current thing” e.g. in a CRUD scenario. This is of course a model_class instance most of the time, but it can also be a row_model_class instance.

This can be confusing, hence this note… I’m not sure if/how the situation can be improved, since sometimes we need to think of a row as a separate concept, but some CRUD logic benefits from being more “agnostic” and not really caring if it has a “parent” or “child” object to deal with.

Parameters:

context – Original context dict provided by view callable.

Returns:

Final context dict for the template.

class wuttafarm.web.views.farmos.master.TaxonomyMasterView(request, context=None)

Base class for farmOS “taxonomy term” views

configure_form(form)

Configure the given model form, as needed.

This is called by make_model_form() - for multiple CRUD views (create, view, edit, delete, possibly others).

The default logic here does just one thing: when “editing” (i.e. in edit() view) then all fields which are part of the model_key will be marked via set_readonly() so the user cannot change primary key values for a record.

Subclass may override as needed. The form param will already be “complete” and ready to use as-is, but this method can further modify it based on request details etc.

configure_grid(grid)

Configure the grid for the index() view.

This is called by make_model_grid().

There is minimal default logic here; subclass should override as needed. The grid param will already be “complete” and ready to use as-is, but this method can further modify it based on request details etc.

delete_instance(term)

Delete the given model instance.

As of yet there is no default logic for this method; it will raise NotImplementedError. Subclass should override if needed.

This method is called by save_delete_form().

get_grid_data(columns=None, session=None)

Returns the grid data for the index() view.

This is called by make_model_grid(); in the resulting Grid instance, this becomes data.

Default logic will call get_query() and if successful, return the list from query.all(). Otherwise returns an empty list. Subclass should override as needed.

get_instance()

This should return the appropriate model instance, based on the matchdict of model keys.

Normally this is called with no arguments, in which case the pyramid:pyramid.request.Request.matchdict is used, and will return the “current” model instance based on the request (route/params).

If a matchdict is provided then that is used instead, to obtain the model keys. In the simple/common example of a “native” model in WuttaWeb, this would look like:

keys = {'uuid': '38905440630d11ef9228743af49773a4'}
obj = self.get_instance(matchdict=keys)

Although some models may have different, possibly composite key names to use instead. The specific keys this logic is expecting are the same as returned by get_model_key().

If this method is unable to locate the instance, it should raise a 404 error, i.e. notfound().

Default implementation of this method should work okay for views which define a model_class. For other views however it will raise NotImplementedError, so subclass may need to define.

Warning

If you are defining this method for a subclass, please note this point regarding the 404 “not found” logic.

It is not enough to simply return this 404 response, you must explicitly raise the error. For instance:

def get_instance(self, **kwargs):

    # ..try to locate instance..
    obj = self.locate_instance_somehow()

    if not obj:

        # NB. THIS MAY NOT WORK AS EXPECTED
        #return self.notfound()

        # nb. should always do this in get_instance()
        raise self.notfound()

This lets calling code not have to worry about whether or not this method might return None. It can safely assume it will get back a model instance, or else a 404 will kick in and control flow goes elsewhere.

get_instance_title(term)

Return the human-friendly “title” for the instance, to be used in the page title when viewing etc.

Default logic returns the value from str(instance); subclass may override if needed.

get_xref_buttons(term)

Should return a list of “cross-reference” buttons to be shown when viewing the given object.

Default logic always returns empty list; subclass can override as needed.

If applicable, this method should do its own permission checks and only include the buttons current user should be allowed to see/use.

See also make_button() - example:

def get_xref_buttons(self, product):
    buttons = []
    if self.request.has_perm('external_products.view'):
        url = self.request.route_url('external_products.view',
                                     id=product.external_id)
        buttons.append(self.make_button("View External", url=url))
    return buttons

persist(term, session=None)

If applicable, this method should persist (“save”) the given object’s data (e.g. to DB), creating or updating it as needed.

This is part of the “submit form” workflow; obj should be a model instance which already reflects the validated form data.

Note that there is no default logic here, subclass must override if needed.

Parameters:

obj – Model instance object as produced by objectify().

See also save_create_form() and save_edit_form(), which call this method.