The MVC's model

[Tony Marston]

Actually it's this distinction which separates MVC from other architectures such as N-Tier. The controller acting as a mediator is not MVC. Push/pull certainly are implementation details but your argument here is a straw man.

I *DO* know the difference between MVC and N-Tier, as explained in FAQ26. Your use of the term "mediator" is a red herring. If I have three components which perform the responsibilities of Model, View and Controller as defined in the MVC design pattern, then that *IS* MVC whatever anyone says.

This is non sequitur. Nowhere did I say (or even imply) that MVC mentioned these details, only that it specifies the direction of data flow.

Then in fact we are in agreement.

Then you're putting display logic in the model.

No I'm not. Logic implies code which manipulates the variables to produce some result. The variables for offset, limit and order simly pass *THROUGH* the Model to be processed by the DAO, then sent back to View where they can be displayed to and altered by the user.

Well, is sorting or taking a subset manipulating? I'd argue not because it's read only.

The View does not sort the data as this has already been done by the DAO. The View does not extract a subset of the data from the Model, it deals with *ALL* the data currently contained in the Model.

As for highest page number in the model. The model should not have the concept of a page. It's display logic and should be irrelevant to the model.

The current/highest page numbers are not processed in any way in the Model, nor do they affect the processing of any business rules within the Model. They are simply variables which are passed down to the DAO and back up to the View.

Irrelevant implementation details. You don't have to use DAOs in MVC.

I don't have to, no, but I'm perfectly within my rights to do so.

Then whatever is setting said message on the model contains display logic.

Then your definition of "display logic" is seriously flawed. Identifying *what* needs to be displayed is totally different from building the actual display, which in a web page is the HTML document. The Model tells the View "please display this message" and the View generates the necessary HTML to perform that task.

If the Model generated any HTML then *that* would be "display logic".

[sunwukung]

You two wanna get a room?

Seriously - how is this debate helping the OP? You simply have to look at any framework (No, not your wunder-framework Mr.Marston) to look at the different implementations of "MVC".

[TomB]

If I have three components which perform the responsibilities of Model, View and Controller as defined in the MVC design pattern, then that *IS* MVC whatever anyone says.

Well that's a nice tautology but it's those responsibilities that are the issue here. If the controller is calling an action on the model and passing the result to the view it's not MVC. Perhaps mediator is too vague but in MVC the model is accessed by the view. If not it's by definition, n-tier rather than MVC. I don't even understand why this is even being questioned. MVC clearly dictates how data flows between the model view and controller. See your own diagram in the link you provided.

No I'm not. Logic implies code which manipulates the variables to produce some result. The variables for offset, limit and order simly pass *THROUGH* the Model to be processed by the DAO, then sent back to View where they can be displayed to and altered by the user.

Then your model needs to be set up in a specific way to work with the view. This is display logic. How many records to display? Display logic, how they should be sorted? Display detail which should be of no relevance to the model.

This inadvertently breaks the principles of MVC. The model essentially now *knows* it's part of paginated data and has to be set up in such a way to cater for that specific view (knowing the total number of pages, records per page, etc)

The View does not sort the data as this has already been done by the DAO. The View does not extract a subset of the data from the Model, it deals with *ALL* the data currently contained in the Model.

The current/highest page numbers are not processed in any way in the Model, nor do they affect the processing of any business rules within the Model. They are simply variables which are passed down to the DAO and back up to the View.

The fact that they're contained within the model is enough. You're setting up the model to work with the view, rather than having a view which works with (usually an existing) model. Different views will need different things. Another view may need different, yet relevant, data. It may not have need for "number of pages" or anything you have put in the there to cater for a specific view. The net result is large, unwieldy models which become hard to maintain.

I don't have to, no, but I'm perfectly within my rights to do so.

But it's way beyond the scope of this discussion.

Then your definition of "display logic" is seriously flawed. Identifying *what* needs to be displayed is totally different from building the actual display, which in a web page is the HTML document. The Model tells the View "please display this message" and the View generates the necessary HTML to perform that task.

