MVCP - MVC missing a layer?

[Selkirk]

But what is a page? According to Fowler, "more strictly, the controllers tie into each action, which may be clicking a link or a button." That would make a Page controller an event handler.

Is there a difference between a Page Controller and a command, except that the Page Controller looks like a page when seen from a user's point of view? If so, what is that difference?

I think thats the key idea. The page is a user-oriented idea. Here is what microsoft has to say about this:

Use the Page Controller pattern to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page. Separate the dispatching logic from any view-related code

Does it matter if your url is:

http://localhost/front.php?page=articlelist

or

http://localhost/article/list.php

The fact that a front controller is used does not eliminate the idea of a page as an important concept.

The need for shotgun surgery to add a field is a downside of MVC and especially the typical layered architecture:

Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.

So this says that if you separate your business and presentation logic, then there are going to be some changes that you have to make in two places. Wow, that sounds so obvious when you actually say it.

[Selkirk]

The sentence 'the controllers tie into each action' is important here. Try to forget about 'Actions' as you know them in Struts, that's just confusing terminology if you ask me.

Struts is a tragedy of naming. They prefixed almost every class with the word action I am surprised they don't have an ActionBoolean class.

Actions are the individual tasks that a user can perform using your application: add news, edit news, add a user, view a list of recent news, etc..

I think a page (and thus page controller) can be responsible for multiple actions.

Going back to the idea of half-requests with commands and views. Perhaps its better to say a page is what links commands and views.

The difference between a framework with PageControllers and a framework with one FrontController and Actions (Struts, Mojavi) is that PageControllers are part of the presentation layer of an application (= V + C) while Actions are part of the model layer of an application.

I disagree. The struts people consider their actions to be within the controller portion of MVC and they recommend that each action create a "business delegate" which handles the domain logic for the action. I don't think page controllers are part of the presentation layer.

The Actions execute logic without making any presentation layer-specific decisions such as returning a View, domain logic. The FrontController than examines some status code returned by this Action and then chooses an appropriate View.

In struts, it is the ActionMapping class and the action class that handles this view selection. Not the front controller. Well, actually, they would consider the ActionMapping class to be a part of the Front Controller. I don't. I consider it to be the "hidden" page controller.

The problem with PHP MVC frameworks like Mojavi is that there Actions in that framework are a combination of presentation layer specific logic (such as form validation) and domain logic. This leads to confusion as to where to place certain behaviour.

I think this is true. I like the separation between views and actions. One thing that is interesting is that the frameworks that don't have explicit separate View classes is that the users tend to divide their actions into "command" actions and "view" actions to enforce this separation. I think Jason (sweatje) does this in his MVC article.

[dagfinn]

Does it matter if your url is:

http://localhost/front.php?page=articlelist

or

http://localhost/article/list.php

Well, I would do:

http://localhost/front.php?command=articlelist

The difference being that a command represents the user's intention, while a page (as I understand it intuitively) is what appears in the browser afterwards.

In this particular case, the practical result is the same, but if the URL is representing an HTTP request from a form, it's different. Imagine a form with method="GET" just to simplify the example. The form might generate this URL:

http://localhost/front.php?command=submitArticle&title=MVC&text=Blah%20blah

Now the action is submitArticle, but the page that comes up may be the article list. The user's intention is not to view a page, but to save the data in the form.

[HarryF]

Just throwing in a curveball, prompted partly by Nativemind reminding me of my first experiences with PHP, using PHP itself as the "framework" and partly because it's raised it's head in WACT.

One thing that's always struck me about me about web applications is what seems to be the first leaky abstraction - links - that <a/> anchor tag and I've yet to find anything that really deals with this. Even with native, "tag-soup" PHP, if you change the name of a script acting as a controller, you may have to make multiple modifications to your HTML to point links at the right location. And it may not only be the HTML which ends up being rendered as a result of the renamed controller - there may be many, more or less unrelated, pages of HTML to modify. Yet everyone keeps on embedding them busily embeds them into their templates... Ignoring discussions of what goes in which layer for a moment, it basically sucks having to make tons of changes like this when you rename a single file.

In a GUI, there the "links" in the interface do not typically point directly at a controller - a menu or a button will emit an event can be diverted to the correct controller.

