Where to put a new object?

[eluser]Nicholas Bello[/eluser]
Hello CI fans,

I've perused the forums and done some googling but i can't seem to get a clear answer on this so here it is.

I am writing my first major CI application and it involves a member database! With that comes the need to add a member to the member database. The member has a boat load of information associated with them so the form will be divided into 5 pages (I know... 5).

Now I want to make a member object that stores all the member information such as name, birthday, address, etc. Then access it throughout the five pages by serializing it and passing it in the session.

Now where do i put my object? It's not a controller because it does not load a page, it's not a model because it does not deal with databases, and it is damn sure not a view. In keeping with the CI spirit where is the best place to put my object? Any help is greatly appreciated.

-Nick

[eluser]johnwbaxter[/eluser]
Controllers don't have to load pages. I'd put it in the controller.

I made a little app that accessed a db and spewed out a load of files and i did it all in the model apart from $this->load->model(app); $this->app->run(); which i put in the controller.

CI really doesn't stop you doing it however you want.

[eluser]majidmx[/eluser]
Hi,
I'd say you can put it in a controller, and in each step save it in user's session and the next step, fetch information and append the new information to it and replace it with previous one.
It's not the best way though.
I'd like to hear the other people's ideas about this too.

Take care,

[eluser]NogDog[/eluser]
I'd probably make it a model. There's is no restriction that forces a model to interface directly with the database, while it certainly sounds like a model: it is modeling a "member", after all. (Personally, I'd probably design it such that it does, in fact, interface with the DB since at some point you need to insert the member into the DB and will want to retrieve it, update, and or delete it from the DB eventually, too.)

[eluser]majidmx[/eluser]
Yeah Model would be the best place,
but as there are several steps, where do you suggest to save the data in each step ? session ?

[eluser]NogDog[/eluser]
My normal inclination would be to save the object to the session data, but I'm not enough of a CI expert (yet) to know what side-effects and/or "gotchas" that might entail.

Another alternative might be to create a separate DB table for "in progress" member definitions. It would basically be a clone of the members table except most/all of the fields would allow nulls (since you would not have data for all of them until the last step). You could have a "Member_model" class for normal use that includes methods for inserting/selecting/updating from the DB. Then you could have a "In_progress_member_model" that simply extends the Member_model with the only difference being the database table it uses (which would be a class variable).

But it's 3:00am here now, so take all the above with a grain of salt. ;-)

[eluser]majidmx[/eluser]
It is 3:00 AM here too
I would save the information incrementally in Database.

[eluser]Nicholas Bello[/eluser]
Thanks everyone for the responses. You make some interesting points. So if i'm understanding this correctly I should set my object up as a model and access it that way. Also when doing an incremental registration I should store the information in the database for each step.

That about summarize it?

One more thing, If i save to the database for each step, but then someone wants to go back a step, I would have to check the database each time the page is displayed to see if there is data in the DB for the specific member ID they are signing up as. Won't that tax the database?

(i.e.) Joe signs up on step one -> he goes into database and is assigned an ID -> The ID is assigned to the session -> He goes to step two where the ID is pulled from the session and checked against the database.

I think that's how it's supposed to work. It's early yet so my brain is not quite functioning but let me know if i'm way off base here.

Thanks,
Nick

[eluser]NogDog[/eluser]
[quote author="ignited" date="1231011190"]Thanks everyone for the responses. You make some interesting points. So if i'm understanding this correctly I should set my object up as a model and access it that way. Also when doing an incremental registration I should store the information in the database for each step.

That about summarize it?
[/quote]
"Should" might be a bit strong. Something like "could" or "a viable option" might be better. ;-)

One more thing, If i save to the database for each step, but then someone wants to go back a step, I would have to check the database each time the page is displayed to see if there is data in the DB for the specific member ID they are signing up as. Won't that tax the database?...

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.

[eluser]a.g.r.c[/eluser]
You could have a field in the shadow member table called something like stage_last_updated, and if they exit on say page 3 (record tand the last details you got from them was page 2 (record '2' in the DB). Then when the member comes back to the site and click retrieve partial form completion you could show them how much they have filled out.

A friend was just saying the other day how he hates multi part forms and he closes the window by mistake or the laptop powers down.

This could be a really cool robust script to keep for the future.

Maybe a plugin?