The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Arborint: Fowler doesn't make the distinction which you have suggested between CM or VM separation. He talks about separating presentation from domain, and about separating view and controller in the presentation layer. Possibly you have misunderstood the presentation layer: this encompasses both view and controller.

Not taking a stab at you McGruff, but it (presentation) can emcompass both View and Controller, which I've seen in a lot of Swing and is common in this area. But I speculate that both View and Controller require separation.

Even if Fowler gives it may not be neccassary to do so, but tha's just my view

You are correct that the presentation layer encompasses both view and controller. But then you simplify it to that point you have just created some sort of Super Transform View. My experience is that the degree of separation between View and Controller can vary, and for that matter the degree of separation between the View and Model, and the Controller and Model can vary as well. And maybe the last project wasn't perfect and pure, but as long as it was better than the one before it then we're still learning and improving. And the choices on degree of separation were hopefully made with an understanding of the tradeoffs.

My problem continues to be churning in search of some dogmatic definition. I am less interested, at this point, in what Fowler said two years ago than, for example, things like sweatje's Double Switch Controller idea. I love the devilish details. To have to hear "that's not MVC" everytime anyone proposes an implementation idea gets old.

I have to wonder what your motives are here. This isn't the first time you've been snapping at my heels. You seem determined to try to finesse my attempts to help explain the MVC pattern despite your obvious lack of understanding. My main reference for most things is Fowler: please go and argue with him instead. This is the sitepoint advanced forum not the Jerry Springer show.

On a framework-level, I don't distinguish much between Controller and View. The Action encompasses both roles, but one at a time. Say that I wanted to update the model - I would have an Action instance that does it's job, then redirect to a View-oriented Action. For example :

As such, all the Action classes in my first example must be regarded as part of the View.

I did it this way, in an attempt to overcome the mismatch between the MVC as it was originally thought out as an architecture for GUI-applications, and how it could be implemented in a web-application.

An Action is merly a response to a http-request. Technically, I believe the browser could be thought of as being the View in a web-application. Thus a request could be either a message to update the Model or a requst for View-data.

I guess this means that I don't distinguish between View and Controller on a code-level, instead I do it on a design-level. It might be more sane to enforce it by simply subclassing Action into View. I'll consider that.

kyberfabrikken, can you post your ListIterator code so I can try you code out?

So every subsection is a atomic part of a complex page. My first question was from where do I get the data for such subsections? My supposition was, the one “Command” collects all the data and passed it with a single DTO Object to the view, not very nice, because the DTO gets huge and complex, but a good separation of content and design?! (Only a push concept, nothing to pull!)

The Kyber approach?!:

If I understand you right kyber, you said the data is assembled by subactions, so every subaction matches one subsection?!

The Proton approach?!:

If I understand you right … ;-) One “main action” for e.g. “UserEdit” with a template which includes subsections. The main action gathers the data (only for which belongs to the “UserEdit”!) and passed it to the view (A push concept). The view uses a complex template which consists of subsections. Each subsections pull the data from Viewhelpers (?!). In that case the View collects data! So Captain Protons approach is a combination of a push and pull concept?!

If I understand you right … ;-) One “main action” for e.g. “UserEdit” with a template which includes subsections. The main action gathers the data (only for which belongs to the “UserEdit”!) and passed it to the view (A push concept). The view uses a complex template which consists of subsections. Each subsections pull the data from Viewhelpers (?!). In that case the View collects data! So Captain Protons approach is a combination of a push and pull concept?!

I think you got it about right.

For a complex template (as an example think of one with a user login form, a poll and a search box or something like that) I would probably use a ViewHelper indeed.

The way I see it you even have two choices, depending on how strictly you want to layer your application. You can have your Controller create the ViewHelper and pass it onto the view or you can have your view create the ViewHelper itself (breaking layering of course).

