| Blog Form |
|
BLOG FORM
Database: blog Table: blog title This is The New Blog This is The New Blog2 content Vestibulum dolor dolor, bibendum nec iaculis quis,... Lorem ipsum dolor sit amet, consectetur adipiscing... date 2016-04-15 00:00:00 2016-04-08 00:00:00 http://localhost/blog/ Can anyone help me fix the code so that it could capture : Upload : [ browse ] Title : Title Content : Content views/blog_form.php PHP Code: <html>controllers/blog.php PHP Code: <?phpmodels/blog_model.php PHP Code: <?php
" If I looks more intelligence please increase my reputation."
In the view:
- The html element should have a head element (containing the title element, meta elements, and maybe link/style elements and the occasional script element) and a body element (containing the content of your page, so pretty much everything other than the title in your example). - You shouldn't use a table to control the layout of your form (use CSS to control the layout, the CSS should be in a style element or in a separate CSS file referenced by a link element). - You shouldn't close your form before closing your table, since your form was open when you opened the table. This makes the HTML invalid and causes potentially unpredictable results. Different browsers can give different results in interpreting invalid HTML. - The text related to the input elements should be enclosed in label elements, and those should use the label element's "for" attribute to associate the label with the input element (the value of the "for" attribute should match the value of the input's (or textarea's) "id" attribute). This not only makes it easier to write CSS to control the layout of the form, it also makes it easier for users to navigate the form (especially those using screen-readers). Some people add additional div elements around a label and its associated control(s) to make it even easier to control the layout (and some goes as far as adding as many elements as (or more than) they would have had if they had used a table). - Each element which will contain a value to be submitted in the form must have a name attribute, the value of which will be used when referencing the value in PHP. - Given that you've included the calendar inside a form and labeled it "Date :", I don't think the calendar is going to do quite what you're expecting it to do. CI's calendar is not a datepicker. With some of these changes, your view might look something like this: PHP Code: <!DOCTYPE html>This still has one glaring issue, and that is the argument to the form_open() function. Since this is set to 'blog', it will submit the form to whatever you've routed 'blog' to on your site (by default, this would be 'blog/index', or the index() method in your Blog controller). It would be unusual to configure your index() method to handle posts from a form, and you certainly haven't done so in your controller. In your controller's index() method, you're calling the same method in your model three times and assigning it to three different values in your $data variable with no changes in the method call. This implies that either you're assigning the same data to $data['title'], $data['content'], and $data['date'], or your select_blog() method in your blog_model holds some internal state and you have to call it in the correct order to retrieve each part of your data. The former is bad simply because you're retrieving and storing the same data three times. The latter would be worse, because it makes it much easier to make bigger mistakes. Since you've included the code for the model, we can see that the method is simply querying the database ("select * from blog") and returning the result, so you're calling the database three times and retrieving everything from your table and storing it in three array values. Further, your query result is an array of rows from the table, so the names of the keys in your $data array are a bit misleading. You haven't included your blog view, so we can't determine whether you've dealt with this properly. It's also a good idea to initialize your variable(s) before use. Your blog_form() method just loads the view. It doesn't attempt to retrieve data to display in the view, and has no code to handle a post from the form (and the form doesn't post back to this method anyway...). Given the fields in your form, you should probably review the documentation on the form validation and file upload libraries in order to validate and process the data in your form. You will also need to modify your view to use form_open_multipart() to process the file input properly (something I overlooked when I modified the view above). Finally, we get to the model. You're using query builder for your insert/update methods, but not your select method. Sometimes there are good reasons for this, and you might have one down the road, but at this point you should either use it or don't. By using query builder, your select method could be simplified to the following: PHP Code: public function select_blog()If you needed to modify the select portion of the query, you would just add a call to the select() method: PHP Code: public function select_blog()You can continue with the method names as you already have them, but I find them a bit redundant. When calling your model from a controller, you'll end up with things like $this->blog_model->select_blog(), $this->blog_model->insert_blog(), and $this->blog_model->update_blog(). You could remove the '_blog' suffix from each method name and have $this->blog_model->select(), $this->blog_model->insert(), and $this->blog_model->update(). Your insert and update methods in the model are retrieving data directly from the $_POST[] array and using time() to set the value for the 'date' field. While I'm a fan of "fat" models (or models with more functionality encapsulated within them), I tend to think that the controller should retrieve the data submitted by the form, then pass that data to the model. Further, you should use $this->input->post() instead of $_POST[], and validate your data before passing it to the database. If you retrieve the data in the controller and pass it to the model, you can isolate the model from the view and use the model in other contexts. For example, if you later needed to update the blog from a different form, and the new form had to use different names for the fields for some reason (maybe to distinguish the blog title from a user's professional title), the controller called by that form can load the same model and choose which form fields will be used for which properties in the model. While assigning your data to public properties in your model can be useful for certain situations, it's probably not a good idea to pass $this as the data parameter to query builder's insert()/update() methods. You could create a simple object to represent the data contained in an individual row of your database result and use that as a "Custom Result Object" as detailed in the documentation ( https://codeigniter.com/user_guide/datab...lt-objects ), but that object would be defined in a separate class. Further, $this is used in CI_Model to return a reference to the CI_Controller instance when a method/property isn't found in our model; while this may not have any impact on what happens when you pass it to query builder's insert()/update() methods, it's usually easier to just avoid doing things which can potentially cause difficult-to-trace issues later. |
| Welcome Guest, Not a member yet? Register Sign In |
MENU
EXTRA MENU
ABOUT US
CodeIgniter is a powerful PHP framework with a very small footprint, built for developers who need a simple and elegant toolkit to create full-featured web applications.
