Requests, Urls and Variables
A PAD url names the page in the query string:
| url | page |
|---|---|
/myapp/
|
index.pad
|
/myapp/?about
|
about.pad
|
/myapp/?admin/users
|
admin/users.pad
|
/myapp/?about&who=world
|
about.pad, with a parameter
|
Parameters become variables
Everything after the page name arrives as plain variables: &who=world is $who in the page's PHP and {$who} in its template. The optional pipe reads one that may not be there:
|
PHP |
HTML fragments/requests_1.pad |
Result |
|---|---|---|
|
Hello world! |
Building urls: the {?var} form
The third variable spelling writes a variable as a url fragment - {?city} renders &city=value, encoded and ready to append to a link:
|
PHP |
HTML fragments/requests_2.pad |
Result |
|---|---|---|
|
As a url fragment: &city=Den+Haag |
Forms
A form posts back to the page it is on - no action needed - and its fields arrive as variables like any other - the note typed here comes back as $note:
|
PHP |
HTML fragments/requests_3.pad |
Result |
|---|---|---|
|
The note said: |
Two habits keep this safe: pass what a visitor typed through padMakeSafe ( $input, $len ) before using it, and give variables set in _inits.php names a form field would never use - a form field named the same would be overwritten.
Carrying more than a url can
What is too much, or too private, for a query string stays on the server: a name listed in $padSessionVars in _config/config.php is kept in the session and is there again on the visitor's next page, and the request never fills it.