I honestly think of my solution as simpler than protons, because all the complex logic is kept in one place (in the Action's), rather than having ViewHelpers.

As far as I know, mine doesn't have any complex logic ViewHelpers can really be as simple as classes with getLatestPollObject() methods, etc. Nothing complex there.

I agree with kyberfabrikken that most actions are requests from the client to perform some action with your Model classes. So I might have some classes like UpdateUserPrefAction or ChangeCriteriaAction. All of these actions would eventually issue a redirect to the application indicating the desired view to show.

Views are then the "default action", i.e. if no other action is specified, show a view. If not specific view is selected, show a default view. I have view classes which
a) create a template object
b) access the Model classes to polulate template vars
c) render the template
I think these might be considered Protonish view helper classes.

Whether my "View" class is a part of the controller (becuase it is brokering data to the template) or a part of the view, I will leave to the MVC philosophers, as I have no idea how many angles can dance on the point of a $model->get('pin')

Whether my "View" class is a part of the controller (becuase it is brokering data to the template) or a part of the view ...

My point exactly.

Originally Posted by Captain Proton

As far as I know, mine doesn't have any complex logic ViewHelpers can really be as simple as classes with getLatestPollObject() methods, etc. Nothing complex there.

I implicitly presumed the "or you can have your view create the ViewHelper itself (breaking layering of course)" solution. I probably didn't mean complex as in "advanced piece of code" as much as "hard to figure out where it's initiated from". If the ViewHelper is instanciated in the Controller, and passed to the View, I get the idea, but I'll argue that the ViewHelper belongs to the Controller-layer.

My thoughts are with the Captain in regards to the View Helper. As from what I can tell, I suppose the View Helper should wrap a given Model

By wrap I mean it [the View Helper] resides over the Model in layering terms...

Admittedly - I stay corrected.
I never actually used the pattern myself, as you may deduct from my posts. I do acknowledge it as a feasible replacement for my Controller-push architecture. Does anybody use this pattern in combination with a XSLT-based view ?

Anyway - ViewHelper or not - how do you people assemble complex views ?

You do? I've yet to see any example that implies a View Helper has any involvement with a Controller [MVC]. Anyways, to answer your question I stated earlier the Composite View?

I stated that your implementation was static, and to some degree this is the case in the sense I was meaning you need to build the composites on the fly, to be dynamic but I didn't see this in your script.

I've tried a few approaches on building the web page as a whole from a number of segments though I've never been really happy with the results. The problems have been in relation to building the composite structure it's self.

I stated that your implementation was static, and to some degree this is the case in the sense I was meaning you need to build the composites on the fly, to be dynamic but I didn't see this in your script.

It's rather hard to see in the posted example, but the idea is that Action::getOuterAction() can return different actions depending on whatever. In the posted example I just return a hardcoded action so in reallity it becomes static. But it's quite simple to extend the method to return something else. In contrast the MainSectionAction vs. MainMenuAction is truly static.
Eg.:

First, please excuse my earlier comments. There's been some history there which I won't go into. Rightly or wrongly I felt that an entirely unambiguous point was being spun out into a point-scoring argument.

Originally Posted by kyberfabrikken

OK, I've done some thinking, and I believe I have a reply to McGruff.

That looks like an ApplicationController. What I think you are calling a view seems to be a whole new request with - possibly - a further MVC trinity containing a view.

I really don't know what else to say about the basic idea of view and controller separation which I haven't already said. It just is what it is.

One possible approach to MVC design is just to forget all about it: decompose the presentation layer as you see fit.

As long as you follow the usual presentation/domain/data layering, and the principle of "one class one task", you'll almost certainly end up with something MVC compliant. Controllers receive input, make decisions and tell other entities to do all the heavy lifting. Calls to the domain for the data to be displayed, presentation logic, formatting, printing the final page: these are all aspects of the view. The two don't have anything in common and if you tend to write nice, tight little classes perhaps there's not much chance they'll get mixed up in the first place. Separating decision from action is an obvious refactoring, in general.

The "MVC" label doesn't say anything much in any case. FrontController? TableGateways? DataMappers? TemplateView? These explain something meaningful about the design choices. If a travelling salesman came to my door selling MVC, I'd frankly be a bit suspicious.

This way the code is more expressive about what it is doing: getCommand gets a command, rather than a large switch block in a run() method. It also exposes more functionality of the FrontController, as it is basically acting as a factory. And you get shorter code too.