Perhaps the real advantage of MVC frameworks like struts is that they do encourage you to use a structure for URLs to determine actions, so you at least have to be consistent in how you use links. This gives you at least some chance to store the address a set of links point at in a single location, making them easy to change later. At the same time, with an environment like PHP, you feel the loss of flexibility. More broadly, web "applications" tend to be "bigger" than desktop applications in the sense that a given website may be comprised of many applications doing very different things (e.g. Sitepoint with a CMS + a discussion forum) but still needing some ability to communicate (how do you think those blogs are getting written ).

The leakiness of links even turns up in Sun's Petstore application. Here's an broken online demo of the petstore (has anyone noticed how hard it is to find online demos of the Petstore?).

Here's the JSP file IncludeQuickHeader.jsp

<center>
<html:link page="/shop/viewCategory.do?categoryId=FISH">
<img border="0" src="../images/sm_fish.gif" /></html:link>
<img border="0" src="../images/separator.gif" />
<html:link page="/shop/viewCategory.do?categoryId=DOGS">
<img border="0" src="../images/sm_dogs.gif" /></html:link>
<img border="0" src="../images/separator.gif" />
<html:link page="/shop/viewCategory.do?categoryId=REPTILES">
<img border="0" src="../images/sm_reptiles.gif" /></html:link>
<img border="0" src="../images/separator.gif" />
<html:link page="/shop/viewCategory.do?categoryId=CATS">
<img border="0" src="../images/sm_cats.gif" /></html:link>
<img border="0" src="../images/separator.gif" />
<html:link page="/shop/viewCategory.do?categoryId=BIRDS">
<img border="0" src="../images/sm_birds.gif" /></html:link>
</center>

This is what generates the FISH | DOGS | REPTILES | CATS | BIRDS links just below the header (above the Parrots head).

The first problem, as I see it, here is the "?categoryID=DOGS" points directly at a value in the database but that's kind of specific to the Petstore app.

Perhaps more important is the question of whether you page designers should be making the decision that to view any category, the application developer will use "viewCategory.do" to handle it. Rename the viewCategory.do handler and you'll need to change this template (plus others).

If, instead, we make a tag for links in a template something more abstract like;

<action name="ViewCategory" value="DOGS">
    <img border="0" src="../images/sm_dogs.gif" />
</action>

It's something a little more disconnected from URLs. With the right template engine, the <action /> get's converted to an HTML anchor tag, the actual URL is worked out by the underlying framework and (hopefully) a change to the name of the controller PHP script can be reflected automatically in the output generated from the <action /> tag.

[dagfinn]

Perhaps the real advantage of MVC frameworks like struts is that they do encourage you to use a structure for URLs to determine actions, so you at least have to be consistent in how you use links.

I think you've hit the nail on the head here. I was just thinking that the problem with all the Web presentation patterns like Front Controller and Page Controller--no, make that one of the problems--is that they miss the point. The real difficulty lies hidden in the details of the communication in the HTTP request--the communication channel between View and Controller. It needs to be treated with more precision.

[dagfinn]

I think a page (and thus page controller) can be responsible for multiple actions.

Going back to the idea of half-requests with commands and views. Perhaps its better to say a page is what links commands and views.

I've revived this thread again because I'm trying to figure out how to define the concepts. So I'm asking the question one more time: what is a "page"? This quote is the closest thing to a definition I can find. But then I wonder: Is there a one-to-one correspondence between a page and a View? If not, when is there not a one-to-one correspondence?

[lastcraft]

Hi...

Is there a one-to-one correspondence between a page and a View? If not, when is there not a one-to-one correspondence?

Here are all the awkward cases I can think of in no particular order...
1) Same content, but choice of Mozilla optimised page or IE optimised page (view chosen by browser not user).
2) Same content as HTML or PDF (view mode chosen by user).
3) Embedded content of page different, e.g. RealPlayer or Quicktime for embedded video.
4) Frames.
5) Composite pages such as RSS aggregators or side by side comparisons.
6) Embedded flash application or Java applet.
7) Decoration views such as a content borders and menus.
8) Pop up windows.
9) Delayed redirects and automatic timed refreshes (blog roll).
10) Different stylesheet for printing.
11) Page that adapts to previous visits.

