(2006). "Handling Forms in PHP." Retrieved 6th August 2008, from http://phpsense.com/php/php-form-handling.html.
(2008). "3.6.6. Using Foreign Keys." Retrieved 10th August 2008, from http://dev.mysql.com/doc/refman/5.0/en/example-foreign-keys.html.
(2008). "B.1.7.2. How to Change the Order of Columns in a Table." Retrieved 10th August 2008, from http://dev.mysql.com/doc/refman/5.1/en/change-column-order.html.
Burns, J. (N.D.). "Checkboxes: Only Two." Retrieved 5th August 2008, from http://www.htmlgoodies.com/tutorials/forms/article.php/3479181.
Castro, E. (2007). Forms. HTML, XHTML & CSS, Peachpit Press: pp. 253-280.
Castro, E. (2007). Triggering a Script. HTML, XHTML & CSS, Peachpit Press: pp. 314-315.
Coggeshell, J. (2001). "Embedding PHP in HTML." Retrieved 29th August 2008, from http://www.onlamp.com/pub/a/php/2001/05/03/php_foundations.html.
H.P. (2007). "PHP MySQL." Retrieved 28th August 2008, from http://phpnmysql.blogspot.com/2007/04/php-beginners-using-html-form-elements.html.
Kiko08 (2006). limit checkbox select. Nico, Programming Talk.
Maurer, T. (2008). Personal Conversation. P. Denley. Sydney.
Maurer, T. (2008). Yahoo Conversation. P. Martin, Yahoo.
scotchegg78 (2008). limit checkboxes in a form - boxes all differnent names mjdmato, php freaks.
uk, J. (2002). "Creating a Login Script with PHP 4, Part II." Retrieved 29th August 2008, from http://evolt.org/creating_a_login_script_with_php4_part_2.
Ullman, L. (2005). PHP & MySQL For Dynamic Web Sites, Peachpit Press.
Ullman, L. (2005). Example - Content Management. PHP & MYSQL For Dynamic Web Sites, Peachpit Press.
Ullman, L. (2005). Example - E-Commerce. PHP & MYSQL For Dynamic Web Sites, Peachpit Press: pp.586-598.
Ullman, L. (2005). Error Handling and Debugging. PHP & MYSQL for Dynamic Websites, Peachpit Press: pp. 211-234.
Ullman, L. (2005). Web Application Security. PHP & MYSQL for Dynamic Web Sites, Peachpit Press: pp. 384-391.
Valade, J. (2008). Building and Processing Dynamic Forms. PHP & MySQL Web Development, Wiley Publishing Inc.: pp. 470-510.
Saturday, August 30, 2008
Final Adjustments
Well, I am glad I took the time to talk with Phil last night. He was able to walk me through several things within the site that were causing it to not function properly.
1. Errorr message positioning: We sorted out the issue with the error messages being hidden behind the header image. It was just a matter of coming up with a $errmsg flag and then adding a div id to position them further down the page.
2. We personalised the welcome page with the username after login. This was just a matter of adding the user_name field to the $query = SELECT on line 35 of the login.php page (and then adding the user_name as a session identifier on line 47 below) and then identifying the user_name session on line 15 of the index.php page. **This may send the session start option out when working with the change_password.php file. Will look into that.
3. The hardest part of all was trying to change the 'submit recipe' form after the recipe has been submitted. It seems to be returning with all fields still filled in even after the recipe is submitted. It took a lot of searching on the net for a solution and then lots of trial and error before we settled on the option of $results, $errmsg, and $success. These are set up as flags on the submit.php page so that the $errmsg picks up any errors when the form is filled out, the $results processes the messages for the results and the $success determines whether the form has successfully completed the validation and processing of information. Once $success registers that it has been successful - 'yes' - then it destroys the form and displays the page with just the $result message and a link back to a new form if the user wants to submit another recipe. Sounds complicated, but works well (Coggeshell, 2001).
4. Another minor issue was that the year and category drop down menu on the 'submit recipe' page didn't have any blank options which meant that the user could skip picking a category and year without it being picked up by an error message. This was very simple. I just added another option value to the top of both menu's which read 'Select'.
5. Also got the individual desserts.php, mains.php etc pages linked to a recipe year by adjusting the $query = SELECT function to include recipe_year.recipe_year in its choice so that I could then identify the related recipe year for each recipe. I also did this with the new 'recipe.php' page and got that working.
So, that is it. There are still some things that I would like to do on the site, but I feel that they are just icing on the cake and can be addressed down the track if I want to complete this project for personal reasons. They are:
1. Complete the design and style of the site
2. Include the 'username' with each result from a recipe search.
3. Improve the format of search results by including linked Recipe Names and a brief description. The link will then expand the recipe results to include all the details of the recipe. This will mean that I may have to add another field to the recipe table - 'recipe_description'.
4. User option to ammend any submitted recipes.
5. Email alert when new recipes have been submitted.
The list could go on. But that is it for now.
1. Errorr message positioning: We sorted out the issue with the error messages being hidden behind the header image. It was just a matter of coming up with a $errmsg flag and then adding a div id to position them further down the page.
2. We personalised the welcome page with the username after login. This was just a matter of adding the user_name field to the $query = SELECT on line 35 of the login.php page (and then adding the user_name as a session identifier on line 47 below) and then identifying the user_name session on line 15 of the index.php page. **This may send the session start option out when working with the change_password.php file. Will look into that.
3. The hardest part of all was trying to change the 'submit recipe' form after the recipe has been submitted. It seems to be returning with all fields still filled in even after the recipe is submitted. It took a lot of searching on the net for a solution and then lots of trial and error before we settled on the option of $results, $errmsg, and $success. These are set up as flags on the submit.php page so that the $errmsg picks up any errors when the form is filled out, the $results processes the messages for the results and the $success determines whether the form has successfully completed the validation and processing of information. Once $success registers that it has been successful - 'yes' - then it destroys the form and displays the page with just the $result message and a link back to a new form if the user wants to submit another recipe. Sounds complicated, but works well (Coggeshell, 2001).
4. Another minor issue was that the year and category drop down menu on the 'submit recipe' page didn't have any blank options which meant that the user could skip picking a category and year without it being picked up by an error message. This was very simple. I just added another option value to the top of both menu's which read 'Select'.
5. Also got the individual desserts.php, mains.php etc pages linked to a recipe year by adjusting the $query = SELECT function to include recipe_year.recipe_year in its choice so that I could then identify the related recipe year for each recipe. I also did this with the new 'recipe.php' page and got that working.
So, that is it. There are still some things that I would like to do on the site, but I feel that they are just icing on the cake and can be addressed down the track if I want to complete this project for personal reasons. They are:
1. Complete the design and style of the site
2. Include the 'username' with each result from a recipe search.
3. Improve the format of search results by including linked Recipe Names and a brief description. The link will then expand the recipe results to include all the details of the recipe. This will mean that I may have to add another field to the recipe table - 'recipe_description'.
4. User option to ammend any submitted recipes.
5. Email alert when new recipes have been submitted.
The list could go on. But that is it for now.
Thursday, August 28, 2008
Some problems arising from the submit recipe form
Now that I have the submit a recipe form working, there have been some other problems arise as a result.
You know this is a lot like life! You spend all your time working on something that is just not right, thinking that if I can just get through this then everything will be perfect. But once you solve one problem a million others pop up to replace it.
I have now discovered that the error report function - ie the echo statements - do not show up. They are there, but they are getting lost behind the header image. I know that this is a layout and css problem, but it has caused a real headache for me in terms of getting the dynamic aspect functioning. When I set up the config.php file I know that it includes an error handling trigger. So I am sure that if I can just get that tagged properly then it will solve this problem, but I am not sure I have set up every page to be linked properly to this file. So I am working out how to solve that problem.
Here is a list of issues that I need to address before submission:
1. Error message layout
2. Personalise the 'Welcome' message when a user logs in.
3. Reset the 'submit recipe' form after a recipe has been submitted
4. Fix 'approx year' and 'category' drop down menu's so the user has to enter a field for successful form submission.
A couple of hopefulls:
1. Refine each recipe page (mains, desserts etc) to include a dynamically linked heading - which can be expanded when clicked on to include the full recipe details.
2. Sort out the recipe tab on the menubar at the top to work like the recipe pages below.
3. Set up the 'guidelines for use' page and link
You know this is a lot like life! You spend all your time working on something that is just not right, thinking that if I can just get through this then everything will be perfect. But once you solve one problem a million others pop up to replace it.
I have now discovered that the error report function - ie the echo statements - do not show up. They are there, but they are getting lost behind the header image. I know that this is a layout and css problem, but it has caused a real headache for me in terms of getting the dynamic aspect functioning. When I set up the config.php file I know that it includes an error handling trigger. So I am sure that if I can just get that tagged properly then it will solve this problem, but I am not sure I have set up every page to be linked properly to this file. So I am working out how to solve that problem.
Here is a list of issues that I need to address before submission:
1. Error message layout
2. Personalise the 'Welcome' message when a user logs in.
3. Reset the 'submit recipe' form after a recipe has been submitted
4. Fix 'approx year' and 'category' drop down menu's so the user has to enter a field for successful form submission.
A couple of hopefulls:
1. Refine each recipe page (mains, desserts etc) to include a dynamically linked heading - which can be expanded when clicked on to include the full recipe details.
2. Sort out the recipe tab on the menubar at the top to work like the recipe pages below.
3. Set up the 'guidelines for use' page and link
Recapping
Not sure if I have covered this in a previous post, but thought I better just mention that I have changed the format of the submit recipe form a bit.
When Phil and I were going through the search recipe function a few weeks ago it became evident that the option to have all recipes linked to three main ingredients (to accommodate an option to search for a recipe by a particular ingredient) was going to cause a real headache when trying to link the associated_ingredients_id with each recipe. So he and I agreed that it would be easier to just create a function which would search for ingredients LIKE which ever one you wanted. So the coding in the search for recipe form looks like this:
$query = "SELECT recipe_title AS Recipe, recipe_ingredients_list AS Ingredients, recipe_method AS Method FROM recipe WHERE category_id = $type AND recipe_ingredients_list LIKE '%".$_POST['ingredients']."%'ORDER BY recipe_title ASC, recipe_ingredients_list ASC, recipe_method ASC"
This then searches for any recipe which has an ingredient that is like the ingredient chosen in the search form. I also included an option to refine the search according to the category chosen.
This meant that I no longer had to include the checkbox option for assiciated ingredients in the submit a recipe form - this checkbox part of the form was also causing headaches. I had actually set up a small piece of javascript in the header.html template to handle this checkbox function. But will not need this anymore.
When Phil and I were going through the search recipe function a few weeks ago it became evident that the option to have all recipes linked to three main ingredients (to accommodate an option to search for a recipe by a particular ingredient) was going to cause a real headache when trying to link the associated_ingredients_id with each recipe. So he and I agreed that it would be easier to just create a function which would search for ingredients LIKE which ever one you wanted. So the coding in the search for recipe form looks like this:
$query = "SELECT recipe_title AS Recipe, recipe_ingredients_list AS Ingredients, recipe_method AS Method FROM recipe WHERE category_id = $type AND recipe_ingredients_list LIKE '%".$_POST['ingredients']."%'ORDER BY recipe_title ASC, recipe_ingredients_list ASC, recipe_method ASC"
This then searches for any recipe which has an ingredient that is like the ingredient chosen in the search form. I also included an option to refine the search according to the category chosen.
This meant that I no longer had to include the checkbox option for assiciated ingredients in the submit a recipe form - this checkbox part of the form was also causing headaches. I had actually set up a small piece of javascript in the header.html template to handle this checkbox function. But will not need this anymore.
Last Week
This week has been extremely frustrating in terms of getting the site to where I want it. I had planned to spend this last week working on making the site more presentable and looking good, but that has gone out the window now.
I am still struggling with the final form function - the Submit a Recipe Form. I had set up a time for Phil to sit down with me and go through it, but he pulled out at the last minute and can't see me till Friday night. So I have spent some of this week trying to work it out on my own (in between finishing off a 2,500 word essay for another unit). I know I have the bones of it right, but there is obvously something amiss somewhere.
Next day....
I posted an explanation of what I wanted to achieve on the forum and got some suggestions. Most of them were things that I had already tried or was about to try. But at least I still had some avenues t pursue, so I started looking at breaking the functions down and trying to get one thing going at a time.
Then Peter got on Yahoo and we worked on it for about 3 hours (what I would do without him I never know). Here is an explanation of what was changed
1. Solving the form validation problem:
This was the first thing that we looked at. After some trial and error Peter pointed out that I did not have a line in there to recognise the submitted function.
eg. input type="hidden" name="submitted" value="TRUE" /
So that went in at line 277 of the submit.php page
This finally got the form validation going.
2. Solving the SELECT and INSERT $query for the user_id, recipe_year_id, and category_id issues. I had been trying lots of different things to get this working, but of course nothing was working up till now because I wasn't even getting past the form validation (hence the idea to break things down into smaller functions).
Anyway, I figured that if I included the username in the form then I could SELECT the user_id FROM the user table WHERE user_name=$un.
Peter questioned me on this part of my coding and suggested that we could discard the username part of the form and just call up the session (since the user would be logged in to submit a form). So at line 58 we placed:
$un = ($_SESSION['user_id']) ;
and then set the query to SELECT user_id FROM user WHERE user_name=$un
After a bit of shuffling things around and adding some ; and ' and } it all started to fall into place. Piece by piece I got the database to record all the information in the right order, with all the right id's, and finally the timestamp working.
I wanted to cry!!! Well, actually I did, but I'll deny it now :-)
How sweet it is when you crack something that you have literally been working on for weeks. I love going in there now and entering a new recipe and seeing the results. Oh the power!!!!
I am still struggling with the final form function - the Submit a Recipe Form. I had set up a time for Phil to sit down with me and go through it, but he pulled out at the last minute and can't see me till Friday night. So I have spent some of this week trying to work it out on my own (in between finishing off a 2,500 word essay for another unit). I know I have the bones of it right, but there is obvously something amiss somewhere.
Next day....
I posted an explanation of what I wanted to achieve on the forum and got some suggestions. Most of them were things that I had already tried or was about to try. But at least I still had some avenues t pursue, so I started looking at breaking the functions down and trying to get one thing going at a time.
Then Peter got on Yahoo and we worked on it for about 3 hours (what I would do without him I never know). Here is an explanation of what was changed
1. Solving the form validation problem:
This was the first thing that we looked at. After some trial and error Peter pointed out that I did not have a line in there to recognise the submitted function.
eg. input type="hidden" name="submitted" value="TRUE" /
So that went in at line 277 of the submit.php page
This finally got the form validation going.
2. Solving the SELECT and INSERT $query for the user_id, recipe_year_id, and category_id issues. I had been trying lots of different things to get this working, but of course nothing was working up till now because I wasn't even getting past the form validation (hence the idea to break things down into smaller functions).
Anyway, I figured that if I included the username in the form then I could SELECT the user_id FROM the user table WHERE user_name=$un.
Peter questioned me on this part of my coding and suggested that we could discard the username part of the form and just call up the session (since the user would be logged in to submit a form). So at line 58 we placed:
$un = ($_SESSION['user_id']) ;
and then set the query to SELECT user_id FROM user WHERE user_name=$un
After a bit of shuffling things around and adding some ; and ' and } it all started to fall into place. Piece by piece I got the database to record all the information in the right order, with all the right id's, and finally the timestamp working.
I wanted to cry!!! Well, actually I did, but I'll deny it now :-)
How sweet it is when you crack something that you have literally been working on for weeks. I love going in there now and entering a new recipe and seeing the results. Oh the power!!!!
Friday, August 22, 2008
Assignment 2 Results
Just got my results back for assignment 2. I am very encouraged by them and appreciate the feedback. When I submitted the assignment I struggled to know how I was going to include the progress report. In the end I decided to include a link to it through the assignment cover sheet. I wondered at the time whether that was a bit too obsolete, and Edwin cofirmed that when he commented on being a bit lost when he first went into my site.
So, appologies Edwin, this time I have taken your advice and have included a link to the progress report blog at the bottom of my web site. Hope this makes it easier for you for next time.
Up to today I have managed to get the following working, in regards to the dynamic aspect of the site:
1. Registration/activation
2. Login
3. Logout
4. Reset Password
5. Forgot Password
6. Search Recipe Form
7. Search for Recipe
I still need to cover the following:
1. Add a recipe - this has proved to be the hardest aspect of all and in my mind the most important of the site (this will be my focus for the completion of assignment 3).
2. Refining each recipe page (mains, desserts, cakes and biscuits) to include just a dynamically linked heading to each recipe, rather than displaying the entire recipe in the list.
3. Refining each recipe search to include just a dynamically linked heading to each recipe found, rather than displaying the whole recipe in a list (both this and item 2. above are included only if I have time. They are not necessary now as the site stands, but as recipes are added and the result lists get bigger they will be a necessary part of it).
So, appologies Edwin, this time I have taken your advice and have included a link to the progress report blog at the bottom of my web site. Hope this makes it easier for you for next time.
Up to today I have managed to get the following working, in regards to the dynamic aspect of the site:
1. Registration/activation
2. Login
3. Logout
4. Reset Password
5. Forgot Password
6. Search Recipe Form
7. Search for Recipe
I still need to cover the following:
1. Add a recipe - this has proved to be the hardest aspect of all and in my mind the most important of the site (this will be my focus for the completion of assignment 3).
2. Refining each recipe page (mains, desserts, cakes and biscuits) to include just a dynamically linked heading to each recipe, rather than displaying the entire recipe in the list.
3. Refining each recipe search to include just a dynamically linked heading to each recipe found, rather than displaying the whole recipe in a list (both this and item 2. above are included only if I have time. They are not necessary now as the site stands, but as recipes are added and the result lists get bigger they will be a necessary part of it).
Sunday, August 17, 2008
The most complicated part
When I went and talked to Phil I suddenly realised where I had gone wrong. I had spent the last three weeks bogged down in trying to get the most complicated part of the web site functioning. I really should have started with the simplest part first - which was the search recipe form. Instead I was bogging myself down in something that required a bit more experience.
So, now that I have completed the easiest part of the site (the search_form.php) I am working on what I realise is the most complicated aspect of the site - the submit a recipe form and its dynamic function.
Phil spent a bit of time showing me what I needed to include in the code for this, and even gave me an idea of how I was to link the recipe_year_id into the recipe table. But I am still struggling with how to link the user_id into the recipe table.
The recipe_year_id is simple enough as the form asks for an identifying year within it and therefore allocates its id as $ry within the form. That allows me to connect an innitial $query of:
SELECT recipe_year_id FROM recipe_year WHERE recipe_year = '$ry' ,
which selects the correct recipe_year_id before I insert anything into the recipe table.
The category_id should be ok too as the form identifies the category it will be in - again allocating it as $r - and therefore can be inserted into the recipe table.
However, I also need to link the recipe to a user_id (as only users can submit recipes) and I am not sure how to do this.
Have tried a few things, but not even having any luck getting the submit.php page up without an error at the moment. Most frustrating!
So, now that I have completed the easiest part of the site (the search_form.php) I am working on what I realise is the most complicated aspect of the site - the submit a recipe form and its dynamic function.
Phil spent a bit of time showing me what I needed to include in the code for this, and even gave me an idea of how I was to link the recipe_year_id into the recipe table. But I am still struggling with how to link the user_id into the recipe table.
The recipe_year_id is simple enough as the form asks for an identifying year within it and therefore allocates its id as $ry within the form. That allows me to connect an innitial $query of:
SELECT recipe_year_id FROM recipe_year WHERE recipe_year = '$ry' ,
which selects the correct recipe_year_id before I insert anything into the recipe table.
The category_id should be ok too as the form identifies the category it will be in - again allocating it as $r - and therefore can be inserted into the recipe table.
However, I also need to link the recipe to a user_id (as only users can submit recipes) and I am not sure how to do this.
Have tried a few things, but not even having any luck getting the submit.php page up without an error at the moment. Most frustrating!
Subscribe to:
Posts (Atom)