If the Model generated any HTML then *that* would be "display logic".

Should the model:

-Decide which colour to make a background based on a record attribute (e.g. status code)
-Tell the view how to handle exceptional cases (no records to display)
-tell the view whether it should display an error message or the result set


Clearly this is all display logic (along with number of records, ordering, etc). If you put this in the model, you're coding your models around how they're going to be displayed instead of how they should behave and what data the contain. Your model is essentially telling the view what to do. You're giving your model control over the output. The model should not be concerned with how it could be presented. By putting things like "maximum number of pages" into the model you're doing exactly this and creating a very firm contract between a model and a view, severly reducing reusability. (any model now needs to fulfil this contract to use the view)

Lets put it this way: should the model decide which fields the view should be showing? it's the same issue. It's likely in your system, the model contains a record set. Sometimes you don't want to display all fields. Do you always want to show every field from a record? No you often want to only display some parts, even though the view could show them, it doesn't. Congratulations your view is already filtering the data it's receiving. It's no different taking a subset of data from a record set, than a subset of data from an individual record.

[TomB]

You two wanna get a room?

Seriously - how is this debate helping the OP?

I do think it's a legitimate discussion regarding different implementations. At least it's (somewhat) related to the original topic. We are discussing model implementations after all.

[Tony Marston]

Seriously - how is this debate helping the OP? You simply have to look at any framework (No, not your wunder-framework Mr.Marston) to look at the different implementations of "MVC".

So you agree with me that MVC can have many different implementations, and not just one? Then you must disagree with TomB who is saying that only *his* implementaton of MVC is the correct one.

[sunwukung]

I disagree with both of you. You more than him.

@Tom - I don't think you should issue data manipulation from the View, but you can interpret data there.

@Tony - we've discussed the role of the controller as a staging post for view variables elsewhere - and this is a facet of n-tier or two-step transform (which are not exclusive from MVC)

@both It's meaningless to validate our interpretations of MVC via the fact that it "works" in our own application design. An application can work, but still be riddled with anti-patterns. Anti-patterns don't break applications, they just make development trickier. Discovering an anti-pattern in our own work can take quite some time (and humility). It's a classic example of pattern-itis, theory getting in the way of practice. Tell me which of the main frameworks is practising the TRUE MVC (not that it matters, if the application works....oh the irony)

@Tony I think it's pedantic (unedifying) to be quibblling like this, which is *NOT* helped by this kind of text formatting (or multiple posts).

[TomB]

So you agree with me that MVC can have many different implementations, and not just one? Then you must disagree with TomB who is saying that only *his* implementaton of MVC is the correct one.

Where exactly did I say that? I even specifically tried to avoid discussing implementation details that weren't directly relevant.


If anything I said the opposite....

Well, the biggest issue is that MVC doesn't actually specify implementation details.

Except MVC is nothing to do with that and has no stipulation on how the data is accessed.

An interesting sub-topic is, should models have a state? (e.g. should they be working based around a specific User object which is stored as a property of the model) In my opinion, no, but it does make it easier in some cases.

the following is completely implementation details and not really relevant but I feel I should respond

The only thing I've been saying is correct is that MVC dictates data flow

How this is done is a point of discussion (push/pull) and an implementation detail. I will, of course, argue that my preferred way is better. But I've not said it's 'correct' and all others are 'wrong'. I have, however, provided my reasoning.

Do I need to start qualifying all my posts with "in my opinion..."?


Anyway, this has gone way too ad hominem for my liking. I'd rather get back to the actual topic.

[Tony Marston]

Well that's a nice tautology but it's those responsibilities that are the issue here. If the controller is calling an action on the model and passing the result to the view it's not MVC. Perhaps mediator is too vague but in MVC the model is accessed by the view. If not it's by definition, n-tier rather than MVC. I don't even understand why this is even being questioned. MVC clearly dictates how data flows between the model view and controller. See your own diagram in the link you provided.