The first three are really view modifers, I just put them there for completeness.

yours, Marcus

[Widow Maker]

Jolly good show, ... Old chap

[McGruff]

And, if client pages are built in blocks (header, footer, sidebar, etc), the one-model-to-many-views relationship becomes one-sub-model-to-many-sub-views.

[dagfinn]

Here are all the awkward cases I can think of in no particular order...

I'm thinking I must have been temporarily braindead not to have thought of some of those. But it's interesting they're all "awkward".

So now I'm wondering when a View is a different View. Where exactly is the dividing line between variations on one View and two different Views? At the point where you make separate mechanics for each? In the form of, say, different templates or different controlling classes?

[dagfinn]

More precisely, perhaps, nearly all your examples seem to be composite Views, so there might still be a one-to-one correspondence between the composite View and the page. But, if I understand correctly, 10) seems to be something else, two different layouts for the same page, in which case my previous question is relevant. I hope I'm making sense here.

[Widow Maker]

Yep. Sort of

According to M Fowler, wouldn't this be the 2 Step View pattern ? I think that what's it's called, but not that far off though

Reading with interest - please continue folks

[dagfinn]

Yep. Sort of
According to M Fowler, wouldn't this be the 2 Step View pattern ?

I've never actually used it, but I think a 2 Step View would be one way of implementing alternative appearances. Not just for one page, but for an entire application or site. So it's related.

[lastcraft]

Hi...

More precisely, perhaps, nearly all your examples seem to be composite Views, so there might still be a one-to-one correspondence between the composite View and the page. But, if I understand correctly, 10) seems to be something else, two different layouts for the same page, in which case my previous question is relevant. I hope I'm making sense here.

I just don't have any answers on this of course . How about if we avoid "view" for a moment? The nastiest example seems to be frames and composite views so I'll randomly poke around here for a sec...

If you have a menu frame that you click on to pull a framed subpage then all of these phrases are still pretty clear: template, server request, action, action handler. The menu click sends a request which becomes an action that is picked up by the action handler that either hands off to a more passive display handler or populates a template itself. Both the page and view words defeat me here . I would like to call the whole ensemble a "view" as this would fit with MVC in desktop applications, but web MVC seems to be rather different by convention.

If we were to unframe this arrangement into a single page where the composite is assembled server side, things get a little easier. Here the whole ensemble (view) is rebuilt on the request. This means that the action must know from which ensemble it belongs so that the whole ensemble can be repainted. Here the dual notions of MVC are being forced together somewhat by this more primitive set up. Something of a shotgun wedding.

I am getting stuck for names that haven't already been used somewhere else. The old OpenDoc system used the name "part" for the pieces of a composite view. This word fits both the framed version and the single page version of my imaginary menu driven site.

Still groping...

yours, Marcus

[sweatje]

So now I'm wondering when a View is a different View. Where exactly is the dividing line between variations on one View and two different Views? At the point where you make separate mechanics for each? In the form of, say, different templates or different controlling classes?

It seems to me the dividing line is primarily the request. In general 1 request = 1 view. In the case of frameset's, I generally think of each pane of the frameset as being a separate view, primarily because they can be requested independantly.

YMMV

[Widow Maker]

Try to avoid FRAMEs if possible, but in the event I need to use them, what I cannot get me head around is the idea that any one (of one or more) can independently refresh it's self, as you say SweatJ.

Now, how would you accomplish this, from

a) Front Controller point of use, and
b) MVC ?

In the sense of how you reference a given FRAME ? Might be able to imply Javascript into the equation somehow, for example, to determine exactly what URL to refresh with ?

My head hurts just trying to figure it all out

[dagfinn]

It seems to me the dividing line is primarily the request. In general 1 request = 1 view. In the case of frameset's, I generally think of each pane of the frameset as being a separate view, primarily because they can be requested independantly.

YMMV

Hmmm...there's a crucial distinction I'm getting here--the distinction between a view as class (in a very abstract sense, not necessarily OO) and a view as runtime instance. One is code, the other is a "viewing" generated from that code. When you say 1 request = 1 view, aren't you talking about a runtime instance. If you hit Reload on a Web page, will that generate a new view?

