[eluser]Nicholas Bello[/eluser]
[quote author="NogDog" date="1231023075"]"Should" might be a bit strong. Something like "could" or "a viable option" might be better. ;-)
[/quote]
That's awesome.
[quote author="NogDog" date="1231023075"]
Don't worry about it...the database can handle it and won't get tired or anything. Every time you view a page in this forum it's making a request to a database, and I'd guess it's making more than one request on each page.[/quote]
Yeah I suppose you are right, I guess I will just store the member information in the database as they go along.
[eluser]majidmx[/eluser]
Yeah, as NogDog mentioned, don't worry about the database.
But pay attention to the traffic of your application too, if it's gonna be a very high traffic application [I mean so many requests per second], it's better to reduce the amount of DB transactions, otherwise don't wory about it at all.
[eluser]darkhouse[/eluser]
I come across this a lot, I have a bunch of forms that have a multi-step process. I decided that if you use a database only, you then have to write the functions to store and retrieve the data, as well as clean up abandoned data. This sounds an awful lot like a session, and you'll probably need to store the id in a session anyways, so you might as well just use a session to store the object. I use the database to store my session data anyways. So by using sessions, there's nothing extra you need to write to get and set the data, and they get cleaned up on their own if the forms are abandoned. It's just $member = $this->session->userdata('member') to get it, add your mods for that step and then $this->session->set_userdata('member', $member);
Now, I do this in a controller with a big switch statement for the different steps. It's in a controller because you're posting the data, why send it to a model just to be stored in a session. You're already validating each step's data in each case in the switch, I think it makes the most sense to just set the session data right there.
[eluser]isaaccreative[/eluser]
I would put it in the Models directory. And use the Controller to instantiate it. At one point I was wondering the same question. I settled with using the following directory structure.
Models Directories -
models / db
models / object
models / form
models / emails
And then anything else... RSS, CURL, ect...
I know your Object is in relation to a form as oppose to a call from a database.... but in case anyone is wondering this is how I set up my objects with my database...
For every table in my database I usually create two files - an Object File & a DB Event File. The DB Event File extends CI Model Class and basically loads & sends Objects to my controllers.
Here's how I usually set-up a small CI Apps. FYI - I think my examples only work in PHP 5. :-)
Lets say we have a table in our database called "Articles". The fields are 'id', 'title', 'content', and 'author'.
1st - I would create an Article Object with the file name - "article_obj.php".
This file obviously goes in the models/object directory. The variables inside this class file are parallel with the Database Table.
i.e.
Code: <?php
class article_obj {
public $id;
public $title;
public $content;
public $author;
// This object only instantiated in a DB Event Class
public function __construct($row) {
parent::__construct($row);
$this->id = $row->id;
$this->title = $row->title;
$this->content = $row->content;
$this->author = $row->author;
}
}
?>
This class extends Model and is placed in the models/db directory.
Here's an example
Code: <?php
include_once("system/application/models/object/article_obj.php");
class article_model extends Model {
public function __construct() {
parent::Model();
$this->load->database();
}
public function load_by_id($id) {
$this->db->where('id',$id);
$query = $this->db->get('article');
return $this->load_article($query);
}
public function load_by_title($title) {
$this->db->where('title', $title);
$query = $this->db->get('article');
return $this->load_article($query);
}
// Return Single Article Object
private function load_article($query) {
$article="";
foreach($query->result() as $row) {
$article = new article_obj($row);
}
return $article;
}
}
?>
Now in the CONTROLLER all I have to do is load the "article_model" object and use any of the public methods to retrieve an article object. I then send the article object directory to my VIEW.
This process might seem a little too much for some cases... You could have easily just return the $row object to the Controller. However the main advantage here is that you can add additional methods, variables, and objects inside your Article Object.
For example you might want to throw in a User inside your Article Object. You can then add a User Object
and create public getter & setter methods to access the user object.
Or for some unknown reason you only want the first three characters of the title. You can create a method in your Article Object call Code: public function short_title() { }
Then later on you can modify that method and instantly update your entire site.
[eluser]Teks[/eluser]
Every now and then I have to deal with multi-page forms. The simplest, most straight-forward solution I've found, does not rely on sessions, nor involves messy temporary database storage.
We have to consider, that there are some common requirements in a multi-page form setup:
* the pages comprising the form are always intended to be used together, in order
* the user should not be able to access a page in the middle of the form directly, without going through the previous pages first
* the information should not be committed to permanent storage until the very last page of the form is completed and submitted
In order to satisfy all these requirements, I usually build a series of form pages, where the information from page 1 gets sent to page 2, and stored there as hidden fields in the new form. Once page 2 is completed, it sends all its information (including hidden fields) to page 3, which does the same. The process continues until you reach the last page, which finally commits the full data to storage.
Over the years, I've learnt from some very patient and knowledgeable coders, that if I find the 'multi-page' solution not sufficiently elegant, I can actually combine ALL of the pages into one single script (a single view file). Depending on the data actually received by the script (view) some fields are set to be 'hidden', while some selected others are displayed as actual input fields, with instructions. Using a well-designed controller in the back-end (with a simple switch statement, which determines which step the user is on) the process can be broken down into as many steps as necessary - all while retaining the simplicity of a single view, and a single controller, and NO messing around with sessions or databases.
I hope this helps.
[eluser]darkhouse[/eluser]
Teks, correct me if I'm wrong, but I think I see a major flaw with your method. If your form has say 3 pages, you have to validate your everything you send on the first page 3 times and everything you send on the send page twice. You can't just store the new data in hidden fields without validating it first, or you leave yourself open to security risks. So, if you're validating the same data over and over, now you've got redundant code, and quite frankly, I think a whole butt-load of hidden input fields to go from page to page is far more messy than just using a simple session variable.
Using a session, you do $this->session->set_userdata('member', array()); initially, then you validate the data on each page once and do $member = $this->session->userdata('member'); add all of your new data for that page, like $member['first_name'] = $this->input->post('first_name'); and so on, then do $this->session->set_userdata('member', $member); and $this->session->set_userdata('step', 2); . Of course, my example assumes you're using the new Form_validation library which rewrites the post data after successful validation.
The only drawback is that if the user takes too long, the session will time out and send them back to the beginning, but that normally means they abandoned the form anyways. Regardless, I still think this is the most logical and clean method.
[eluser]xwero[/eluser]
Teks solution is not that bad. If your public uses a-grade browsers you don't send anything to the server until the end page is reached. Validation will be taken care of by javascript when going through the pages and when you send it to the server it will be taken care of by php.
This method has one disadvantage : the uploads have to be on the end page because they need server validation.
If the browsers are various there is no other way than to have a temporary storage. One way to make sure the potential member doesn't need to restart after a session time out is to send a unique number that restores the already known information.
[eluser]Teks[/eluser]
@darkhouse: ok, let me see if I understand what you are seeing as the problem. I will use an example, to make it easier for me to visualise. Let's say, that you have a 3-step membership form. On the first page, you ask the user for a username/password. On the second page, you ask the user for a whole bunch of personal data (email, address, phone number, shirt size, etc.). Finally, on the last page, you show the user the terms and conditions of service for the site, which the user must agree to, before they can register.
Now, let's say that the way you are doing things behind the scenes is like this:
1) once the user submits their username and password in page 1, you already do a validity check (and data integrity check in the database - ie., "is the username unique?", "does this password comply with the security guidelines of the site?", etc.). If it is, you store the data in the cookie, and go to page 2.
2) proceed exactly as for page 1
3) if the user accepts the terms and conditions, retrieve the cookie data, and finally send it to the database (= to the model).
However, some time has passed since the user first filled out their username in page 1, and the time when they finally submit their acceptance in page 3 - ie., perhaps now another user has already registered with that username. This means, that always, as a last step, before you finally submit the data to the database, you should do your entire data validity and integrity check again - to ensure that all your data is still entirely valid, and try to guarantee your database integrity. This means, that you will have to do at least 2 checks: once, when the user is first submitting each part of the form, and a second time, when the data is being committed to the database.
This is really no different to the method I suggested.
The only difference between the 2 methods, is that as the data is being stored in the hidden fields - instead of inside a possibly encrypted cookie - it is more easily 'visible' to the user. This may make you feel, like you are opening up your form to be 'hacked', potentially allowing someone to 'skip' over one of our form validation steps, and entering the form directly on page 2 (or 3).
If that were to happen, then when the hacker finally submits the form on page 3, it will still have all its information validated anyway - remember, the last validation before submitting it to the database? - and any validation errors will be picked up then.
If I were dealing with highly confidential information - like credit card or bank account numbers - then I'd spend some time implementing the temporary database storage solution, coupled with a couple of custom encryption algorithms (simply because of the extra added security that the encryption can provide). But for most multi-page form applications, that level of security is hardly ever needed, and even using sessions can add a level of complexity that is often not needed - with problems (such as timeouts) that new programmers are often unfamiliar with.
Ultimately, my suggestion would be for people to choose a strategy that they are *comfortable* with. Consider, that *you* will be the one maintaining this code, so you should feel confident that you can change, update and evolve it, if needed. If there is a particular area of knowledge that you are an expert at - such as database, or sessions - then you may prefer to implement *those* techniques that are familiar and comfortable to you - and so you should! :-)
I hope this helps.
|
