View of /trunk/webwork2/doc/devel/URL-notes

    1 THE CURRENT STRATEGY
    2 
    3 The URL strategy we've been basically using is to put the nouns in the path info and the verbs in the query string. The heirarchy of the path info mirrors the heirarchy of objects in the system. It works like this in the Problem.pm content generator (I think):
    4 
    5 	/webwork/$courseID/$setID/$problemID?submitAnswer=Submit+Answer
    6 
    7 WeBWorK contains courses, courses contain sets, sets contain problems. This is reflected in the path info. The presence of a parameter named submitAnswer in the query string causes Problem.pm to record the answers given later in the query string. The set and problem to which the answers are recorded is given in the path info. Each content generator has a default action that is performed if no verbs are given in the query string. These default actions are non-destructive, i.e. "view" or "list".
    8 
    9 ADVANTAGES
   10 
   11 This scheme has the advantage of allowing a user (usually a professor) to easily reference a "location" within the system, without needing to worry about the relativly complicated syntax of the query string. For example, a professor could, after making a change to a problem, instruct students via email to "visit http://courses.webwork.rochester.edu/mth161/4/7/ to view the updated problem". This is certainly more manageable than a scheme in which the verb is in the path info and the nouns are in the query string (as in "http://courses.webwork.edu/viewProblem?course=mth161&set=4&problem=7").
   12 
   13 It also allows us to, as we strive to reduce the amount of state that is passed through each request, pare the URL down so that very little query string remains. For example, the session key could be kept in a cookie, and the rest of the session data could be kept in the key table of the database. The only thing that would be left in the query string would be the verb and (I suppose) various "adverbs" and "adjectives".
   14 
   15 PROBLEMS
   16 
   17 Currently the dispatch() function uses only the path info to decide which content generator to invoke. This means that unless we wish to have the problem viewer and the problem editor be implemented in the same content generator, it would be impossible to have these two URIs:
   18 
   19 	/webwork/$courseID/$setID/$problemID/?action=view
   20 	/webwork/$courseID/$setID/$problemID/?action=edit
   21 
   22 This, I think, can be solved by allowing the dispatch() function to inspect the query string in a limited fashion. If it were allowed to check for an "action" parameter, and a standard set of actions were defined, the combination of an action (in the query string) and a type of object (in the path info) could be used to select a content generator.
   23 
   24 A table would be needed to noun/action pairs to content generators and vice versa. For example:
   25 
   26 	Problem + view <=> WeBWorK::ContentGenerator::Problem
   27 	Problem + edit <=> WeBWorK::ContentGenerator::Instructor::PGProblemEditor
   28 
   29 However, there are some tricky implementation problems with this approach. The value of a parameter triggered by a submit button (generated with the INPUT element) is the same as the text that is displayed on the button. This puts the desire for good UI at odds with having easily manageable action identifiers. We'd like to have a button named "Download Hardcopy for Selected Sets", but have the action identifier be "makeHardcopy" or something. The BUTTON element promises to solve this, but browser support is very broken for both the presentation and behavior of this element.
   30 
   31 Another problem with this scheme is that sometimes the nouns needed are not known when the form action is decided at page generation time. For example, the URI for creating a new set might be something like:
   32 
   33 	/webwork/$courseID/instructor/sets/$setID?action=create
   34 
   35 The set name ($setID) would have be supplied by a text field on the form, and therefore would not be known at the time that the form was generated. One solution to this would be to name the "slots" in the path info, and have the dispatcher substitute in values from the query string before handing the request off to the content generator. A redirect to the URI with the values substituted in could fix the user experience somewhat. For example, the dispatcher could convert the URI:
   36 
   37 	/webwork/mth161/instructor/sets/?action=create&setID=newIntegrals
   38 
   39 to:
   40 
   41 	/webwork/mth161/instructor/sets/newIntegrals/?action=create
   42 
   43 In the example, the value of the parameter named "setID" was placed in the "setID" slot in the path info, and the parameter was deleted.
   44 
   45 --------------------------------------------------------------------------------
   46 
   47 (+) = list
   48 
   49 THE CURRENT URI HEIRARCHY
   50 
   51 $webworkURIRoot
   52 	$courseID
   53 		test
   54 		$setID
   55 			$problemID
   56 		hardcopy
   57 			$setID
   58 		login
   59 		logout
   60 		options
   61 		feedback
   62 		instructor
   63 			[some crap]
   64 
   65 PROPOSED URI HEIRARCHY
   66 
   67 $webworkURIRoot
   68 	$courseID -- lists sets
   69 		test -- prints debugging information
   70 		$setID -- lists problems in a set
   71 			$problemID -- displays problem (interactive mode)
   72 		hardcopy -- prompts user for which sets/users to generate
   73 			$setID (+) -- generates hardcopy for specified sets
   74 		login -- prompts for login information
   75 		logout -- deletes session information, displays logout message
   76 		options -- allows user to change email address and password
   77 		feedback -- allows user to send feedback to professor
   78 		instructor -- gives user a choice between user list and set list
   79 			sets -- lists/edits (global) sets
   80 				$setID -- displays/edits (global) set data
   81 					problems -- lists (global) problems for a set
   82 						$problemID -- displays/edits (global) set data
   83 					users -- lists/edits assigned users
   84 						$userID (+) -- displays/edits user-specific set data
   85 							problems -- lists/edits assigned problems
   86 								$problemID -- displays/edits user-specific problem data
   87 			users -- lists/edits users
   88 				$userID -- displays/edits user data
   89 					sets -- lists/edits assigned sets
   90 						$setID -- displays/edits user-specific set data
   91 							problems -- lists/edits assigned problems
   92 								$problemID -- displays/edits user-specific problem data