In rich-client MVC, Views are runtime instances (simultaneous ones, in fact). In Web MVC, it seems we usually speak of Views in terms of the code that generates what the user sees. It's hard to pin down, but I think that's the case.

[meryn]

Dagfinn, it's good you bring up those two notions of 'view'.
I think that a lot of people forget that in web applications (in the abstract sense, the application that you use, that you experience) a both the view and the controller are spread out between the client and the server.

The view is not only the HTML output, or the code that generates it, it's also the styling applied to it by CSS, some parts may even be hidden! It's also the place of the HTML page within your browser window. It could be in a frame. This could be a called a 'framed view'.

The controller isn't only the HTTP request handling. It's also the javascript. Your browser is in fact a very important part of the controller (again, in the abstract sense).

A web application is more than HTTP request handling. I think MVC can't be applied to HTTP request handling without remembering that a part of V and C are in fact on the client side, on which you (as a PHP developer) do not have direct control.

[Azmo]

How about if we avoid "view" for a moment? The nastiest example seems to be frames and composite views so I'll randomly poke around here for a sec...

Odd... I'd say that these two are the easiest two of the list you posted....

The "composite view" is a single Document with multiple Blocks of content. In another thread (I think it was about data driven web apps, started by Harry), I already tried to explain that multiple Blocks in a single Document are either unrelated to the main Block (so they don't depend on the Request's parameters) or they can deduct their own parameters from the parameters used for the main Block.

A framed 'page' consists of several Documents: the frameset, and one or more HTML pages. There is a separate Request/Action/Document set for each part of the page. The main difference with normal web pages, is the lack of a main layout inside the frames: instead of a header/footer/menu page, each frame Document only consists of the content of the Block it contains.

Off Topic:

This would be a nice argument against automatically prepending and appending headers and footers to each page; which IMO is a bad smell.

[Selkirk]

I see the idea of a view as concretely rooted in the HTTP protocol. The view, composite or not, is tied to response generated to an HTTP request.

Does page = view?

I'm a bit surprised at how difficult it is to define a page. I think the idea of a page has to account in some way for the URI of the request. Perhaps the answer lies in some Human Factors oriented definition of a page. For example the nouns and verbs concept that Mark Rickerby posted to the WACT mailing list.

The "what is" discussions about MVC remind me a of the discussions that we used to have when we were trying to follow Ivar Jacobson's OOSE definition of a use case. We had endless discussions of uses versus extends, detail levels, best practices, formats, etc. Then we found that Catalysis had a better definition of a use case. once we understood the catalysis definition, all those issues that we used to argue over all went away because the catalysis definition provided clear guidance where the OOSE definition did not. The switch from confusion to clarity occurred for us almost overnight. It would be nice to see the same thing happen in this forum regarding MVC.

I am not sure where clear guidance will come from in this issue, but I am inclined to tie definitions to concrete concepts such as the HTTP request, response, and perhaps resource (URI).

I wish I had more time to research this issue. I've started to collect some related references regarding URIs here.

I am just thinking out loud here, but perhaps in order to clear this up, we have to let go of the idea that the default pattern in PHP is the page controller. Perhaps this idea makes our concept of what a page is too broad?

[lastcraft]

Hi...

Does page = view?

Not with an applet, but I would say that this pushes us outside the web paradigm altogether. A simplification of frames is that in practice there is only one content frame at a time, the other frames contain menu/search controls that fetch the main content "page". You can always knacker the page metaphor, but for usability reasons it is unwise to do so.

nouns and verbs concept

I don't think that is correct. Experienced users in web environments have two modes of thinking. Search mode (the eyeball scans subconsciously for blue underlined text and ignores all else) and goal mode (you start reading and scrolling). You will bookmark the top of interesting indexes and useful goals. You won't bookmark any intermediate steps.

Form filling strikes me as a special form of search mode. You just want to fill in enough widgets to get to the end of the task. The goal here is simply to finish and anything else is just a distraction. The form filling could be JavaScript or multiple HTTP requests, but the user probably won't notice.

Perhaps "doors" and "rooms"?

I am just thinking out loud here, but perhaps in order to clear this up, we have to let go of the idea that the default pattern in PHP is the page controller.

