[MVC] Implementation issues

[atu]

Originally Posted by 33degrees:
What exactly do you mean by 'figure out'? I'd say that a model is generally picked based, in some way, on the request, which makes it the controller's domain.

I think on a loose coupling between the view and the model.
Details here

[Viflux]

Skimmed some posts, as I'm not really up-to-snuff on all the latest Pattern Terminology.

It took a while for me to get everything working seemlessly, but thus far it works well and haven't encountered any unsurmountable snags.

Here's an overview of what I do, and it works. Not sure if it falls into any given setup as described above.

1. Front Controller (index.php) receives all requests.
2. Front Controller performs pre-filters.
3. Front Controller chooses and creates Application Controller based on request.
4. Application Controller runs pre-filters.
5. Application Controller chooses and created a Data Source.
6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
7. Model returns XML to Application Controller.
8. Application Controller chooses and creates View, based on request, and passes XML to it.
9. View loads necessary XSL files, performs XSLT and outputs results.
10. Application Controller runs post-filters and tidies up.
11. Front Controller runs post filters and tidies up.

[Captain Proton]

You see, telling a model to fetch data isn't..

I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..

[arborint]

I wish we could agree on when to use "fetch." It is commonly used to mean "get data from a database" as opposed to "load" with usually implies "get (all) data from a file" or "read" which implies a stream, whether a file, device or port. Which is pretty confusing and I imagine worse for those for which English is not their first language.

Think of how those words apply to a book, for example. To fetch a book means to go get it and bring it back. To load a book means to put it into something. To read a book means to scan the text inside it.

Maybe "access" or "get" for variables?

[Overunner]

Very interesting discussion, keep it flowing

As for the FC, I have a ChainOfResposibility with one or more RequestMappers. Each RequestMapper may have different strategies for selecting a proper Controller, or it may fall thru to the next in the chain, if it doesn't find a match.

Why do you need more than one RequestMapper? What's the difference between your RequestMapper_ActionRequestMapper and your RequestMapper_ServerPageRequestMapper?

The Request is passed to the FC...the $_GET['command'] variable is matched to the CmdDictionary. If there is a command for it, execute it (or if it is a Composite Command, execute all childs as well), else execute a default Command.

So if you want to execute several actions you load one big action (lets call it main) which executes all the actions? This approach seems very inflexible to me since it will result in an explosion of classes, no? What if I mix and match my actions, then I'd have to create a new action for every combination of actions I want to execute seqentially.

-Each Command holds a controller, which is executed when the command is executed. Based on the Request, the Controller loads a View and populates it with a model, which belongs to the controller.

So your command is basically an application / page(?) controller?

Also, I wonder why you need the CommandDictionary (storing commands?). Wouldn't it be much more simple to just fetch the Command from the filesystem. For instance like this:

function getCommand ($commandName)
{
  $file = '/commands/' . $commandName . 'Command.class.php';
  require_once($file);
  $class = $commandName . 'Command';
} 

[DarkAngelBGE]

@Overrunner: About the several Actions. Why would this be inflexible? You just create an Action object and pass it to an existing Action object, like

$action1->addChildAction($action2); 

However, I agree that my way of doing this is still not very flexible. Open to ideas here.

Yes, my command is as of now more or less only a controller, since it does not do much more than holding a controller. Might need it for more stuff later though.

CommandDic is simply my way of having an ActionMap which I can populate in different ways depending on whether I deal with the AdminPanel or not. It really is only for programming closer to the problem as of now.

[McGruff]

I'm getting a bit behind in this topic but...

But then again if you have a PDFView and a HtmlView of some text that is stored in the database, both Views would include the same code for telling the model to fetch the data. Isn't that Code Repition?

Actually it's just the reverse. The same data-collection code is re-usable with any kind of template.

[DarkAngelBGE]

@Overrunner: Actuallly I have refactored it all now. I just pass a Collection of Controller identifiers and the request to the fc, which tries to map the request to the list, loads a controller file dynamically and executes the controller. Thanks for your notification, I was coding blindfolded.

So for now I got rid of CommandDictionary and Command. At my house a Controller is an Action. Weird, but ok yes?

[McGruff]

If you use DispatherView, the View pulls from the Model, whereas in the TemplateView the Model is pushed to the View (~Template) by the Controller (~Action). You may then argue that the DispatcherView isn't "true" MVC, since Controller and View are intertwined. This can be dealt with by introducing the ViewHelper witch is an object that pulls data from the Model. This gives you back your VC seperation, since the controller-logic is now in the ViewHelper.
So in the DispatcherView you have the Controller represented by the ViewHelper, while in the TemplateView you have the Controller represented by the Action.

I think it's maybe easier to understand if you think of "control" as making decisions - including which view to display. Other entities actually do all the work. The controller can ask a view to update itself but it can't get involved in the details of that task (at least not in MVC). Objects which help create a view are part of the view layer not the controller layer. Controllers will manipulate the model, views will read from the model and never the twain shall meet.

[arborint]

