Putting the View back into MVC.

[eluser]wiredesignz[/eluser]

The URI is still just a way for the user to interact with the system.

What do you mean JUST a way. there is NO OTHER way to interact with web applications.

[eluser]zilverdistel[/eluser]
[quote author="wiredesignz" date="1205425244"]

The URI is still just a way for the user to interact with the system.

What do you mean JUST a way. there is NO OTHER way to interact with web applications. [/quote]

what I mean is that the design patterns like MVC can be used in any environment, not only in web applications, and does not say how to interact.

Maybe, just maybe (i'm speculating now), some artist might find a way to use MVC as a design pattern for his paintings for example ... I don't wanna go into this, might get too philosophical on this ;-).

[eluser]zilverdistel[/eluser]
I forgot where I found this, but I think it might be interesting to other people too, see attachment.

[eluser]xwero[/eluser]
That's a very clear diagram but that means the base model is the super object all others depend on where in CI the model is an addition to the super object so it would be taken apart and be reconstructed if you want a real MVC pattern?

[eluser]xwero[/eluser]
[quote author="wiredesignz" date="1205383488"]The strange thing to me is that most CI example code suggests collecting your model resultset in an array and passing this to your view. Not only does this place more demand on memory, but breaks the basic MVC principle of seperation of concerns.
[/quote]
Passing the resultset as an array is mainly because of php4 compatibility i guess. You can't loop through an object for instance.

[eluser]zilverdistel[/eluser]
[quote author="xwero" date="1205430949"]That's a very clear diagram but that means the base model is the super object all others depend on where in CI the model is an addition to the super object so it would be taken apart and be reconstructed if you want a real MVC pattern?[/quote]

I'm affraid I don't understand your question, could you reprase?

[eluser]xwero[/eluser]
The diagram states in the model "encapsulates application state". If i understand that sentence correctly the application starts with loading the model class and everything else gets added to the model, yes?

[eluser]zilverdistel[/eluser]
[quote author="xwero" date="1205433429"]The diagram states in the model "encapsulates application state". If i understand that sentence correctly the application starts with loading the model class and everything else gets added to the model, yes?[/quote]

No, I think you still can have as much models as you want. My interpretation of this sentence is that they refer to the value (or 'state' if you think of it as checkboxes eg) of the properties of the objects that determine your application.

An example: in a web-shop: the objects in the shopping cart determine the application state. So you create a model Shopping_cart, and you save the selected objects in it.

So in this diagram, the responsibility of the models is pretty huge. They ARE the application, in a way. The nice thing about this approach is that you can write a gui in GTK (eg) that interacts with these same model files. I never tried that, though. The responsibility of the views is to show the application state from a particular _view_point. Which point of view? That depends on what the user (trough the controller) asks the system to show him.

Now to get back from where this discussion started, it's the view that decides HOW to display, the controller only decides from which point of view. So yes, in my opinion, views need some intelligence too ...

VIEW = POINT OF VIEW

[eluser]dtrenz[/eluser]
Man, I am so confused now.

From everything I've read, it appears that one of the few concepts of MVC that is universally accepted is that MVC solves code/design problems that tend to arise as a result of too much coupling by separating data access, business logic, and presentation.

I guess I just assumed:

Model = data access
View = presentation
Controller = business logic

End of story.

But is sounds like my understanding of the meaning of business logic is wrong. I assumed business logic involved not only directing traffic between the model and view, but also massaging/preparing/staging data retrieved from the models before sending it to the views.

Are you all saying that all the controller should do is call model methods and load views, and that all data formatting or prep should be handled in the models as well as data access?

EXAMPLE:

What if you are on a user profile page on a website, and a truncated version of the users bio is displayed. By clicking a "read full bio" link, you are taken to the bio page where a NON-truncated version of the bio is displayed.

In this example, would you have 2 separate model methods for retrieving the bio text? One that returned the bio, truncated by some string truncate function, and another that returned the whole bio text?

I currently have one model for retrieving the bio, and then in the controller, I truncate (or not) before sending the bio text to the view.

Which is correct MVC? Either?

[eluser]Pygon[/eluser]
xwero: technically, yes, the model structure should encapsulate application state (note, currently most people are looking at "model" as a single component and not as a structure of components that accomplish tasks.

Essentially, the model is fairly dumb in the grand scheme of things -- it simply takes requests, makes changes, stores data and returns it upon request. The controller structure determines flow but isn't really responsible for handling data (should all be handled in the model structure) and selects a view appropriate to the change made. The view simply requests application state and displays it.

"Application state" is probably a bit confusing to you, since in our application our models start fresh with every page change, but this more means the current state of our application (ie. this model holds on to that there was this error while processing).

How's about a sudo example:

Code:

User:: Request insert comment
Controller:: access->hasAccess()
  ? continue
  : load->view('no_access','insert_comment') >> end
Controller:: validate->check()
  ? continue
  : error->setError(1) >> load->view('error_comment') >> end
Controller:: comment->insert()
  ? load->view('success_comment') >> end
  : error->setError(2) >> load->view('error_comment') >> end

View (error_insert):: error->getErrorType() >> lang->get(error) >> //Determine appropriate form and show it// >> end

View (success_insert):: lang->get('success') >> //Determine what should display and do it// >> end

In this example, the controller doesn't care what data changes, only whether it succeeded or failed. When it fails, it notifies the model structure that there was an error, then selects the view best suited to handle the results.

The view structure, based upon the view invoked and the data status (error or not), the view determines what should be displayed and how. The model doesn't care what is going to show up on the screen, and neither does the controller really (other than to let the view know the result of its action in the form of selecting a view).

This really isn't that far off from the way CI handles things. The difference is that most of the view structure and some of the model responsibilities are moved into the controller, and the view becomes essentially a template (due to the method of loading, although yes there are ways to work around it).