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.

Ok, here is simplified code of how i would try implement an MVC pattern to the above app.
Basically the links and forms in the app contain _OBJECT and _METHOD values either via $_GET or $_POST.
So in this example if i clicked on the "edit" link, i would create an "ArticleViews" object and call the "articleForm" method from that object.
and by submitting the form i would create a "ArticleModel" object and call the "editArticle" method.
Would you consider this MVC? I've used this approach and it and have not had any problems, but i feel like i'm missing the boat on this concept.

Thanks for your input ausurt, so you would say im on the right track here? I recently posted a question (there is a link in my first message above) about this controller and the response i got made me think maybe im not seeing the big picture of MVC.

Anyone else have an opinion as to whether the code above is a legitamate MVC pattern? Like I said it seems to work fine for me, but i would really like to get some confirmation that im going in the right (or the wrong) direction with this thing.

The only problem I see with your code (And this is only thecnical and shouldn't drive your design until latter) is the overhead it has for each request building the array of allowable calls when only method of one class it's gonna be used.

Perhaphs I've been worring too much about the performance of my applications lately, but currently I'm trying to break up classes so only code that's gonna be execute is included and avoid building too much configuration / options arrays.

Actually this is really for dummies like myself, an easy-to-understand example that tackles a practical problem. However, just wondering if any other experts/experienced developers agree w/ the implementation? Or there are more potential problems w/ it?

Regards

edited: I believe the implementation is similar to what's in php|arch May article.

This is your Model, thus you should not have $_GET et al in your Model at all; The Model(s) are completely ignorant of this knowledge. A better option would be just to pass in the parameter(s) via the class method it's self, via the Controller.

As for everthing else, I suppose it would pass... Personally, I wouldn't address $_GET et al directly, but I would encapsulate them, but that isn't here nor there in regards to MVC, but this specific point I make is purely a design issue, in regards to those GLOBALs ($_GET et al).

The Request ($_GET et al) has, prior to reaching this point - executing the controller - has been merged with $nodes; I can do this since the $nodes container is the same type as of Request, so architecturally it makes no difference to the triad (in my view).

Thought I'd mention that, as accessing the Request is via the View therefore. A Model just looks like this,

The View it's self is typeof QDataspace_Interface as well, so I only need to push the Model data over to it via the QDataspace::import( QDataspace_Interface $dataspace ); class method.

You understand, that I make extensive use of this QDataspace container? It just helps in so many ways, for me to decouple a lot of responsibilities; In fact a huge part of my framework hinges on this type (along with another type; QAcceptee_Interface and QAcceptance_Interface [The Visitor pattern]).

This is your Model, thus you should not have $_GET et al in your Model at all; The Model(s) are completely ignorant of this knowledge. A better option would be just to pass in the parameter(s) via the class method it's self, via the Controller.

> What pattern do you use in conjunction with MVC for multiparts of a page?

Composite and the Visitor; You require the Visitor so you can separate the rendering away from each of those Composites. The separation therefore allows you to easily implement a number of renderers... Such as one for (x)Html, Xml, etc.

The Controller part in my MVC implementation is a Composite, in that it can contain child Controller(s); A given renderer will recurse the Composite structure, from the bottom up (towards the root) to execute each Controller, and in turn, gather the generated output for each Composite in turn.

You've made the same assumption as someone else [MikeShank] in regards to your Model by putting $_GET et al in there, where they should be in the Controller, and these it for the Controller to pass in the parameters to the Model, be it by the constructor, or a class method on the Model.

Your not escaping your data either going into your SQL which is bad; Apart from that, I can't (seam to) fault it.

You've made the same assumption as someone else [MikeShank] in regards to your Model by putting $_GET et al in there, where they should be in the Controller, and these it for the Controller to pass in the parameters to the Model, be it by the constructor, or a class method on the Model.

Your not escaping your data either going into your SQL which is bad; Apart from that, I can't (seam to) fault it.

For the escaping part I have some other code somewhere else that cleans all the stuff going into the database. What I have put here is just a baisc example.

I actually have a full shopping cart system setup using this type of MVC, but I want to make sure I'm coding things the right way.