Infrastructure Perspective: Display Classes

Introduction

D
isplay classes are descendents of the 'Display' class. They take as input a request object (as part of the contructor) and ouptut a cs_page object, by modifying the page object passed in as the argument of the make_page method. They are helped in their endevour by Controls and Query objects. Always keep the Working definitions of these objects in mind.

Constructing and Invoking a Display Object

The FileCopy Mixin

D
efunct. See StaticString Mixin.

StaticString Mixin

T
his mixin implements the GetString method:

GetString(key, display=None, extra={}, title_fn=None)

If you want to use this as a control see StaticStringControl.

GetPSString(key,display,extra,title_fn) gets the static string keyed under "key" and then does a percent-substitution on the resulting string using display and extra. If title_fn is not None, then GetString searches the static string for a substring enclosed in <H1>...</H1> and calls the function title_fn, passing the substring as argument. Typically it is used to set the page title. Finally, if display is None, then it defaults to self, since the most common use is when it is used as a Mixin for the Display class.

If you want to create a page, which displays a bunch of staticstrings, then look up StaticStringDisplay.

The Arguments Mixin

T
he arguments class provides functions to parse arguments received (through the URL or through POST data aka forms) into a dictionary. All data received through POST data is already in the form of a dictionary, while those received through the URL (display.req.url.arguments) is a list of strings. Do you know which pages receive arguments in which way when in what mode? There are two main functions in this class: parse_arguments and process_search_arguments, further explained later.

Suggested use in display class: Define a function called process_arguments() in your display class, and have make_page call it right at the beginning. The body of your process_arguments should be something like this:


    def process_arguments(self):
        self.args = self.parse_arguments(...)
        .... any other post processing ...

If your page is being called from a search page, you might want to use process_search_arguments instead of a call to parse_arguments. The post processing can be very useful at times. For example the courses page, expect five arguments in a specific order with default values for each. However if only one argument is given it is interpreted as a combination of some of the arguments. So in the courses page, the post processing takes care of the one argument case and unpacks the single argument into its constituents.

parse_arguments

It takes the following arguments:

argnames:
a list of {string(NAME) or pair(NAME,DEFAULT)} where NAME is the name of the argument eg. 'year', and DEFAULT the default value if not given eg. 2001

noargs=[]:
the default list of arguments, if no arguments are given. This is not necessarily the list of DEFAULT arguments.

name_value_format=1:
The format of URL arguments can be  pairs eg. 'year/2001'

value_format=1:
The format of URL arguments can be  just the values ie. '2001'

form_data=1:
Read the arguments received through POST data also.

space2plus=None:
The spaces inside any of the arguments have been converted to +

IntCheck=[]:
A subset of argnames. Check and confirm that these arguments are integers. Otherwise raise a Type Check error.

For example a call like parse_arguments(
 argnames=["subject","cnum",("year",2001),"quarter"],  noargs=["",0,2001,"SUM"],  form_data=0,  IntCheck=["cnum","year"] )

will accept arguments like

'CS/100/200' (this is in value format) and return {'subject':'CS','cnum':100,'year':200,'quarter':None}

'year/200/cnum/100' (this is in name-value format) and return {'subject':None,'cnum':100,'year':200,'quarter':None)

If both formats are possible, then name-value format is assumed iff the number of arguments are even and the first argument is one of the name.

process_search_arguments

Arguments: argnames,noargs=[],name_value_fmt=1, value_fmt=1, form_data=1,space2plus=None,IntCheck=[]

For meaning see parse_arguments above.

This processes all the arguments using parse_arguments. If there was no form_data then it returns the dictionary returned by parse_arguments. If some form_data exists then it bounces the request to itself, with all the arguments passed through the URL using name-value format. Use this instead of parse_arguments in scripts which can be called as a result of a form submission. This would then result in a URL which the user can bookmark to display the search results, instead of filling up the form again. Another advantage of this is that pressing the BACK button on the browser will not give the "THIS PAGE WAS THE RESULT OF A POST, Press OK to resubmit the post" message any more.

The Modal Mixin

T
his mixin handles the behind the scences implementation of modes. The most common set of modes used are error, display, edit. One of the pages in the courses subsite uses some other esoteric modes like retire, unretire, renumber, verify....

The modes are implemented in terms of cookies. This mixin is responsible for sending the right cookie to the client's browser, getting the cookie to see if the client has the right permissions. In order for this to work, the display class must define its own permit_mode(self,mode) function which returns None if the client is not allowed to be in the mode mode for this page. Usually, you will need to use the perms.may function of the perms module.

Database Displays

S
ee the Infrastructure Perspective: Database Displays path.