I disagree. The MVC design pattern does not dictate the mechanics of how the data flows between each of the three components, it simply identifies the responsibilities of each of those components and leaves the actual mechanics, the implementation details, up to the individual programmer.

Then your model needs to be set up in a specific way to work with the view. This is display logic. How many records to display? Display logic, how they should be sorted? Display detail which should be of no relevance to the model.

You still do not understand what "display logic" actually means. In a web application this means the code which generates the HTML which is passed to the client's browser. If the Model does not generate any HTML then it does not contain any "display logic".

Look at the case where the instruction from the user is "give me 10 database rows starting at page 3". This is *NOT* data access logic. The page size and page number variables are just pieces of data which are captured in the View, passed to the Controller, through the Model to the DAO. It is *ONLY* when the DAO actually uses these variables to construct and execute an sql SELECT statement that there is any data access logic. "Logic" requires program code to process a variable, not simply to pass it down (or up) the chain of command.

This inadvertently breaks the principles of MVC. The model essentially now *knows* it's part of paginated data and has to be set up in such a way to cater for that specific view (knowing the total number of pages, records per page, etc)

That is just a bunch of data which is passing through, and in no way affects how the Model does its job. To the Model these are just variables which have no processing significance, so there is no "logic" attached to them.

The fact that they're contained within the model is enough. You're setting up the model to work with the view, rather than having a view which works with (usually an existing) model. Different views will need different things. Another view may need different, yet relevant, data. It may not have need for "number of pages" or anything you have put in the there to cater for a specific view. The net result is large, unwieldy models which become hard to maintain.

*Your* Model classes may be unwieldy and hard to maintain, but mine are not. Each one of my Model classes is capable of working with any View without modification. This is because each concrete table class inherits a large amount of code from an abstract table class.

Should the model:

-Decide which colour to make a background based on a record attribute (e.g. status code)
-Tell the view how to handle exceptional cases (no records to display)
-tell the view whether it should display an error message or the result set

The Model may attach a CSS class to a column name, but the specifications of that CSS class are held *outside* the Model (in a separate CSS file). The colour which is actually used in the View is therefore outside the control of the Model.

When it comes to record sets or error messages, the View does not decide which to display, it simply displays whatever it has been given by the Model. If it is given a record set, empty or otherwise, it displays that record set. If it is given one or more error messages, then it displays those messages. It does not decide what to display, simply how to display it.

Clearly this is all display logic (along with number of records, ordering, etc). If you put this in the model, you're coding your models around how they're going to be displayed instead of how they should behave and what data the contain. Your model is essentially telling the view what to do.

What's wrong with that? It is up to the Model to obtain data by whatever means necessary, and it is up to the View to display whatever data it has been given. Logic such as which colour is to be used in what circumstances comes under the heading "business rules" and therefore belongs in the Model. The Model makes decisions and the View implements those decisions.

You're giving your model control over the output. The model should not be concerned with how it could be presented. By putting things like "maximum number of pages" into the model you're doing exactly this and creating a very firm contract between a model and a view, severly reducing reusability. (any model now needs to fulfil this contract to use the view)

The Model obtains data from somewhere, applies business rules which may generate additional values, messages or colour suggestions, and passes them to the View. As such the Model *does* control what is displayed (that is its purpose after all), but it is the View which constructs the output, which could either be HTML or PDF.

Lets put it this way: should the model decide which fields the view should be showing? it's the same issue. It's likely in your system, the model contains a record set. Sometimes you don't want to display all fields. Do you always want to show every field from a record? No you often want to only display some parts, even though the view could show them, it doesn't. Congratulations your view is already filtering the data it's receiving. It's no different taking a subset of data from a record set, than a subset of data from an individual record.

While my View may only display a subset of the fields on each database row, it does not filter out any rows it has been given. Every row is processed in exactly the same way. Nor does it sort the rows it has been given as they were pe-sorted in the DAO.