There are those "views" which require handling to get to a different page. Usually forms, such as search fields and sign-ups. There are "views" that show information and any controls cause a request to be echoed to the same page. An example might be a grid view with links to reorder the columns. You can have both within a single "page".

I find the composite view (esp. custom tag) a more powerful concept with web apps. A view talks to itself or it sends a command to higher level (different view, frame or page). A view that talks to itself (introvert) has it's own handler and higher handlers (URL/page) just pass it through. That the page is repainted is an unfortunate accident. An extrovert request is intercepted with the intention of finding a new room.

Both types are sending HTTP requests.

yours, Marcus

[dagfinn]

There are those "views" which require handling to get to a different page. Usually forms, such as search fields and sign-ups. There are "views" that show information and any controls cause a request to be echoed to the same page. An example might be a grid view with links to reorder the columns. You can have both within a single "page".

Since last time I had a realization about this. There is a ridiculously simple way of thinking about it. There are HTTP GET requests and HTTP POST requests. GET expresses the intention to view something, POST expresses an intention to process something. Isn't that pretty close to the distinction you're making here?

What's more, it answers the question in the very first post in this thread:

An http request could maybe be seen as having two parts.

(1) a "presentation request" - ie the page to serve up to the client (model and view)

(2) a "processing request" - any tasks which do not output anything to the browser: form processing prior to building the "success" page/form redisplay, authentication, etc (added in controller)

Yes, you could see it as having two parts, or you could see it as either/or: (1) HTTP GET or (2) HTTP POST.

Tell me I'm wrong, it couldn't possibly be this simple

[dagfinn]

Does page = view?

I'm a bit surprised at how difficult it is to define a page.

So am I. My conclusion so far, after thinking a lot about it, is that a page is a concept which is meaningful on a static HTML site and pretty much meaningless in Web programming.

I am just thinking out loud here, but perhaps in order to clear this up, we have to let go of the idea that the default pattern in PHP is the page controller. Perhaps this idea makes our concept of what a page is too broad?

If the concept of a page is meaningless, the the term Page Controller is confusing. Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions. (That, in turn, is a confusing term, but less so.) I can see now that Fowler, on whom I've been leaning heavily, is also confused and doesn't quite know what he's talking about. Neither does anyone else, I think.

[Azmo]

My advice: forget pages, and ban the use of the term 'view' in web development. These two terms both have strong ties with the user's experience created by following a chain of requests using a web browser. And while this is how the majority of our applications will be used, it has NO relation to the actual workings of web applications. Processing (or rendering) the output of our applications is the job of the client software. The user (if there is one) creates his own interpretation of the presented content based on his expectations, prior experiences, and the context and style in which the content is presented.

Our applications return a Response for each Request sent by a client. An Action needs to be performed to create the Response. In most cases, we need to include a Document in the Response with links to further related Requests. That is the core functionality of a web application. What we perceive as a 'View' or 'Page' is no more than one or more Documents rendered by the web browser in the same window. These two terms only have real meaning at the user level.

But if you start your conceptualization from the perspective of a User, you're going to paint yourself into a corner, because you end up completely missing the point. For example, lots of people on this forum have been trying to solve the problem of 'Form validation'. But forms don't even exist from the application's point of view. A form is just an HTML structure which lets a User manipulate the parameters that will be sent along with the next Request by the client software. All the application sees is a list of parameters, and it doesn't give a damn whether these came from a regular request or from a form. But everyone's trying to solve the form 'problem', because they see a form on their screen.

I can understand how people are having problems with form validation, composite views, and all that other crap. Because most of these 'problems' arise when we define our application from the user's perspective, and they become completely befuddling when we combine these misconceptions with the ultimate anti-pattern in web applications; an MVC-based architecture.

Thank god I don't use MVC.

[dagfinn]

Thank god I don't use MVC.

I'm afraid your architecture could be described as MVC anyway. Your Responses and Documents would be the View. Whatever you use to process the Request is your Controller. And presumably there's some data and possibly some business logic (even though you neglect to mention it), which would be the Model.

Then there's the Action. Fowler would place that as part of the Controller in the Front Controller pattern.

You may not like it and you're free to reject it, but what I think is that it's good to be able to think of a design from different perspectives.