I think McGruff's explaination is an excellent one. Controllers probably got their name from association with electro-mechanical controllers. Those controllers tell a device to do something (e.g. a valve to open/close) but are neither the device itself (i.e. the valve), nor the mechanism the controller talks to (i.e. motor and gearbox).

[33degrees]

I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..

Right, what I meant is that the model needs to fetch data from the database, and it's the controller's job to the tell the model what data to fetch, based on the request.
Here's an overview of what I do, and it works. Not sure if it falls into any given setup as described above.

1. Front Controller (index.php) receives all requests.
2. Front Controller performs pre-filters.
3. Front Controller chooses and creates Application Controller based on request.
4. Application Controller runs pre-filters.
5. Application Controller chooses and created a Data Source.
6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
7. Model returns XML to Application Controller.
8. Application Controller chooses and creates View, based on request, and passes XML to it.
9. View loads necessary XSL files, performs XSLT and outputs results.
10. Application Controller runs post-filters and tidies up.
11. Front Controller runs post filters and tidies up.

Interesting; in regards to steps 5 and 6, I'm curious to know how this works exactly; by Data Source do you mean a specific server and database name? Or can your models get data from a variety of sources (i.e. Databases, text files, etc)

Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...

[33degrees]

Degrees, did you look at the code samples I posted above? What do you think of them?

Yes, here's what I would do:

In the controller

<?php
/**
* Author: Tim Koschützki
* Date Started: April 7th, 2005
*/
require_once('IssueController.php');

class DeleteIssueController extends IssueController {
    public function DeleteIssueController (&$dao,$input=null) {
        parent::__construct($dao, $input);
    }
    public function execute() {    
        if(!isset($this->input['submit'])) {
            require_once(ISSUE_VIEW_PATH.'DeleteIssueItemView.php');
            $this->model->listIssue($this->input['id']);
            $this->setView(new DeleteIssueItemView($this->model, $this->lang));
        } else {
            $success=0;
            if($this->model->deleteIssue($this->input['id'])) {
                $success=1;
            }
            
            require_once(ISSUE_VIEW_PATH.'IssueItemHasBeenDeletedView.php');
            $this->setView(new IssueItemHasBeenDeletedView($this->model, $this->lang, $success));
        }
    }
}

?>

And for the view

<?php
/**
* Author: Tim Koschützki
* Date Started: April 7th, 2005
*/
require_once(LIB_PATH.'Template.php');
require_once('IssueView.php');

class DeleteIssueView extends IssueView {

    //! A constructor.
    /**
    * Constucts a new IssueItemView object
    * @param $model an instance of the IssueModel class
    */
    public function __construct(&$model,&$lang) {
        parent::__construct(&$model,&$lang);

    }

    //! A manipulator
    /**
    * Renders a single issue
    * @return void
    */
    private function deleteIssueItem() {   
        $tmp =& new Template('delete_issue_confirm');        
        $tmp->setValue('{ISSUE_ID}',$this->model->ID);
        $tmp->setValue('{ISSUE_TITLE}' => $issue['title']);
        
        $tmp->parse();
        return $issueTemplate->fetch();
    }

    public function display () {
        $tmp =& new Template('standard');    
        $tmp->setValue('{HEADER}',$this->header());
        $tmp->setValue('{FOOTER}',$this->footer());
        $tmp->setValue('{NAVBAR}',$this->navbar());
        $tmp->setValue('{CONTENT}',$this->deleteIssueItem());
        $tmp->parse();
        return $tmp->fetch();
    }
}

?>

The model->listIssue() command is now in the controller, which is where I feel it belongs, and which is incidentally where you had placed the model->deleteIssue(); both commands manipulate the model in some way, and that's why they belong the controller.

Also, since the model already contains the data the ID of the item to be deleted, there's no longer any need for the controller to pass it seperately and for the view to store it.

Other than that, it looks good to me!

[33degrees]

Allow me to recap on TemplateView vs. DispatcherView...

Thanks, I had been a bit confused regarding the difference between the two; now I know that my prefered approach is using a DispatcherView.

I think on a loose coupling between the view and the model.
Details here

Looking at that diagram, the view is inside the controller, and is doing things like appending filters and authentication; I would argue that those things aren't presentation logic, and that this view is really just a controller, with the template being rendered a TemplateView.

[McGruff]

Looking at that diagram, the view is inside the controller, and is doing things like appending filters and authentication

This (SMART) may or may not be a good design but it's certainly not MVC. Here's the WACT wiki entry on MVC: http://wact.sourceforge.net/index.ph...ViewController

1. Front Controller (index.php) receives all requests.
2. Front Controller performs pre-filters.
3. Front Controller chooses and creates Application Controller based on request.
4. Application Controller runs pre-filters.
5. Application Controller chooses and created a Data Source.
6. Application Controller chooses and creates a Model, and passes in the Data Source and the request.
7. Model returns XML to Application Controller.
8. Application Controller chooses and creates View, based on request, and passes XML to it.
9. View loads necessary XSL files, performs XSLT and outputs results.
10. Application Controller runs post-filters and tidies up.
11. Front Controller runs post filters and tidies up.

OR:


Front Controller (index.php) receives all requests.
Front Controller performs pre-filters.
Front Controller chooses and creates Application Controller based on request.
Application Controller selects a view and tells it to update itself
Front Controller runs post filters and tidies up.