If I wish to change the number of columns which are displayed, or the order in which they are displayed, then I can change the View and not have to touch the Model. This is as it should be.

[Tony Marston]

The only thing I've been saying is correct is that MVC dictates data flow

I disagree. To implement MVC you must have three components, each of which performs the responsibilities of either Model, View or Controller. How the data passed between those components, whether it is pushed or pulled, or who does the pushing and pulling, is not the issue - that is an implementation detail.

How this is done is a point of discussion (push/pull) and an implementation detail. I will, of course, argue that my preferred way is better. But I've not said it's 'correct' and all others are 'wrong'. I have, however, provided my reasoning.

How many times have you stated that "if its not done *this* way then it's not MVC"? I have always worked with a loose definition of MVC, and not one which tries to enforce a particular set of implementation details.

[TomB]

In a (potentially futile) attempt to simplify this discussion I'm going to reply to as few of your points as I feel necessary. If you feel I missed something important please tell me

I disagree. The MVC design pattern does not dictate the mechanics of how the data flows between each of the three components, it simply identifies the responsibilities of each of those components and leaves the actual mechanics, the implementation details, up to the individual programmer.

MVC clearly dictates that:
-Models should not know about the views or controllers
-Views have access to models
-Controllers can access models and views

Which looks like this:

(source: wikipedia)

You're explaining MVC as if it's this:

You still do not understand what "display logic" actually means. In a web application this means the code which generates the HTML which is passed to the client's browser. If the Model does not generate any HTML then it does not contain any "display logic".

This is not true. Display logic is anything related to, and only needed by presentation. This includes sorting and limiting. In your example the model is telling the view "Display these records" rather than the view asking the model for "these records for me to display". The difference is subtle but important. Your model needs to work out how many pages there are in total. This is something used entirely for display purposes. It is display logic, theres no need for it to be in your model.... and it needs to be in every model which uses the view rather than once, in the view.

That is just a bunch of data which is passing through, and in no way affects how the Model does its job. To the Model these are just variables which have no processing significance, so there is no "logic" attached to them.

It has to be in every model which uses the view. This is unarguably a cause of reduced reusability and clutter in the model. Imagine you have 100 views all with slightly different requirements, should they all have variables in the model which are used only by them?

What's wrong with that? It is up to the Model to obtain data by whatever means necessary, and it is up to the View to display whatever data it has been given. Logic such as which colour is to be used in what circumstances comes under the heading "business rules" and therefore belongs in the Model. The Model makes decisions and the View implements those decisions.

The model should be view agnostic. It should be able to work with any view/controller without modification.

While my View may only display a subset of the fields on each database row, it does not filter out any rows it has been given. Every row is processed in exactly the same way. Nor does it sort the rows it has been given as they were pe-sorted in the DAO.

But you're filtering out data here, there's no reason the view shouldn't be able to decide what it shows (it's the views job after all), regardless of whether it's a field or a record.

If I wish to change the number of columns which are displayed, or the order in which they are displayed, then I can change the View and not have to touch the Model. This is as it should be.

Nail/head. So changing the order of the fields is ok, but not the records. That's at best inconsistent.

Imho, the view should have total control over what it shows.

[arborint]

Honestly, this guy has been confusing people for years. I can really think on no one comparable. Legendary. He still doesn't seem to understand what those little arrows on all those diagrams mean. It is a shame that a someone that verbose gets some many things half-wrong.

TomB does have a lot of useful information for the OP, but they will have to wade through pages of other nonsense to find it.

[sunwukung]

Ah stuff this, I'm going back to spaghetti and tables

[AnthonySterling]

Off Topic:

Ah stuff this, I'm going back to spaghetti and tables

[webaddictz]

Ah stuff this, I'm going back to spaghetti and tables

Thanks for this, you already made my Friday!

