You don't need to stop the flow of the program to wait for user input as would be the case in other programming languages. When the page is displayed to the user all processing has already stopped. All user input sent to the server will be processed by a completely new page. (This is what all the Ajax buzz is about: how can you send a new request to the server without asking for a completely new page, but let us leave that aside to keep things simple)
This is exactly what made it difficult for me to grasp PHP programming. I believe programmers refer to this as maintaining state (Look for it on Google especially in combination with
PHP as a search term)
As a mere mortal I'd like to call it: How does one Moodle page knows which selections were made on the previous Moodle page?
Simple answer: they use parameters in the url or they send parameters through forms. (There is another way: sessions, but we will leave those aside for the moment.)
Using url parameters is the easiest way:
Write a lot of links for the different choices:
<a href="./format.php?linebreaks=false&numberedsubq=true">
No linebreaks, Numbered subquestions</a>
<a href="./format.php?linebreaks=true&numberedsubq=true">
Linebreaks, Numbered subquestions</a>
etc...
Alas, this is ugly! So we will go for the harder way...
Passing parameters through forms. The best way to understand it, is to look at existing forms. You will quickly notice 2 things:
Moodle forms contain a lot of hidden fields. That's precisely to pass around information from one page to the other: it's likely that the question category would in your code be passed using a hidden field.
Moodle forms come in pairs: edit.php is accompanied by edit.html / post.php by post.html / etc...
The html file contains the form and the php file has two parts: the first part processes the information that was submitted. (Look at the data_submitted() function). The second part is used to setup some defaults before displaying the html file with the form.
I hope carefully studying some examples of these *.html / *.php pairs will make it clearer.
Just one warning. Now that you know how Moodle passes around information from page to page, you'll understand that it is very easy for a user to enter other information (Just add a new parameter to the url or use the Firefox Web Developer Toolbar to change the value of a hidden field). That's why the receiving page should never trust information entered by the user. (eg in your case you might add a check whether the user is really allowed to export that particular question category). This information is often neglected in PHP tutorials or books. Some of the examples in those books or on the web are even dangerous to use on a real server connected to the internet.
Some other things to pay attention at when you grasp a PHP book or tutorial:
You can skip the part about MySQL database connections. Moodle's database functions are way easier to use.
Do read about $_GET
(the PHP way of passing around values through urls) and $_POST
(passing around values through forms) work, but afterwards you can use the simpler Moodle functions for those: data_submitted()
and optional_param()
and required_param()
Hope this saves you some time. I know I spent quite a bit of time trying to grasp this, coming from a Commodore 64 Basic background, where one would simply write
3060 INPUT "Numbered subquestions?", NUM
3070 IF NUM = "Y" THEN GOTO 3120
...