(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!
Dealing with the Search Form and conditionals.
This last week has been a learning curve of sorts. I spent about 3 hours with my friends husband, Phil, who in some ways managed to confuse me even more, but in most ways helped me work through some of the issues I was up against.
He took me through some of the basics of sql and helped me to understand some simple things relating to 'values', 'names' and 'id's'. I finally got the connection between the allocation of values and names when doing forms, and how they related to the php code when executing a search.
Just prior to meeting with Phil I had a breakthrough with my recipe search function and got the search form working dynamically, so that the drop-down menu pulled the information for the categories and ingredients directly from the database. I was really pleased to be able to work this funcion out on my own. But much of it was trial and error and not a lot of understanding. Phil was able to enlighten me on it and I was then able to work through the actual php coding for the recipe search with him.
We talked about how I had set up the 'submit recipe' function in my design and analysis document and we both determined that by asking the user to submit three connected ingredients to their recipe may make the search function too complicated. So I decided to scrap this idea and make it a little more simple. I wanted to keep the idea of limiting the search to just 16 ingredients, so Phil showed me a way to set-up the $query statement to reflect a direct search for a category and then a 'LIKE' statement to reflect a search for an ingredient. He came up with this:
$query = "SELECT * FROM recipe WHERE recipe_ingredients_list LIKE '%".$_POST['ingredients']."%' and category = $type";
I got home from meeting with him and got stuck into the details of the search form. I had to fiddle around with the Select query a bit to get it to work. I shifted the conditionals around a little bit and finally got it to work really well. At first I got it working, but it was clear that the category conditional was not working as I kept getting recipes displayed which didn't fit in with the chosen category, but after shifting the order of the conditionals around I had success. This is what I ended up with:
$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 $query uses the LIKE conditional and asks for any recipe within the designated category which contains the designated ingredient, LIKE that described in the search form, through the 'search for recipe' function on each page of the site. It calls for the title, ingredients list and method for each relevant recipe.
} else {
$query = "SELECT recipe_title AS Recipe, recipe_ingredients_list AS Ingredients, recipe_method AS Method FROM recipe WHERE recipe_ingredients_list LIKE '%".$_POST['ingredients']."%'ORDER BY recipe_title ASC, recipe_ingredients_list ASC, recipe_method ASC"; }
//This calls for any recipe within the designated ingredient list and does not require a designated category. Because some users may want to only search for a recipe with a certain ingredient without having to specify a category. Choosing a category is not compulsory. $result = @mysql_query ($query);
I managed to refine the $query even more by adding the ORDER BY conditional, and adding some headings and borders, to create a simple table to display the results in. The result was simple, but effective. Not sure if I will have the time to refine the layout for it, but am happy that I got the dynmics working, which fulfills the requirements of the assignment.
He took me through some of the basics of sql and helped me to understand some simple things relating to 'values', 'names' and 'id's'. I finally got the connection between the allocation of values and names when doing forms, and how they related to the php code when executing a search.
Just prior to meeting with Phil I had a breakthrough with my recipe search function and got the search form working dynamically, so that the drop-down menu pulled the information for the categories and ingredients directly from the database. I was really pleased to be able to work this funcion out on my own. But much of it was trial and error and not a lot of understanding. Phil was able to enlighten me on it and I was then able to work through the actual php coding for the recipe search with him.
We talked about how I had set up the 'submit recipe' function in my design and analysis document and we both determined that by asking the user to submit three connected ingredients to their recipe may make the search function too complicated. So I decided to scrap this idea and make it a little more simple. I wanted to keep the idea of limiting the search to just 16 ingredients, so Phil showed me a way to set-up the $query statement to reflect a direct search for a category and then a 'LIKE' statement to reflect a search for an ingredient. He came up with this:
$query = "SELECT * FROM recipe WHERE recipe_ingredients_list LIKE '%".$_POST['ingredients']."%' and category = $type";
I got home from meeting with him and got stuck into the details of the search form. I had to fiddle around with the Select query a bit to get it to work. I shifted the conditionals around a little bit and finally got it to work really well. At first I got it working, but it was clear that the category conditional was not working as I kept getting recipes displayed which didn't fit in with the chosen category, but after shifting the order of the conditionals around I had success. This is what I ended up with:
$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 $query uses the LIKE conditional and asks for any recipe within the designated category which contains the designated ingredient, LIKE that described in the search form, through the 'search for recipe' function on each page of the site. It calls for the title, ingredients list and method for each relevant recipe.
} else {
$query = "SELECT recipe_title AS Recipe, recipe_ingredients_list AS Ingredients, recipe_method AS Method FROM recipe WHERE recipe_ingredients_list LIKE '%".$_POST['ingredients']."%'ORDER BY recipe_title ASC, recipe_ingredients_list ASC, recipe_method ASC"; }
//This calls for any recipe within the designated ingredient list and does not require a designated category. Because some users may want to only search for a recipe with a certain ingredient without having to specify a category. Choosing a category is not compulsory. $result = @mysql_query ($query);
I managed to refine the $query even more by adding the ORDER BY conditional, and adding some headings and borders, to create a simple table to display the results in. The result was simple, but effective. Not sure if I will have the time to refine the layout for it, but am happy that I got the dynmics working, which fulfills the requirements of the assignment.
Sunday, August 10, 2008
Cleaning up the database
While I am waiting to get together with the mysql expert, I have decided to go back to my databsae and see if it needs to be cleaned up and tightened up a bit. I think that if I can get that in order that I might be able see a bit clearer on how to connect the foreign keys to each other when setting up the 'add a recipe' form.
This whole connection between tables and foreign keys has got me completely baffled. It is like the text book, Ullman, skirts around it with every database interface it covers. Then, I can't quite pinpoint what I should be querying when I search on the net for a solution. So I come up with nothing in that avenue too.
A couple of things I have done from this:
1. Ensured that every primary key and foreign key are of the same type - SMALLINT(4) UNSIGNED NOT NULL.
2. I fixed up the recipe table so that all the foreign keys are at the top of the table (below the primary key) instead of spread all over the place.
3. Ensured that every primary key is of the same type as their corresponding foreign key in other tables.
This whole connection between tables and foreign keys has got me completely baffled. It is like the text book, Ullman, skirts around it with every database interface it covers. Then, I can't quite pinpoint what I should be querying when I search on the net for a solution. So I come up with nothing in that avenue too.
A couple of things I have done from this:
1. Ensured that every primary key and foreign key are of the same type - SMALLINT(4) UNSIGNED NOT NULL.
2. I fixed up the recipe table so that all the foreign keys are at the top of the table (below the primary key) instead of spread all over the place.
3. Ensured that every primary key is of the same type as their corresponding foreign key in other tables.
Saturday, August 9, 2008
The Home Stretch
Ok, now that the second assignment is in, it must be all downhill from here. Or maybe it is a steep climb to the end. It was a real stretch to get the second assignment in. I really didn't think that I was going to make it with my login and logout code. But thanks to the help of Peter Martin (another student) I was able to get it over the line just in time, with the login and logout working well.
I faced up to the reality of what I need to accomplish over the next few weeks with this assignment and wondered if I will be able to achieve what I outlined in the Analysis and Design Document. Edwin made comment in my assignment 1 results that it was a good and solid database outline, but that it was going to be tricky and complex (but manageable). This week I started early to tackle what I thought would be the most difficult part of the site - the 'add a recipe' form and its complex coding. This was a dramatic understatement. I have spent all week struggling to understand just how I am going to do it.
My biggest problem has been knowing how to approach the issue of dealing with information which needs to be distributed to several different tables and then reflected back into the recipe table and the associated_ingredients table through Foreign keys. I have read just about every part of Ullman, several times over, trying to get a feel for the correct flow of the coding for it. But there is nothing in there that is clear in how to deal with multiple tables in the way that I need. I think I was spoilt with the first assignment, in that Ullman provided a perfect framework for what I wanted to achieve with the login and logout pages. What gets me is that there are bits here and there of code which I think are relevant, but I just don't know how to put it together to make it work. Now I feel like I am totally on my own and unable to get an idea of how to even approach it. I spent a lot of time on the net searching form something that would get me on the right track. But, again, nothing which resembled anything I need to do with the form. My biggest issue is that I don't know what order to do things in, and how to link so many different fileds to so many different tables.
I linked up with Peter again on Friday for about two hours on Yahoo, but as he has not done anything like this either we really didn't make any headway. I have been thinking that I need to link up with someone locally who has a hand on this whole thing, who can walk me through some of the more obvious aspects of it. By 2am this morning I realised that i was not going to do it on my own.
This morning I rang the husband of a friend who I thought might either know something or someone to help me. I started telling him what the assignment entailed and he jumped in and said that mysql was like talking english for him. So I am going to get together with him sometime this week and nut out how I need to approach the rest of the site design. I feel so much better about this now. By having someone right next to me and being able to answer my questions and offer solutions is going to make this so much easier for me. Yesterday I was considering a fail on this assignment as I couldn't see a way out of this. But today I think I am actually going to get something out of this unit and come away having learnt something.
I faced up to the reality of what I need to accomplish over the next few weeks with this assignment and wondered if I will be able to achieve what I outlined in the Analysis and Design Document. Edwin made comment in my assignment 1 results that it was a good and solid database outline, but that it was going to be tricky and complex (but manageable). This week I started early to tackle what I thought would be the most difficult part of the site - the 'add a recipe' form and its complex coding. This was a dramatic understatement. I have spent all week struggling to understand just how I am going to do it.
My biggest problem has been knowing how to approach the issue of dealing with information which needs to be distributed to several different tables and then reflected back into the recipe table and the associated_ingredients table through Foreign keys. I have read just about every part of Ullman, several times over, trying to get a feel for the correct flow of the coding for it. But there is nothing in there that is clear in how to deal with multiple tables in the way that I need. I think I was spoilt with the first assignment, in that Ullman provided a perfect framework for what I wanted to achieve with the login and logout pages. What gets me is that there are bits here and there of code which I think are relevant, but I just don't know how to put it together to make it work. Now I feel like I am totally on my own and unable to get an idea of how to even approach it. I spent a lot of time on the net searching form something that would get me on the right track. But, again, nothing which resembled anything I need to do with the form. My biggest issue is that I don't know what order to do things in, and how to link so many different fileds to so many different tables.
I linked up with Peter again on Friday for about two hours on Yahoo, but as he has not done anything like this either we really didn't make any headway. I have been thinking that I need to link up with someone locally who has a hand on this whole thing, who can walk me through some of the more obvious aspects of it. By 2am this morning I realised that i was not going to do it on my own.
This morning I rang the husband of a friend who I thought might either know something or someone to help me. I started telling him what the assignment entailed and he jumped in and said that mysql was like talking english for him. So I am going to get together with him sometime this week and nut out how I need to approach the rest of the site design. I feel so much better about this now. By having someone right next to me and being able to answer my questions and offer solutions is going to make this so much easier for me. Yesterday I was considering a fail on this assignment as I couldn't see a way out of this. But today I think I am actually going to get something out of this unit and come away having learnt something.
Thursday, July 31, 2008
References
(N.D.). 5.4.7. Causes of Access denied Errors. MySQL 5.0 Reference Manual, MySQL. http://dev.mysql.com/doc/refman/5.0/en/access-denied.html
(N.D.). 5.4.7. Causes of Access denied Errors. MySQL 5.0 Reference Manual, MySQL. http://dev.mysql.com/doc/refman/5.0/en/access-denied.html
(N.D.). B.1.4.1. How to Reset the Root Password. MYSQL 5.0 Reference Manual, MYSQL. http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
Maurer, T. (2008). Active Field for Registration page crmalibu, Sitepoint.
Maurer, T. (2008). Activation Solution. Petermartin29, Yahoo Messenger.
Maurer, T. (2008). Failure to Activiate. Bianca Todd & Peter Martin, Curtin UniversitybWebCT.
Meloni, J. C. (2007). PHP, MySQL and Apache, Sams Publishing.
Sean. (2007). "Registration Script." Retrieved 29th July 2008, from http://www.tutorialcode.com/php/registration-script/
Student, S. (2008). "Registration activation through email verification ation ation " Retrieved 29th July 2008, from http://codeigniter.com/forums/viewthread/75576
Taylor, A. G. (2003). SQL Wiley Publishing.
Ullman (2005). PHP and MySQL For Dynamic Web Sites, Peachpit Press.
Ullman, L. (2005). Programming with PHP. PHP and Mysql For Dynamic Web Sites, Peachpit: 35-79.
Ullman, L. (2005). Example - User Registration. PHP and MySQL for Dynamic Websites, Peachpit Press: pp. 527-575.
Valade, J. (2008). PHP & MySQL Web Development, Wiley Publishing.
Breakthrough!
Well, I didn't think I would make it, but thanks to Peter Martin's help I got there. I now have a fully functioning registration, login and logout function on my website. It took about 6 hours last night to work through it. In the end it was just a matter of one or two changes to the script. But it was a marathon effort.
Most of what occured is mentioned in my comments within the script, but really it was just a matter of working through each error message as they arose and dealing with them one by one. Most were very simple, such as leaving a comma in where it shouldn't be and knowing the correct field to include when using sessions and how those connected to other pages.
We really got bogged down in it after a while so, since I was pretty much using the same script as Ullman (Ullman, 2005, pp. 527-575), Peter suggested we download the script for the login and logout pages from his book and start again. Two things occurred at that moment:
1. I went into shock to discover that I could have downloaded the script from Ullman's website. I had spent a good part of a week typing up the script for each page thinking that was the only way I could get it into my notebook++. However, I was consoled when I realised that I learnt a heck of a lot of stuff by typing it up myself and figuring out what much of it meant.
2. I was reluctant to download it as I was fairly sure that I had typed it up pretty accurately (since I had gone through it so slowly when I did it) and that I had only made a few changes to the original script. However, I knew I was not infallable (I know, hard to believe isn't it!) so I agreed.
We spent the next several hours going through each line step by step and working out what the problems were when we tested it. It proved to be a really worthwhile exercise as this morning i was able to go through and comment on everything in more detail without much help from the text book.
Please note:
Most of what occured is mentioned in my comments within the script, but really it was just a matter of working through each error message as they arose and dealing with them one by one. Most were very simple, such as leaving a comma in where it shouldn't be and knowing the correct field to include when using sessions and how those connected to other pages.
We really got bogged down in it after a while so, since I was pretty much using the same script as Ullman (Ullman, 2005, pp. 527-575), Peter suggested we download the script for the login and logout pages from his book and start again. Two things occurred at that moment:
1. I went into shock to discover that I could have downloaded the script from Ullman's website. I had spent a good part of a week typing up the script for each page thinking that was the only way I could get it into my notebook++. However, I was consoled when I realised that I learnt a heck of a lot of stuff by typing it up myself and figuring out what much of it meant.
2. I was reluctant to download it as I was fairly sure that I had typed it up pretty accurately (since I had gone through it so slowly when I did it) and that I had only made a few changes to the original script. However, I knew I was not infallable (I know, hard to believe isn't it!) so I agreed.
We spent the next several hours going through each line step by step and working out what the problems were when we tested it. It proved to be a really worthwhile exercise as this morning i was able to go through and comment on everything in more detail without much help from the text book.
Please note:
*The Reset Forgotten Password and the Change Password links and files do not function yet.
* Also, the link to the functioning website through geoffrey_multimedia is situated at the top righthand of this blog, titled The 'Raspberry Whirl' Website
A couple of things need to be addressed, but nothing that effects the register, login and logout functions. I will list them below to remind myself of what I need to look at over the next four weeks to get it functioning as I want.
1. Understand the output buffering and make sure it functions on the pages that it needs.
2. Sort out the issue with the 'Welcome, 'username' not showing up when a user logs in.
3. Understand more about sessions and cookies and make sure they are functioning properly on each page
4. Possibly address the issue of having to move the login form from the top menu bar to a separate page. I didn't have time to research how to make this dynamic while it sits in the header.html template.
There are also some major things that I will need to address, that I don't understand, to get my site working in the way I outlined in the design document.
They are:
1. How I am going to make the search recipe option dynamic, since it sits in the header.html template. Similare to point 4 above.
2. How I am going to write the script for the highly complicated 'Submit Recipe' form (I am really dreading this after my experience with the fairly simple login/logout forms).
Tuesday, July 29, 2008
Activation of Registration
I have decided to make this a separate post as there is so much to this issue.
When I innitially made the attempt to register for the firts time I got as far as the activation link within the email before the error trigger showed up and I was not able to activate the registration. The active field of the database showed that there had been a registration with a email, username, and password, but that it had not been activated. the active column showed the #2 under it. Subsequent tries had the same result - all having the #2 in the active column.
I spent a lot of time cleaning up the script and managed to fix up the Parse errors and script errors, but couldn't get the validation to work.
My thinking was that it had something to do with the database setup, but I wasn't sure. Everything validated within the register.php, and it wasn't until the validate.php page was called up that the error message appeared. This said to me that the problem lay in the database structure.
As I studied the script in the activate.php file I felt that I should have to change the Char from (1) to (32), as the '$y' generated a temporary 32 character string which validates the registration, and then it reverts to NULL when the registration is validated. But changing this didn't solve the validation problem. So I was not sure where to look from there.
I did a bit of research on the internet, but couldn't find anything specific enough to solve the problem (Sean, 2007)(student, 2008). So I decided to ask for help on the WebCT forum. I recieved a couple of repsonses and then an email from Peter Martin suggesting we walk through it together on Yahoo Messenger (Maurer, 2008). He spent over an hour with me going through both the register.php script and the activate.php script. I also posted a question on Sitepoint Forums and had a response, but Peter and I had solved it before I could get right into it (Maurer, 2008).
It all came down to two problems. The first one was discovered by Peter:
1. The setting the variable for activate as '$a' on line 40 of the register.php page. I had not properly set it, but had actually set it as NOW(). Which meant I was issuing a date and time to it and not a variable. So I changed it. However, it still didn't solve the problem with the validation, but, both Peter and I felt that we were not far from the solution and that this was part of it.
2. I then mentioned that we probably should change the active field to Char(32) to allow for the 32 character temporary string. I ended up giving it Char(40). This worked a treat and before I knew it Peter had registered and validated.
Since then I believe I also need to change the NULL column to NULL instead of NOT NULL, as once registration is activated the active column reverts from a 32 character string to NULL. The database works the same with it, but still not sure if this is the right thing to do. Will keep looking into it.
Right now I have another problem on my hands. Validation works, but when I try to login after validation I keep getting the error:
Please enter a valid password
Please enter a valid username
So back to the drawing board....
When I innitially made the attempt to register for the firts time I got as far as the activation link within the email before the error trigger showed up and I was not able to activate the registration. The active field of the database showed that there had been a registration with a email, username, and password, but that it had not been activated. the active column showed the #2 under it. Subsequent tries had the same result - all having the #2 in the active column.
I spent a lot of time cleaning up the script and managed to fix up the Parse errors and script errors, but couldn't get the validation to work.
My thinking was that it had something to do with the database setup, but I wasn't sure. Everything validated within the register.php, and it wasn't until the validate.php page was called up that the error message appeared. This said to me that the problem lay in the database structure.
As I studied the script in the activate.php file I felt that I should have to change the Char from (1) to (32), as the '$y' generated a temporary 32 character string which validates the registration, and then it reverts to NULL when the registration is validated. But changing this didn't solve the validation problem. So I was not sure where to look from there.
I did a bit of research on the internet, but couldn't find anything specific enough to solve the problem (Sean, 2007)(student, 2008). So I decided to ask for help on the WebCT forum. I recieved a couple of repsonses and then an email from Peter Martin suggesting we walk through it together on Yahoo Messenger (Maurer, 2008). He spent over an hour with me going through both the register.php script and the activate.php script. I also posted a question on Sitepoint Forums and had a response, but Peter and I had solved it before I could get right into it (Maurer, 2008).
It all came down to two problems. The first one was discovered by Peter:
1. The setting the variable for activate as '$a' on line 40 of the register.php page. I had not properly set it, but had actually set it as NOW(). Which meant I was issuing a date and time to it and not a variable. So I changed it. However, it still didn't solve the problem with the validation, but, both Peter and I felt that we were not far from the solution and that this was part of it.
2. I then mentioned that we probably should change the active field to Char(32) to allow for the 32 character temporary string. I ended up giving it Char(40). This worked a treat and before I knew it Peter had registered and validated.
Since then I believe I also need to change the NULL column to NULL instead of NOT NULL, as once registration is activated the active column reverts from a 32 character string to NULL. The database works the same with it, but still not sure if this is the right thing to do. Will keep looking into it.
Right now I have another problem on my hands. Validation works, but when I try to login after validation I keep getting the error:
Please enter a valid password
Please enter a valid username
So back to the drawing board....
Monday, July 28, 2008
Tiny steps at a time
I feel like I am inching my way along a precarious wall 100 feet in the air. With every tiny step there is another boulder to hurdle.
So, I got through the password issue, and into the refining of the script. I started getting the error handling messages (which I set up in the config.php file) on the username validation. Obviously there was an issue with how I set it up - so I looked at the coding.
I had taken much of the coding for the registraion page from chapter 13 of Ullman's book and had to adapt it because I was not going to require a first name and second name. So in place of the first_name and second_name I included a user_name and used the same character class :alpha and the same characters as would be used for a first or last name (Ullman, 2005, p. 406). However, I later changed the character class to :alnum, because I wanted the user to be able to use numbers as well as letters. But I forgot to change the characters within the brackets to include a-z0-9 as well. So when I tried registering the username it kept sending me the error handling message. Once I added the extra range of characters it worked a treat and I was welcomed to the Raspberry Whirl website and instructed to go to click on the link which was sent to my email address to activate my account. It was all so exciting...
EXCEPT!!!
I also had a message below the welcome which indicated that the buffering session could not be terminated as there had not been an action to commence it. I straight away checked to see if I had included the start buffering code in the header.html template, which I had. So now I have to deal with this issue.
Update: Can't work out why this is coming up as not being commencing. Have looked at the coding - very simple - but not sure. As I feel that I have some other more important things to deal with for now I have decided to take out 'output buffering' and address it later.
However, I did go to my email and I found the link there in an email for me to click on. I did so, but failed to get back into the site. Something else to look at - I suspect it may be linked to the buffering issue, or the issue below, but not sure.
Then I wondered if the new user information had been recorded in my database, so I went in there to look. I was very excited to see that it had. But the username column had the email address connected to it and the email address column had the username connected to it. So I guess the order in which you submit a query is important. I will now go in and delete my registration and see if I can get the order right so that the information can record correctly.
Update: I just discovered that I had changed the order of the form handling on the register.php page, and the INSERT INTO $query, but didn't change the order of the VALUES (line #40 on register.php). That is why it was registering under the wrong columns. :-)
So, I got through the password issue, and into the refining of the script. I started getting the error handling messages (which I set up in the config.php file) on the username validation. Obviously there was an issue with how I set it up - so I looked at the coding.
I had taken much of the coding for the registraion page from chapter 13 of Ullman's book and had to adapt it because I was not going to require a first name and second name. So in place of the first_name and second_name I included a user_name and used the same character class :alpha and the same characters as would be used for a first or last name (Ullman, 2005, p. 406). However, I later changed the character class to :alnum, because I wanted the user to be able to use numbers as well as letters. But I forgot to change the characters within the brackets to include a-z0-9 as well. So when I tried registering the username it kept sending me the error handling message. Once I added the extra range of characters it worked a treat and I was welcomed to the Raspberry Whirl website and instructed to go to click on the link which was sent to my email address to activate my account. It was all so exciting...
EXCEPT!!!
I also had a message below the welcome which indicated that the buffering session could not be terminated as there had not been an action to commence it. I straight away checked to see if I had included the start buffering code in the header.html template, which I had. So now I have to deal with this issue.
Update: Can't work out why this is coming up as not being commencing. Have looked at the coding - very simple - but not sure. As I feel that I have some other more important things to deal with for now I have decided to take out 'output buffering' and address it later.
However, I did go to my email and I found the link there in an email for me to click on. I did so, but failed to get back into the site. Something else to look at - I suspect it may be linked to the buffering issue, or the issue below, but not sure.
Then I wondered if the new user information had been recorded in my database, so I went in there to look. I was very excited to see that it had. But the username column had the email address connected to it and the email address column had the username connected to it. So I guess the order in which you submit a query is important. I will now go in and delete my registration and see if I can get the order right so that the information can record correctly.
Update: I just discovered that I had changed the order of the form handling on the register.php page, and the INSERT INTO $query, but didn't change the order of the VALUES (line #40 on register.php). That is why it was registering under the wrong columns. :-)
Now it gets exciting - Puting it all together
Yesterday I finally got enough php pages completed for me to get the database going with the website. It was a bit daunting as I have been following the posts on the forum and get really worried that if all these issues are arising with others, then they are sure to arise with me, and half the time I have no idea what they are talking about. So it was with apprehension that I made my first attempt to register through the registration page.
Predictably it didn't go well. However, I soon realised that I had not written the mysql_connect.php page up correctly. I had the DB_HOST correct 'localhost', and the DB_NAME correct too 'geoffrey_Raspberry. But I wasn't sure of the DB_USER or the DB_PASSWORD. I spent some time wondering what they would be, then went into MYSQL on geoffreymultimedia, where my database was. There it was staring me in the face - the correct information on the MySQL Account Maintenance page. Under each database heading is provided the exact PHP connection code. However, I couldn't remember the password I had set so many weeks ago (I thought I had recorded it somewher, but couln't find it).
So I spent about 2 hours yesterday and this morning trying to research how I could either locate the password, or create a new one for the database. I went to the MySQL website and did a fair bit of research on it in the Reference Manual:
http://dev.mysql.com/doc/refman/5.0/en/access-denied.html
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
But could only come up with how the change the password - but of course I had to have the old password to change to a new one. So no luck there.
I made a post on the forum to find out if anyone could help me. I got one reply - suggesting I create another database. But I didn't have the time for that. However, it did lead me to think that I might be able to copy my database and create another one with the same data and then I could create a new username and password.
So I went into my database and discovered I could do just that. So geoffrey_Raspberry became geoffrey_raspberry and the new username and password went into the mysql_connect.php and it all worked well. It actually connected to the database, but of course, there was a list of other errors I had to deal with.
Predictably it didn't go well. However, I soon realised that I had not written the mysql_connect.php page up correctly. I had the DB_HOST correct 'localhost', and the DB_NAME correct too 'geoffrey_Raspberry. But I wasn't sure of the DB_USER or the DB_PASSWORD. I spent some time wondering what they would be, then went into MYSQL on geoffreymultimedia, where my database was. There it was staring me in the face - the correct information on the MySQL Account Maintenance page. Under each database heading is provided the exact PHP connection code. However, I couldn't remember the password I had set so many weeks ago (I thought I had recorded it somewher, but couln't find it).
So I spent about 2 hours yesterday and this morning trying to research how I could either locate the password, or create a new one for the database. I went to the MySQL website and did a fair bit of research on it in the Reference Manual:
http://dev.mysql.com/doc/refman/5.0/en/access-denied.html
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
But could only come up with how the change the password - but of course I had to have the old password to change to a new one. So no luck there.
I made a post on the forum to find out if anyone could help me. I got one reply - suggesting I create another database. But I didn't have the time for that. However, it did lead me to think that I might be able to copy my database and create another one with the same data and then I could create a new username and password.
So I went into my database and discovered I could do just that. So geoffrey_Raspberry became geoffrey_raspberry and the new username and password went into the mysql_connect.php and it all worked well. It actually connected to the database, but of course, there was a list of other errors I had to deal with.
Sunday, July 27, 2008
Activation Field
In working through chapter 13 and setting up my login, join, and logout process, I discovered I will need to include an activate field in the user table of my database. This is necessary for those who join the website. They will have to activate their account before they can login for the first time.
Thursday, July 24, 2008
Some Lights are Turning on
As I start to get into the various files involved in setting up this site I am slowly realising that my innitial Design and Analysis Document is sadly lacking. Since submitting assignment 1 I have decided to base my site around much of what is presented in Ullman's Chapter 13 - Example - User Registration (2005, pp. 527-575). It covers a lot of what I wanted to include in my site, so i thought that would be the safest way to go. But I am now discovering that there is so much more in the way of file creation than I thought when I was preparing my Design Document.
Of course there are some aspects of his instructions which I won't need to use, and there are some things that I do want to use that he doesn't cover in this chapter. So it is a bit of give and take. But I thought I would highlight some of the changes or additions I will have to make here.
Header Template (header.html) - This is fairly straightforward as I covered it in earlier exercises. However, there are a couple of things that I needed to consider. At first I wasn't sure if I needed to use cookies or sessions, but after making some queries on the forum and doing some reading I will include the the sessions_start because i will be having users login and their information will need to be tracked by the server, which won't happen if I don't have sessions set up.
Footer Template (footer.html) - The footer coding in Ullman includes an option to login, logout, change password, and reset password. This is something that i had not considered innitially and will require me to create several more pages -
1. login.php - which is a separate login page. As I have the login table set-up on every page I have decided to just create a link back to the Home Page here, where they can enter their login details, rather than creating a whole new page for it.
2. forgot_password.php - This is for those users who have forgotten their password. I will keep this in, but am yet to understand fully how this works. This is an important page to have as it will offer an important service for the target audience (mostly over 60, poor memories, inexperienced Internet users etc.).
3. logout.php - This will be a fairly simple page to create as it will have a static message (tailored with the users name) on it. I will still include this.
4. change_password.php - I will include this page, but it will only be accessable when a person is logged in already.
**All these pages will be accessed via links across the bottom of every page and will be displayed according to whether a person is logged in or not (Ullman, 2005, p.530).
Configuration Scripts (config.inc.php) - This file will handle and display the errors. Innitially, as I set up the website, I will set it so that the errors will display on the web browser. When the site is complete I will set it up to notify me through email.
Database Script (mysql_connect.php) - This file sets up the database access information, creates the connection and sets up any specific functions needed to handle errors. As I have not yet attempted a connection I am still not sure how this happens, but will soon find out.
Home Page (index.php) - This page has been pretty standard as I have been through some of the earlier exercises which cover it.
Finally, as my site is not just a Registration site - unlike the excercise in Ullman - i will have a link to the registration page which will be separate to the Home Page, and it will not be mandatory to login before using the site. Anyone can use the site to browse for recipes. But to submit a recipe you must register and be logged in.
Of course there are some aspects of his instructions which I won't need to use, and there are some things that I do want to use that he doesn't cover in this chapter. So it is a bit of give and take. But I thought I would highlight some of the changes or additions I will have to make here.
Header Template (header.html) - This is fairly straightforward as I covered it in earlier exercises. However, there are a couple of things that I needed to consider. At first I wasn't sure if I needed to use cookies or sessions, but after making some queries on the forum and doing some reading I will include the the sessions_start because i will be having users login and their information will need to be tracked by the server, which won't happen if I don't have sessions set up.
Footer Template (footer.html) - The footer coding in Ullman includes an option to login, logout, change password, and reset password. This is something that i had not considered innitially and will require me to create several more pages -
1. login.php - which is a separate login page. As I have the login table set-up on every page I have decided to just create a link back to the Home Page here, where they can enter their login details, rather than creating a whole new page for it.
2. forgot_password.php - This is for those users who have forgotten their password. I will keep this in, but am yet to understand fully how this works. This is an important page to have as it will offer an important service for the target audience (mostly over 60, poor memories, inexperienced Internet users etc.).
3. logout.php - This will be a fairly simple page to create as it will have a static message (tailored with the users name) on it. I will still include this.
4. change_password.php - I will include this page, but it will only be accessable when a person is logged in already.
**All these pages will be accessed via links across the bottom of every page and will be displayed according to whether a person is logged in or not (Ullman, 2005, p.530).
Configuration Scripts (config.inc.php) - This file will handle and display the errors. Innitially, as I set up the website, I will set it so that the errors will display on the web browser. When the site is complete I will set it up to notify me through email.
Database Script (mysql_connect.php) - This file sets up the database access information, creates the connection and sets up any specific functions needed to handle errors. As I have not yet attempted a connection I am still not sure how this happens, but will soon find out.
Home Page (index.php) - This page has been pretty standard as I have been through some of the earlier exercises which cover it.
Finally, as my site is not just a Registration site - unlike the excercise in Ullman - i will have a link to the registration page which will be separate to the Home Page, and it will not be mandatory to login before using the site. Anyone can use the site to browse for recipes. But to submit a recipe you must register and be logged in.
Yes, I am still here :-)
The last week has been fairly quiet because, firstly I have had other assignments due this week, so have spent the bulk of my time on that, but secondly I have spent most of my NED24 energies on getting the various pages for my site written up. As this is fairly straight forward - using the manual to make sure I have covered everything - I've not had any real issues with it. So consequently, not much to report here.
Right now I am trying to get my index.php page working, which is proving bothersome, as I keep coming up with all these sintax errors. Normally this would be really frustrating, but since I understand that syntax errors just require a bit of patience and proof reading to be fixed, it doesn't bother me.
What is bothering me is that it is so quiet at the moment. It feels like the calm before the storm. Everything is going too well. This calm and quiet has to mean that there is going to be something major happening around the corner. I know that as soon as I start to put all this together into a working web site that the problems are going to start. With only a week to go for assignment 2, I am not sure I am ready or equiped to solve them.
Oh well, just keep going, one foot at a time and face one problem at a time.
One change I have made to the overall design of the site is to use PHP to dynamically display the appropriate login, logout, change password, forgot password links. I have followed the instructions given in Ullman to do this (Ullman, 2005, p.530).
Right now I am trying to get my index.php page working, which is proving bothersome, as I keep coming up with all these sintax errors. Normally this would be really frustrating, but since I understand that syntax errors just require a bit of patience and proof reading to be fixed, it doesn't bother me.
What is bothering me is that it is so quiet at the moment. It feels like the calm before the storm. Everything is going too well. This calm and quiet has to mean that there is going to be something major happening around the corner. I know that as soon as I start to put all this together into a working web site that the problems are going to start. With only a week to go for assignment 2, I am not sure I am ready or equiped to solve them.
Oh well, just keep going, one foot at a time and face one problem at a time.
One change I have made to the overall design of the site is to use PHP to dynamically display the appropriate login, logout, change password, forgot password links. I have followed the instructions given in Ullman to do this (Ullman, 2005, p.530).
Monday, July 14, 2008
Progressive Decisions
I have decided that I will add just a few recipes to the database to start with. Then I will try and get the database linked to the php files and get that working before I enter too much data. I think that if I try to get all the data in there at once I may be confusing myself and also making it more difficult to work out the connection process. I have yet to really work through the chapter on 'Using PHP and MySQL' and don't want to create something bigger than I can handle before I master the basics.
Next Phase
I almost forgot that this was here. I was so buried in my first assignment that I haven't had a chance to consider this blog. But as it is a requirement to show my progress in the next assignment I am going to have to make sure I touch base here a bit more often from now on.
Well, I have to say that getting the first assignment out was very stressfull. There were several time when I considered if I should actually drop this unit. It felt like I was constantly hitting a brick wall when trying to understand database structuring. My biggest hurdle was understanding where to put what in each table and then how to link them. It really stretched the logical side of my brain - not my strong side. But I have to say that once I got it (somewhat) I really did feel like a door had been opened. What capped it off was when another student posted their database structure on the forum and asked for feedback. I was able to look at it and get an idea of what it was all about and even make a suggestion on how to adjust it. I knew then that I would at least be able to come away from this unit having learnt something completely new.
This is how the structure turned out:
However, today I have been working on the actual creation of each table and have decided that I need to add a category table, with associated id, and link it to the recipe table. There will only be four categories - Main, Dessert, Cake and Biscuits - but I figure that it will be easier to link the category_id to each recipe rather than the actual name of the category.
This, I have discovered, also means that I will need to move the unique index I have placed on the category_id in the recipe table to the category column of the category_id table.
Well, I have to say that getting the first assignment out was very stressfull. There were several time when I considered if I should actually drop this unit. It felt like I was constantly hitting a brick wall when trying to understand database structuring. My biggest hurdle was understanding where to put what in each table and then how to link them. It really stretched the logical side of my brain - not my strong side. But I have to say that once I got it (somewhat) I really did feel like a door had been opened. What capped it off was when another student posted their database structure on the forum and asked for feedback. I was able to look at it and get an idea of what it was all about and even make a suggestion on how to adjust it. I knew then that I would at least be able to come away from this unit having learnt something completely new.
This is how the structure turned out:
However, today I have been working on the actual creation of each table and have decided that I need to add a category table, with associated id, and link it to the recipe table. There will only be four categories - Main, Dessert, Cake and Biscuits - but I figure that it will be easier to link the category_id to each recipe rather than the actual name of the category.
This, I have discovered, also means that I will need to move the unique index I have placed on the category_id in the recipe table to the category column of the category_id table.
Subscribe to:
Posts (Atom)