Being serious though; I can only agree with arborint when he says there's no point in arguing further. It's clear that you disagree with each other (a lot) and you're now mostly confusing other people with this pointless discussion. Of course, it's not up to me, but if it was I'd say: let it go guys.

[Tony Marston]

MVC clearly dictates that:
-Models should not know about the views or controllers
-Views have access to models
-Controllers can access models and views

Which looks like this:

(source: wikipedia)

I'm afraid it is *YOU* who is inferring too much from the arrows in that diagram. The MVC pattern requires at least three components, the Model, the View and the Controller, each of which has its own specific responsibilities. The same data can flow between each of these components and is processed differently within each. *HOW* the data flows, whether it is pushed or pulled, or who does the pushing or pulling, is *NOT* specifed in the pattern. That is an implementation detail.

You're explaining MVC as if it's this:

No I'm not. There's no data flow in that diagram, so it simply won't work.

This is not true. Display logic is anything related to, and only needed by presentation. This includes sorting and limiting.

It is quite clear that you do not understand the difference between DATA and LOGIC.

DATA is just a collection of variables which may hold different values at different moments in time.

LOGIC is the program code which acts upon, manipulates or transforms that data in some way.

Thus in a web application the "display logic" is that code which transforms that data into HTML. The fact that some or all of that data has also passed through other components does *NOT* mean that those other components also contain "display logic". They share data, yes, but not logic.

In a database application the Model may use a separate Data Access Object (DAO) in order to communicate with the database. This is where the data is transformed into SQL, or where and SQL statement provides data.

So you see, the same data can pass through the Controller, the Model, the DAO and the View, but this does *NOT* mean that all the components share the same logic. The data access logic (program code) to transform the data to/from SQL exists *ONLY* in the DAO, not anywhere else. The display logic (program code) which transforms that data into HTML exists *ONLY* within the View, not anywhere else.

In your example the model is telling the view "Display these records" rather than the view asking the model for "these records for me to display". The difference is subtle but important.

Again you are inferring too much by the arrows in the diagram. The data flows from the Model to the View, but it does not matter whether that data is pushed by the Model or pulled by the View. The mechanics of how the flow is actually performed are irrelevant as they are an implementation detail.

Your model needs to work out how many pages there are in total. This is something used entirely for display purposes. It is display logic, theres no need for it to be in your model.... and it needs to be in every model which uses the view rather than once, in the view.

Wrong. The Model does not work out how many records or pages there are. These are variables which are determined immediately after the sql SELECT statement has been issued within the DAO. These variables are then passed through the Model to the View so that they can be displayed (or not) in some way. The fact that the DAO contains data that is transformed in the View most certanly does *NOT* mean that the DAO contains "display logic". It is data, not logic.

It has to be in every model which uses the view. This is unarguably a cause of reduced reusability and clutter in the model. Imagine you have 100 views all with slightly different requirements, should they all have variables in the model which are used only by them?

I do not tailor each of my table classes so that it only contains the variables which the current View actually needs. This "tailoring" would create an enormous programming overhead which I personally would find unacceptable. Instead each table class creates whatever variables are appropriate to the current operation, then it hands *ALL* those variables to the View for transformation into HTML. How the View deals with those variables is of no concern to the Model.

The model should be view agnostic. It should be able to work with any view/controller without modification.

If you bothered to read what I wrote you will see that I have already achieved that within my framework. Any table class (Model) can be used, without modfication, by any Controller and any View.

But you're filtering out data here, there's no reason the view shouldn't be able to decide what it shows (it's the views job after all), regardless of whether it's a field or a record.

I disagree. It is not the View's responsibility to filter out records, or to sort those records into a particular order. After the records are transferred from the Model to the View it is the View's repsonsibility to display all of those records in the order in which they were given.

Nail/head. So changing the order of the fields is ok, but not the records. That's at best inconsistent.

Not in my opinion. It is far more efficient, and requires less code, to have the data sorted within the sql SELECT statement. The fields may come from the database in a totally random order, but the View can position each of those fields wherever it likes. I don't have to change the sql statement in order to change the order of fields on the screen.