[McGruff]

I'd hate to add to the confusion, but the Model is "the data". Model is your application's data model..

Just to expand a bit, the model performs domain logic on raw data obtained from persistent storage, amongst other things. Data obtained from the domain layer has some kind of added value compared to data obtained direct from the data access layer.

[DarkAngelBGE]

Thanks Degrees for your code sample. What do the others think of what Degrees posted?

[DarkAngelBGE]

Hrm actually I dunno. I think this is not really important whether the controller tells the model to select an issue or the view tells the model to select the issue. This code does not manipulate the model in any way, the model is still independant of the presentation. I agree though that everything that manipulates the model should be in the controller. That's what Fowler's been saying as well.

[atu]

Originally Posted by McGruff
This (SMART) may or may not be a good design but it's certainly not MVC.

Thats correct.

IMO following 100% the mvc definition results in overcomplicated design.

[DarkAngelBGE]

IMO following 100% the mvc definition results in overcomplicated design.

Which one do you regard as the MVC definition?

[atu]

Originally Posted by DarkAngelBGE
Which one do you regard as the MVC definition?

Thats a good question. May the reason for some confusions is here.

[kyberfabrikken]

Why do you need more than one RequestMapper? What's the difference between your RequestMapper_ActionRequestMapper and your RequestMapper_ServerPageRequestMapper?

They follow different rules for determining the target. The ActionRequestMapper would recognize a $_GET['action'] and create an Action object. The ServerPageRequestMapper would match a regex against $_SERVER['REQUEST_URI'], and return a DipatcherView object with the filename. You could make up new rules ... for instance you might crete a CommandDictionaryMapper, witch holds degree's CommandDictionary.
It allows me to combine different strategies for mapping the request ... actualy it makes it possible to use TemplateView for some pages and DispatcherView for others.

now I know that my prefered approach is using a DispatcherView

so is mine, but it took me some time to swallow it, since for simple pages it gives the impression of not being "proper" MVC as the V and C aren't seperated.

Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...

Regarding XML/XSLT for Views, I think there is a great potential for using DipatcherView. With XML_Transformer you could use callbacks to ViewHelpers from within te XML-document (the View). I have been toyed with this, but haven't actualy used it.
This way you won't have big xml-documents in memory, since the ViewHelper will just fetch what is needed.

[DarkAngelBGE]

for instance you might crete a CommandDictionaryMapper, witch holds degree's CommandDictionary.

It is "my" CommandDictionary.

Anyone willing to elaborate on whether the controller should use the model to say fetch(!, not manipulate) some data from the datasource and then pass the model to the view or whether the view should use the model to fetch the data. Does it matter much? WHat are the Pros and Cons?

Too bad Fowler does not say anything about that in PoEAA. He simply states that the controller is responsible for manipulating the model. That's alright. But should fetching some data from the datasource also be considered as manipulating the model? Sounds like it does it not?

[kyberfabrikken]

It is "my" CommandDictionary.

Sorry - I just skimmed back thru the thread, and saw 33degrees post some code.

Anyone willing to elaborate on whether the controller should use the model to say fetch(!, not manipulate) some data from the datasource and then pass the model to the view or whether the view should use the model to fetch the data. Does it matter much? WHat are the Pros and Cons?

Well - for one thing, it's easier to narrow it down to just what you need, with the pull-method, than with the push. Also - If the View really need nothing from the Model, it's overhead to have a push-architecture.

Too bad Fowler does not say anything about that in PoEAA. He simply states that the controller is responsible for manipulating the model. That's alright. But should fetching some data from the datasource also be considered as manipulating the model? Sounds like it does it not?

You may have a point here - I'll have to consult the holy text on that. Whether or not Fowler says it, I'd argue that the seperation is healthy nevertheless.

[Viflux]

Interesting; in regards to steps 5 and 6, I'm curious to know how this works exactly; by Data Source do you mean a specific server and database name? Or can your models get data from a variety of sources (i.e. Databases, text files, etc)

Also, if you need to display data from, say, 100 rows in your database, doesn't that make for a big XML file to have in memory? Still, I find the idea of doing view using XSL very interesting...

Well, as of now, it can use a database, text file or XML file as the data source.

I don't actually create an XML file, I just pass around XML stored in a variable. No different than storing all your content in a variable, in an unorganized state.

[DarkAngelBGE]

Quote:
Originally Posted by DarkAngelBGE
Anyone willing to elaborate on whether the controller should use the model to say fetch(!, not manipulate) some data from the datasource and then pass the model to the view or whether the view should use the model to fetch the data. Does it matter much? WHat are the Pros and Cons?

Well - for one thing, it's easier to narrow it down to just what you need, with the pull-method, than with the push. Also - If the View really need nothing from the Model, it's overhead to have a push-architecture.

Don't quite understand. Whether the controller fetches the data and sends an updated model to the view or the view tells the old model to fetch some data both stands for a pull method. The View pulls the data from the View. It's just whether the controller tells the model to update itself or the View.

Maybe I did not understand what you meant though.