MVC in codeigniter

[eluser]pstp[/eluser]
Hey Everyone!!!

So, I got a lil bit confuse when reading all materials about MVC.
From Wikipedia, common MVC is like this pic:

FIRST_PIC

is there any different with MVC in codeigniter? 'Cause I got one more pic, like this:

SECOND_PIC

->first pic mean view can access model
->second pic means only controller can access the model, and view can't access the model

so, which one is codeigniter's? from wikipedia which is common mvc, or the special one which is view can't be allowed to access model??
#confused
:roll:

[eluser]WanWizard[/eluser]
Technically there is no reason why your view wouldn't be able to access models directly.
The CI way however is described in the second picture.

The Controller gets the request and processes it. It retrieves data from models, passes them on to views, which get send back to the requester.

[eluser]pstp[/eluser]
Maybe because people in design hates to code and to connect with the database, that's why the view shouldn't access models directly.
I mean if view access models directly, it wouldn't be mvc, it must be mv, without controller mirk:

[eluser]WanWizard[/eluser]
And most developers hate it that designers mess with their code. Or create a code dependency (and a possible maintenance nightmare) by using PHP in a view.

It's the main reason that some use template engines (like Smarty or Dwoo) so that no PHP can be used in views, and the applications business logic is unreachable by the frontend designer.

[eluser]tz2001[/eluser]
I just found this topic while searching for MVC related tutorials.

From what I understand, In MVC the views access the model directly. The approach taken by CI (and most of the other big frameworks) is closer to MVP. I also found an interesting article which addresses this exact issue: http://r.je/views-are-not-templates.html

So I guess my question is what is the reasoning behind codeigniter working in this way?

[eluser]WanWizard[/eluser]
The theory is all very nice.

Given my statement before, implementing strict MVC just adds another layer of complexity. Instead of having logic in models and controllers, you now have it in views to. And to maintain logic and presentation separation, you have to add another layer (a template?) which you call from the view to present the actual data retrieved by the view. How? Exactly the same as you now do it in the controller: by assigning them to variables which can be passed on to the template.

For a web based application, it doesn't make much sense to strictly follow the MVC paradigm, it only adds complexity. Part 2 of that article described exactly that. Then the article continues with describing a solution to the problem they've just created. They call it 'view helpers', which will contain the business logic. Yet another layer of complexity. You have a model that contains your data manipulation logic. Why repeat this functionality in a 'view helper'? What does it solve? Where first the view was dependent on the model, it's now on the view helper. Nothing solved.

Then you have the problem of shielding front end designers (those in this article responsible for templates) from application code. This article suggests you do that by only making the helpers available that they should be able to access. How? Exactly how you now assign variables to views!

My conclusion: a lot of added complexity, that doesn't solve anything, except the fact that you can now say you're following more truely the MVC pattern. At an imho unacceptable cost.

[eluser]tz2001[/eluser]
Thanks for your reply

Heh, I only read part 1 that's already stretching my knowledge on the topic quite a bit!

I think in the second article they're suggesting that display logic can be reusable and that the "helpers" allow any model to be used by any view. Which sounds good I suppose but I'm unsure if this really adds anything useful. It seems like they've created about 40 lines of code to save repeating 4. I guess if you're saving yourself repeating it more than 10 times it's a net gain? Does seems a bit overkill though.

I think a lot of the complaints about binding logic affecting maintainability are valid, though I'm not sure the suggested solution is really an improvement.

[eluser]WanWizard[/eluser]
First of all, I still have to see the first really truely reusable view. It means not only all data, but also all literals must be variable. More complexity.

Secondly, the only reason a helper can use any model, is that there is code higher in the hierachy that tells the view which model to use. You have to define it somewhere, a view is not clairvoyant.

Imho they just move the problem, so indeed, a lot of extra complexity without any benefit. The advantage of CI for me is the simplicity, and the speed in which you can develop applications. For me, a lot more relevant than semantics...