Create the Master View (/vehicles/)

Exposing a table’s data for CRUD operations is done via a “master” view. This is a Python class which inherits from MasterView, giving it a fair bit of logic out of the box.

The master view declares which CRUD operations it supports, and potentially many other things we won’t get into here.

New Master View Wizard

When you’re viewing an App Table record, e.g. for a table you just created, you should see a button to make a new master view. (Again, typically requires you to “become root” for access.)

Or if you go to App Info, then click Master Views, you should see a button to start the wizard.

Either way, this is similar to the new table wizard. We’ll explain more below but the high level is:

  • collect info

  • generate python module for view class

  • suggest menu, permission changes

Choose Model

The first step is choosing a “model” which the master view will represent. Typically this is an app table, but can really be any tabular data set. We’re sticking to the app table option here.

We want to use the Vehicle model we created in the previous section. It should already be selected, but if not you can manually do so. Then click to advance the wizard.

Enter Details

Ugh, more naming nonsense! By now some patterns hopefully start to emerge and it doesn’t all need to be explained.

The various “prefixes” are used for the view’s route/url configuration etc. You can read more about them in Config Prefixes.

CRUD support can be declared by (un)checking the relevant boxes.

You can also choose which columns show for the grid view, and which fields show for the form views (used for create, view, edit, delete). Once your view class exists, you can always edit the code later to refine the visible fields etc.

For our tutorial example, we will not change anything on this page, and just stick with the provided defaults. When ready, click the button to advance the wizard.

Write View

This asks where on disk the new Python module should be created.

It should auto-suggest the location specific to your project. Change the filename as needed.

Click the button to write a new file when ready.

Confirm Route

We should now have view code to look at. As with the table model, this is a good time to tweak it a bit if needed. But that can also be done later, the important thing here is just to get the basics wired up.

The app will not “know” about the new view until it’s explicitly added to the Pyramid config.

Once you’re happy with the view class definition, add a config.include() statement in the appropriate place. Relevant file paths and example statement should be on screen for reference.

Technically the running app may need a restart at this point, to reload all modules. But if you’re running the web app with -r in local dev, you should not need to manually restart.

The ultimate test is whether the running app is “aware” of the new view class; you can click “Check for Route” to confirm that.

Add to Menu

This step is optional, and depends on how you want to expose the master view to users. But typically, adding it to the top menu makes sense.

Relevant file paths and example code should be on screen for reference.

For sake of tutorial we’ll just assume you added a Vehicles menu entry “somewhere” as it suggests. Doesn’t really matter where you put it.

There is nothing to “confirm” here, the wizard just assumes you know what you’re doing.

Grant Access

Your view is fully functional at this point, but nobody has permission to see it yet. (Not even you, unless you’re being root.)

So as a convenience, you can choose which roles get access for each of the CRUD operations. Be sure to give access to your own role(s) to avoid surprises when you stop being root.

When you click “Apply these permissions” it will do just that, updating roles in the app database.

Commit Code

This is just an “outro” page with a reminder to commit all that code you just generated.

From here the last button will take you to see your new index view, where you can finally see the Vehicles table data! Of course that’s still empty…

Browsing the View(s)

You may already be there by now, but based on our example you could just enter /vehicles/ for the URL path in your browser address bar. Or access it via the top app menu. This gives you the “index” for the master view, aka. the table/grid/list view.

If you gave yourself access, and the view supports it, you should see a Create New button which lets you start adding data. Once records exist you can view/edit/delete any of them as expected.

Note that our Vehicles data is very simple, so we can expect smooth sailing here. But some (types of) fields can require further customization to get the behavior you need. In fact some (notably, foreign key reference fields) have downright poor behavior out of the box and really need tweaked to be usable.

We’ll get into more of that with the next table. For the vehicles example, we won’t even bother configuring the view any further, at least for now.

Also worth noting, in our example we enabled version history for the vehicle table and all columns. Therefore when viewing a vehicle record, we see a View History button to access that.

But that’s really it for the Vehicles table + view, it’s up and running!