Imho, the view should have total control over what it shows.

This control should be limited to where and how each field is displayed, but *NOT* which records should or should not be displayed, or the order in which they are displayed. The choice of which records to display, and their order, has already been determined by the Model/DAO.

[Tony Marston]

Honestly, this guy has been confusing people for years.

By "confusing" I assume you mean that I have been putting forward a different, but perfectly valid, opinion.

He still doesn't seem to understand what those little arrows on all those diagrams mean.

It means that data flows in the direction of the arrow, but it does *NOT* dictate whether the data is pushed or pulled, or who does the pushing or the pulling.

It is a shame that a someone that verbose gets some many things half-wrong.

That implies that half the things I say are right. Can I quote you on that?

[TomB]

No I'm not. There's no data flow in that diagram, so it simply won't work.

The MVC design pattern does not dictate the mechanics of how the data flows between each of the three components

The MVC pattern merely defines *WHAT* nust be done in each of the three components, not *HOW* it must be done. The HOW also includes how data flows between the various components.

Your views on data flow in MVC are contradictory and confusing. You seem to say MVC doesn't specify data flow but now you're saying that without data flow MVC wont work. You were essentially saying "put the arrows anywhere, it's still MVC"

So you see, the same data can pass through the Controller, the Model, the DAO and the View, but this does *NOT* mean that all the components share the same logic. The data access logic (program code) to transform the data to/from SQL exists *ONLY* in the DAO, not anywhere else. The display logic (program code) which transforms that data into HTML exists *ONLY* within the View, not anywhere else.

Ok you have data related to one specific view in a model that can be used by any number of different views Data that's not needed by the model in the model? Not right (and you do have display logic as you need to work out the total number of pages...)

Again you are inferring too much by the arrows in the diagram. The data flows from the Model to the View, but it does not matter whether that data is pushed by the Model or pulled by the View. The mechanics of how the flow is actually performed are irrelevant as they are an implementation detail.

