1. Updating and Deleting Form Records:
Many of you should be wondering about how the form data provided through this form can be edited, updated or even deleted? Well, this is simple. First, let’s recall the form_a function that we have created in the default.py controller:
def form_a(): form = SQLFORM(db.registration) if form.process().accepted: response.flash = ‘You have successfully submitted the form’ elif form.errors: response.flash = 'Please check your form for errors' else: response.flash = 'This form cannot be left empty!' return dict(form=form)
This is a very meanly written controller function (I admit it), which only supports the insertion of input data. In order to make it cover the record update/delete features, we can transform it to something like this:
def form_a(): form = SQLFORM(db.registration, request.args(0), deletable=True, upload=URL(r=request, f='download')) if form.accepts(request.vars, session): if not form.record: response.flash = 'Your input data has been submitted.' else: if form.vars.delete_this_record: session.flash = 'User record successfully deleted.' else: session.flash = 'User record successfully updated.' redirect(URL(r=request, f='form_a’)) records = db().select(db.registration.ALL) return dict(form=form, records=records)
Well, we have added a ‘bit’ something in the above function, so allow me to explain it all. Under the SQLFORM function, we have added three new features namely ‘deletable’, ‘request.args(0)’, and ‘upload’. The ‘deletable’ feature specifies if the form records can be deleted and edited on-demand, the ‘request.arg()’ feature fetches the record associated with the specified user, while ‘upload’ constructs the url for the (image) file upload through the web form. Moreover, we have added some conditional methods specified by the classical ‘if-else’ conditions, which are simply telling the controller about what action is to be performed when a specific operation is carried out on user data. Rest of the content is simply reflective, so I leave it on you to play with the conditions.
Check your new Web2Py form and insert some sample registration record by visiting:
Once the new record entry is submitted, just add ‘/[number of the record]’ at the end of the url to edit the submitted form record:
This page provides you a complete way to edit the submitted form values for the record number ‘2’ (I assumed to be 2 for exemplifying the process, and it can be any value based on the number of records you have submitted to the database). However, this isn’t a good way of managing user submitted records.
2. Managing the Submitted Form Records:
Web2Py’s SQLFORM function has a serious feature named ‘grid’. This is sort of a pre-built method that provides a feature of viewing all the records submitted on the website from a particular form to a specific table (in our case, the ‘registration’ table). To utilize it, create a new function in the default.py controller and name it as records:
def records(): record = SQLFORM.grid(db.registration, user_signature=False) return locals()
Now browse to http://127.0.0.1:8000/forms/default/records to see the list of all the records submitted to the ‘registration’ table in the database, using form_a. On this page, you can view, edit, update and delete any of the record entry as well its associated data fields. This is such an elegant approach of Web2Py, which seriously saves at least tens of hours of code development and gives out the true essence of a web framework.
Probably you have noticed something in the above code: there is no user authentication layer, and the form records are open to anyone for manipulation. To add this feature, simply set the ‘user_signature’ field as ‘True’, and (additionally) add a single line of code right at the top of this function:
@auth.requires_login() def records(): record = SQLFORM.grid(db.registration, user_signature=True) return locals()
In the function above, @auth.requires_login() calls an upper-level login function, which requires any user to verify profile credentials before viewing the ‘records’ page, while user_signature=True sets the inner-level protection, which means that a user may be able to view the ‘records’ page only, but will not be able to edit or delete the particular records. It is up to you to decide about how many layers of protection should be there.
Well, this is it for this part. Stay tuned for learning some more interesting ideas, tips and tricks in the next tutorial of this series on Python’s Web2Py.