Welcome Guest, Not a member yet? Register   Sign In
Model Philosophy
#1

[eluser]logan2z[/eluser]
I've come to CI from a Rails background so I have a pre-conceived notion of how models are used in an MVC framework. But CI seems to view models somewhat differently from Rails and I'm struggling a bit philosophically with the differences. In particular, I was expecting the CI model to be more OO in nature and provide a way to instantiate a Model object from form data a la Rails. CI, on the other hand, seems to view Models as simply a way to talk to the db and not really a way to encapsulate model data (someone correct me if I'm way off base here). Anyway, I decided to create my own BaseModel class that extends the CI Model class and provides a constructor that populates the model class's 'attributes' from form data. That seems to work reasonably well, but what it means is that I am handing model objects to my view from the controller, rather than extracting form data in the controller and making it available to the view. I haven't seen much CI code up to this point, but none of the examples I've seen in the docs ever seem to do this. Is doing this sort of thing against the spirit of CI, or is this a pretty common way of doing things in the CI world?
#2

[eluser]Michael Wales[/eluser]
You've pretty much hit all of the nails on the head. CodeIgniter merely views the Model as a means to communicate with a data source (whether that be a database, an XML file, whatever). This opens up a world of possibilities that simply isn't available in Rails and one of the things I love about CodeIgniter.

You, may love the encapsulation method and could extend the Model class to do so (as you've no doubt already begun). For me, I prefer to use my Models in a manner that is reminiscent of a static class.

Quote:rather than extracting form data in the controller and making it available to the view.
Maybe I am misunderstanding here or it's because I don't know what your application actually does, but the only time I can think it would be useful to extract form data within the controller and send that data to the view would be on a failed validation attempt (repopulating the form).

During normal CRUD operations, I personally would like as much data as possible to come from my Model so that I know it is properly validated (don't trust the users). Controller calls the Model to retrieve the data and then passes that data to the View (where it is formatted and displayed).
#3

[eluser]logan2z[/eluser]
Thanks for the quick reply, Michael. Glad to hear I'm not too far off base here.

[quote author="Michael Wales" date="1256332726"]
Quote:rather than extracting form data in the controller and making it available to the view.
Maybe I am misunderstanding here or it's because I don't know what your application actually does, but the only time I can think it would be useful to extract form data within the controller and send that data to the view would be on a failed validation attempt (repopulating the form).[/quote]

Sorry, I was unclear. Yes, failed form validation is the case I had in mind here.
#4

[eluser]BrianDHall[/eluser]
You might also note that the core philosophy of what a model can or should do remains the same. The big difference is in implementation - CI is 'lightweight' and 'unopinionated', so it doesn't assume population from form data or anything like that.

What you might be very interested in is Datamapper Overzealous Extension over in Ignited Code forum, especially with the array extension http://www.overzealous.com/dmz/pages/ext...array.html

You might have a user account creation model that is used like this:

Code:
// form posted to create a new account

$user = new User();
$user->from_array($_POST);

if ($user->save())
{
// account creation success!
}
else
{
#fail
}

Cool, huh? You define form validation in the Datamapper model in a way very similar to the CI form class, but you just do it once for each model so 10 forms can use the same data and you don't need any custom config files or lots of set_rule and all that nonsense.

The HTMLForm extension is pretty awesome too, but that's a different issue entirely.

Note that the above method is actually secure, because extra fields that don't correspond with the database get ignored. If you have fields you don't want set by a malicious user, the from_array() function has a $fields parameter where you can set only what fields you want taken from $_POST.
#5

[eluser]logan2z[/eluser]
Actually, another case that might benefit from passing a model directly to the view is for something like a form preview, that you often see in web-based forum software and other applications. So the form data is sent to the controller, the model object is constructed from the form, and then handed over to the view that renders the preview based on the model data. Of course you could construct the model, then decompose the model into data to pass to the view, but wouldn't just handing the model object over to the view make more sense in this situation?
#6

[eluser]GregX999[/eluser]
I too first "learned" MVC programming in Rails and found that Datamapper - Overzealous Edition has a strong Rails flavor to it.

I was on the fence at first - between taking the path of creating CI-style models, or using DataMapper to have models that map to database tables, and I finally decided to go the DataMapper way. Having "objects" (like users or products or posts) that have their own methods is just too useful to pass-up!

Plus, writing a ton of methods in a model to do custom CRUD tasks is a pain. Having that stuff "automated" is a much more enjoyable way for me to program.

Greg




Theme © iAndrew 2016 - Forum software by © MyBB