This is yet another straw man argument. As I've said all along (at least 3 times I believe). Push/pull is an implementation detail. What you're arguing (the arrows can go anywhere, and that MVC doesn't specify which components communicate) is a separate issue, you cant seem to see this distinction.

Wrong. The Model does not work out how many records or pages there are. These are variables which are determined immediately after the sql SELECT statement has been issued within the DAO. These variables are then passed through the Model to the View so that they can be displayed (or not) in some way. The fact that the DAO contains data that is transformed in the View most certanly does *NOT* mean that the DAO contains "display logic". It is data, not logic.

The DAO is part of the model layer. You have display logic in your model (layer). You need to work out how many pages there are in total for the sole purpose of putting "page X of Y" in the view.

This control should be limited to where and how each field is displayed, but *NOT* which records should or should not be displayed, or the order in which they are displayed. The choice of which records to display, and their order, has already been determined by the Model/DAO.

Which is some nice display logic in your model (or DAO, which by the way, is part of the model).

I'm going to follow webaddictz's advice. I'm not going to reply again in regards to the whole display logic in model thing is definitely an implementation detail and I don't really think it's useful to anyone now that we're going around in circles. Especially since I've provided reasoning (ie drawbacks in your method) and all you're doing is arguing seemingly irrelevant details (logic/data) and not back up your argument with actual reasoning (e.g. the benefits a model which contains variables that are required by a single view) and mixing two different issues into a single argument, which is not helping anyone, yourself included.

[auricle]

In a (potentially futile) attempt to simplify this discussion I'm going to reply to as few of your points as I feel necessary. If you feel I missed something important please tell me

I'd like to Marston being that polite, even if he never reaches agreement with anyone.

[sunwukung]

emphasizing *ALL* of your *KEY* points like *THIS* is perhaps not helping

[webaddictz]

Guys. Let's keep it calm, okay? There is no point whatsoever in continuing this way, and it doesn't do much good to the overall feel on this forum. Let's be gents.

[Tony Marston]

I'd like to Marston being that polite, even if he never reaches agreement with anyone.

When have I ever been impolite? Insistent yes, but never impolite.

[Tony Marston]

Your views on data flow in MVC are contradictory and confusing. You seem to say MVC doesn't specify data flow but now you're saying that without data flow MVC wont work. You were essentially saying "put the arrows anywhere, it's still MVC"

I never said that MVC does not specify data flow, what I did say is that the mechanics of that data flow - who does the pushing and who does the pulling - is an implementation detail which is not specified in the pattern. The data has to flow between the various components so that each one can do its work, but how the flow is implemented is unimportant.

Ok you have data related to one specific view in a model that can be used by any number of different views Data that's not needed by the model in the model? Not right (and you do have display logic as you need to work out the total number of pages...)

I repeat (for the umpteenth time) that display logic is the program code which generates the HTML output, not the data which may be incorporated into the HTML output. There is absolutely no HTML code generated within the Model or DAO, so there is no display logic in the Model or DAO. Having a piece of data in the Model or DAO which is passed to the View so that it can be incorporated into the HTML output is not the same as "display logic". Logic is code, not data.

If the Model contains any data which is passed to the View and incorporated into the HTML output, are you saying that this data is "display logic"? What if this data is obtained from the database? Is this data also "display logic"? If you think about that for a moment who should see the error in your argument. Logic is code, data is not code, therefore data is not logic.

You may think that it's wrong to generate variables in the Model that are not used in the Model, but which are passed to the View, but where does that rule exist in the definition of MVC?

This is yet another straw man argument. As I've said all along (at least 3 times I believe). Push/pull is an implementation detail. What you're arguing (the arrows can go anywhere, and that MVC doesn't specify which components communicate) is a separate issue, you cant seem to see this distinction.

I agree, push/pull is an implementation detail. Which component does the pushing and which does the pulling is also an implementation detail. The only "requirement" in MVC is that the data flows (somehow) into the right component so that it can be dealt with by that component. You seem to want a definition which is more restrictive than this, and my argument is that I am not prepared to go along with your artificial restrictions.

The DAO is part of the model layer. You have display logic in your model (layer). You need to work out how many pages there are in total for the sole purpose of putting "page X of Y" in the view.

The Model does not generate any HTML output, therefore there is no dsplay logic in the Model. Logic is not data, it is the program code which operates on that data.

... we're going around in circles. Especially since I've provided reasoning (ie drawbacks in your method)

They were not drawbacks (ie. errors) in my methods. You were stating that my approach is wrong simply because it is different from yours.

and all you're doing is arguing seemingly irrelevant details (logic/data) and not back up your argument with actual reasoning

You keep telling me that my Model contains display logic when it most certainly does not. Logic is code, not data. "Display logic" is that code which generates the HTML output. There is no code in my Model which generates HTML output, therefore there is no display logic in my Model. There is data which is passed to the View so that it can be incorporated into the HTML output, but it is a fundamental requirement of MVC that data flows between the Model and the View so that each component may operate on that data in order to carry out its designated responsibilities. The Model obtains data by unspecified means, then passes that data to the View where it is transformed into HTML.

(e.g. the benefits a model which contains variables that are required by a single view)

Now you are contradicting yourself. You stated previously (and I agree) that a Model should be able to be used with any View. This implies that the Model should be able to feed any View with the variables that it may need. If a Model needs to be coded so that it only contains variables that are required by a single view then you are creating an artificial restriction. In your own words "the Model should not be aware of the View" which implies that the Model should not need to know the precise list of variables that are required by the current View. The Model supplies the View with all the data it's got, and it's up to the View what it does with that data. This approach allows changes to be made to the View without having to change the Model.

[arborint]

I just want to clarify for anyone trying to separate the wheat from the chaff in this thread that diagrams like this (http://martinfowler.com/eaaCatalog/m...ontroller.html) are UML Class diagrams -- not Data Flow diagrams.

[TomB]

*sigh* I know I said I wouldn't but I'll bite.

There are 2 issues here:
-The definition of MVC
-Model content

I'll address the first one first. You keep saying things like:

You could even have the Controller "pull" from the Model and "push" to the View, but who cares? That the data flows is important, but the actual mechanics are an implementation detail.

Which is not mvc. In MVC the view interacts with the model directly. Now you're changing your position.

I repeat (for the umpteenth time) that display logic is the program code which generates the HTML output, not the data which may be incorporated into the HTML output. There is absolutely no HTML code generated within the Model or DAO, so there is no display logic in the Model or DAO. Having a piece of data in the Model or DAO which is passed to the View so that it can be incorporated into the HTML output is not the same as "display logic". Logic is code, not data.

If the Model contains any data which is passed to the View and incorporated into the HTML output, are you saying that this data is "display logic"? What if this data is obtained from the database? Is this data also "display logic"? If you think about that for a moment who should see the error in your argument. Logic is code, data is not code, therefore data is not logic.

Consider this:

You have pagination nowhere in your system so you create a view for it. You should be able to implement it with any model without changing the model definition. In your system (and no, this isn't an invitation for you to talk about your own framework again) you have to change the model (and before you say it: base class or not, it's irrelevant) so that it contains the relevant methods (in this case adding a method to get the total number of available pages) for the view you've just added. Is this adding logic? Yes. Is this display logic? Yes. You just added it for the sole purpose of making a view work and your view cannot work without it. This is by definition display logic. Now Tony, I know what you're like, you're going to say, in a very cleverly worded way something along the lines of "my own framework already supports pagination so it doesn't matter". It does. Who knows what views you will need in the future and there's certainly no way to know what they might need to know about the model!

Your definition of "Display logic" is flawed. It doesn't have to be used to return an output to be "display logic" if it's used only by those functions which generate the output it's still display logic, you've just abstracted it slightly.

You may think that it's wrong to generate variables in the Model that are not used in the Model, but which are passed to the View, but where does that rule exist in the definition of MVC?

I do (in most cases) think it's wrong, but nowhere did I say this was anything to do with MVC or was defined in MVC. In fact I explicitly stated that in my first post on the subject:

the following is completely implementation details and not really relevant but I feel I should respond

I am not prepared to go along with your artificial restrictions.

I have suggested nothing about MVC other than the established principles.
I have said nothing more than:
-The model has no awareness of the view (although we already know you don't like this fact) or controller
-The view has access directly to the model
-The controller accesses both the model and the view

Point me to a whitepaper (or otherwise adequate source.) which says anything else.

I have said nothing else in regard to MVC. The fact that you can't see past the obvious flaws in a model knowing how it needs to be displayed is simply not my problem. This is MVC, they are not 'artificial restrictions' it's how MVC works.

Now you are contradicting yourself. You stated previously (and I agree) that a Model should be able to be used with any View. This implies that the Model should be able to feed any View with the variables that it may need. If a Model needs to be coded so that it only contains variables that are required by a single view then you are creating an artificial restriction. In your own words "the Model should not be aware of the View" which implies that the Model should not need to know the precise list of variables that are required by the current View. The Model supplies the View with all the data it's got, and it's up to the View what it does with that data. This approach allows changes to be made to the View without having to change the Model.

How did I contradict myself? The model should be able to use any view. The difference is, you're coding your models to cater for your views. You need to cater the view to fit the model.

[PCSpectra]

Just out of curiosity, using psuedo-code can someone show me what and how the view would have direct access to the models? Are you injecting the model into the view or is the model a concrete dependency of the view class? Would this not mean you would need a View class for almost every model? How do you query the model within the view, if the model requires GPC, SESSION or SERVER variables? Do you pass those variables into the View via it's API or do you access those directly from within the View?

Cheers,
Alex