SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 118

Thread: The MVC's model

  1. #76
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    A model doesn't have to be of the same "entity" as the view. You could have one or several models loaded into a single view. So you could theoretically have separate model classes for the session, server, etc data access and merely inject them into the view. The idea behind a model is data access and that doesn't specifically only include the database but all data related transfer. Therefore, it is perfectly acceptable to use session and server models. You could even encapsulate that functionality in a single model called system or something.
    The only code I hate more than my own is everyone else's.

  2. #77
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    See to me, the model is more about the business logic than the data access, although that is obviously part of it in 95% of cases.

    Where I do disagree, is the idea of having a SESSION model or SERVER model or SYSTEM model that centralized access to environement variables.

    For one, I think those objects would essentially be getter/setter abstraction objects, nothing more, so I wouldn't call them models so much as I would very trivial data accessors.

    Secondly, while dependencies are expected and required, the less you have, the better of you are.

    I guess it comes down to asking yourself, what are the odds I am going to use this model inside a CLI script? If the answer is yes, then maybe directly depending on SESSION variables isn't a good idea, at least inside the model?!?

    Secondly, what implications does that have on unit testing? Models are the one entity I would test, if and when I write AUT for anything. So the easier time I have, the better.

    Anyways, I went slightly off-topic. I am more curious to see what others (including yourself) say about the number of additional view classes that need be introduced. In my applications, the view is typically nothing more than a Smarty instance or PHP alternative syntax custom class.

    I assign various values to the 'view' object, initialize with a template and render. I use an approach similar to that of Joomla when dealing with complex layouts, so modules like paging are composed of loosely coupled MVC components but you still retain that drop-in nature.

    Cheers,
    Alex
    The only constant in software is change itself

  3. #78
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    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.
    No, I am not changing my position. The data flows between the Model and the View, but how it flows is not specified in MVC.

    Quote Originally Posted by TomB View Post
    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.
    I do not deal with pagination by creating a single pagination component. Pagination exists as a set of variables which are transformed into HTML by logic in the View, and into SQL by different logic in the DAO. These variables are not logic, they are data. It is logic which transforms this data into either HTML or SQL. I do not have to change any model definition to deal with pagination. The necessary logic has been defined in one place and is inherited by all model classes.

    Quote Originally Posted by TomB View Post
    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.
    I disagree. Logic is lines of program code while data is groups of variables. Code is not data, therefore variables are not logic. Data may be transformed, processed or manipulated by logic, but it is not part of that logic.

    Quote Originally Posted by TomB View Post
    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
    I have never disagreed with this. I have stated quite categorically that in my implementation that any model can be used with any view, and any model can be used with any controller. Tell me where I have said otherwise?

    Quote Originally Posted by TomB View Post
    -The view has access directly to the model
    The view has access to the data from the model, but how it is accessed, either directly or indirectly, is not specified in MVC. That is an implementation detail.

    Quote Originally Posted by TomB View Post
    -The controller accesses both the model and the view
    I never said that it didn't. It may do, it may not. But if I show you an MVC diagram which does not have an arrow between the controller and the view, how is it possible for the controller to access the view?

    Quote Originally Posted by TomB View Post
    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.
    I do not build a view so that it can only be used by one model. I allow my models to use any view, and I allow my views to be used by any model.

  4. #79
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by PCSpectra View Post
    Secondly, while dependencies are expected and required, the less you have, the better of you are.

    I guess it comes down to asking yourself, what are the odds I am going to use this model inside a CLI script? If the answer is yes, then maybe directly depending on SESSION variables isn't a good idea, at least inside the model?!?

    Secondly, what implications does that have on unit testing? Models are the one entity I would test, if and when I write AUT for anything. So the easier time I have, the better.
    You've pretty much got it. Using $_SESSION directly will make a right mess of things.

    You've already mentioned testing. For unit testing you're completely knackered, because the tests will start interfering with each other. The key to testing is isolation and repeatability. If you have those, then tests are trivial to write and run as fast as the processor will go. With a free floating $_SESSION you'll spend your time debugging your tests. Hardly what you want.

    The properties that make it good for testing are also good properties for flexibility. If you decide to move a persistent piece of data from $_SESSION to $_COOKIES you end up rewriting code. That can't be right? An application level presentationish thing causing model rewrites?

    Grab hold of $_SESSION right at the very first top level script and pass it down (either as hash or wrapper) forever more. If in doubt always pass it, or better yet pull from it what you need and pass that instead.

    The real reason is that if you access $_SESSION directly you're head will soon explode.

    Suppose you have a bug. Another developer offers to help you out, but does not understand the code. They set up everything in a known state and stick a few print statements in to see what is happening. They dig as far as a model returning something strange. Thus far they've only have to search the model code, a smallish chunk of application. The bug is somewhere in there and they just have to keep digging downward.

    When they hit $_SESSION though, all hell breaks loose. Now the bug could be anywhere in the entire application. the best they can do is start grepping (a painful way of finding dependencies) hoping to find where the session variable got clobbered. Routine fault tracing has turned into spaghetti hell.

    That developer that knows nothing about the code is you in a month or two. You can probably see yourself crying into your coffee even now. Listen to the ghost of Christmas future and please, please take that $_SESSION reference out now.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  5. #80
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I do not deal with pagination by creating a single pagination component. Pagination exists as a set of variables which are transformed into HTML by logic in the View, and into SQL by different logic in the DAO. These variables are not logic, they are data. It is logic which transforms this data into either HTML or SQL. I do not have to change any model definition to deal with pagination. The necessary logic has been defined in one place and is inherited by all model classes.
    Haha, I point you to my post above where I anticipated you saying exactly this: talking about your own irrelevant implementation and saying you only need to change the base class.

    So you have display logic in the model! Even if you have to change the base model class you're still changing the model! Take my example where pagination does not exist in the system at all. You've just had to modify the model base class to account for it. you are coding your model around how it could be displayed.

    I disagree. Logic is lines of program code while data is groups of variables. Code is not data, therefore variables are not logic. Data may be transformed, processed or manipulated by logic, but it is not part of that logic.
    To work out the total number of pages you need to:
    -Query the database using a count(*) query with the same WHERE as you're using to fetch the current page
    -Calculate $totalRecords / $recordsPerPage

    This is logic. However you want argue this, it's not data. You're working something out. It's also only ever going to be used by the view. It's display logic.

    I do not build a view so that it can only be used by one model. I allow my models to use any view, and I allow my views to be used by any model.
    This is where you're very confused. You have things in the model which are related to a single view that may or may not ever use the model. This is wrong, plain and simple. You appear to be blinded by what your code can already do to see the disadvantages of it. Either that or you're trying to defend it because you don't want to admit when you're wrong.

  6. #81
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by PCSpectra View Post

    Anyways, I went slightly off-topic. I am more curious to see what others (including yourself) say about the number of additional view classes that need be introduced. In my applications, the view is typically nothing more than a Smarty instance or PHP alternative syntax custom class.

    The assumption that view == template is imho, too simplistic. It basically removes any reusability of the display logic, because now it's either in the controller or in the template itself. Of course this is an implementation detail but I consider the view to encapsulate the template and work above it.

    Pagination, as we've discussed already, is a good example. The logic is the same for every single view. Both the template and the model used can be swapped and the pagination logic reused.

    I have 3 views in my system which handle 99% of cases. Forms, Pagination and Generic (which I just assign variables/arrays/objects). I pass them a View Helper (in the Java sense rather than the Zend sense) and the template they're going to use.

  7. #82
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I did have a much longer reply but I don't want anyone to get lost in details so I'll try and keep it breif.

    The assumption that view == template is imho, too simplistic. It basically removes any reusability of the display logic, because now it's either in the controller or in the template itself. Of course this is an implementation detail but I consider the view to encapsulate the template and work above it.
    I disagree with the idea views in PHP as templates are to simplistic. After all simplicity is a beautiful thing. :P

    In a desktop application, View logic could be quite complex. HTML removes much of the burden from us, as we no longer (as PHP programmers) need to render anything, we simply provide declarative documents, send to browser and voila. The only time presentation logic should be required (IMHO) is when deciding whether to show or hide a segment of HTML, include an additional template, etc.

    I do agree that a View would encapsulate the template, Smarty is a good example of a View class (although most of us use PHP Alternative Syntax; SImple View class).

    However introducing a View class for a pager. I really see views as nothing more than trivial data containers. You could provide an API I suppose, to simplify the assignment of data variables calculated by a model, such as:

    $pager = new Pager_View();
    $pager->setPageCount($model->getPageCount());
    $pager->setPageIndex($_REQUEST['index']);
    $pager->setPageLength($_COOKIE['length']);

    echo $pager->render();

    The view would have it's template initialized in the ctor() and each method acts as simple getter/setter methods.

    Having said all this, I think where we might different is in perspective.

    From the point of view of a reusable pager control, it to has the triad of components, MVC.

    It's view, being a simple template. Only truly needs a few variables to render a nice pager navigation control:

    1. Index of active page
    2. Number of pages to show

    From here the model could calculate the array of paging indexes to show, based on properties you might provide:

    1. Do you want a balanced pager, for example if you have 25 pages and you only show 5 indexes at a time and your current page is 10, do you want output to be:

    Code:
    8 | 9 | 10 | 11 | 12
    2. Do you want a simplistic pager there the active page is always the first index, from the example above:

    Code:
    10 | 11 | 12 | 13 | 14
    The presentation logic in the template then would be checking whether to show an enabled or disabled (or whatever else)

    Code:
    HOME | PREV | NEXT | LAST
    In this case, the model provides the API, the view remains a simple template. The model does not touch any database directly but whatever table you wanted to paginate would need a model that implemented an interface like Pager.

    You could take this a step further an inject the model for the table or file listsings, etc that you wished to paginate, so using the pager, would be as simple as something like:

    PHP Code:
    // Class implements a pager interface 
    $model = new File_Listings('../some/path');

    // Injecting external model allows pager ctor()
    // to initialize it's own model with required variables
    $pager = new Pager($model);

    $pager->setPageIndex($_REQUEST['index']);
    $pager->setPageLength($_COOKIE['length']);

    echo 
    $pager->render(); 
    If you look into many windowing frameworks that each component (ie: list box, pager, data grid, etc) they all have their own MVC components and the views are relatively simple, no calculating, complex logic, they only decide what to display, where and maybe why? :P

    In old school applicaitons, you might have View calculations when dealing with the GDI. For instance I remember (trying) building a WYSIWYG editor and having to calculate where each character was to be positioned, adjusting line heights, etc. Working directly with the GDI this was nessecary as it did not make sense to go in the model, which would have coupled the already complex model (but possibly reusable) to the WIndows GDI API.

    In PHP we do not really have that concern, the View is somewhat implied and handled for us.

    I would say Views (especially complex Views) in PHP are probably a sign of over-engineering, IMO.

    Cheers,
    Alex
    The only constant in software is change itself

  8. #83
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    A lot of points there.

    Take a look at my post here:

    http://www.sitepoint.com/forums/show...5&postcount=29

    I included a very basic example of why repeatable view logic is useful. Otherwise you end up with repeated code in the controller.

    If the controller is interacting directly with the template, you end up with something like this (especially where something like smarty is used and you dont have any php code in your template).

    Take my previous example:

    PHP Code:
    $perPage 10;
    $page $_GET['page'];
    $users $this->user->find('lastlogin < "2009-05-10"'$perPage$perPage $page);
    $totalPages $this->user->count('lastlogin < "2009-05-10"') / $perPage;
    $this->template->assign('users'$users);
    $this->template->assign('page'$page); 
    Of course you still need logic to create the HTML for the page list.

    Something like (pseudo code)

    PHP Code:
    for ($i 1$i $totalPages$i++) {
    $this->template->append('page', array('num' => $i'class' => ($i == $page) ? 'current' '');

    This is all logic which is repeated anywhere you have pagination. If you create a view class as an intermediate step, this is reusable.

    With that intermediate step, all you need is something like I showed in my previous example. It removes all the display logic out of the controller. All the controller is now doing is setting up the view.

  9. #84
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by PCSpectra
    Anyways, I went slightly off-topic. I am more curious to see what others (including yourself) say about the number of additional view classes that need be introduced. In my applications, the view is typically nothing more than a Smarty instance or PHP alternative syntax custom class.

    I assign various values to the 'view' object, initialize with a template and render. I use an approach similar to that of Joomla when dealing with complex layouts, so modules like paging are composed of loosely coupled MVC components but you still retain that drop-in nature.
    That was a significant part of the debate in the previous pages. Whether the controller acting as a mediator nullifies MVC. In a traditional paradigm the view directly communicates with the model and doesn't rely on the controller to load it with data. I see why given the difference in environments that approach emerged but its not part of the flow of the traditional pattern.
    The only code I hate more than my own is everyone else's.

  10. #85
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    He's on my ignore list and I still can't help myself .

    Logic is lines of program code while data is groups of variables. Code is not data, therefore variables are not logic. Data may be transformed, processed or manipulated by logic, but it is not part of that logic.
    Every 18 year old CS student knows that this is bogus. Code and data are completely interchangeable.

    Code is data when it's not being interpreted. Data is code if it will be acted upon. The obvious examples are interpreters, compilers, configuration files, declarative languages, queries, bytecode, refactoring tools, blah, blah.

    The turing machine makes no distinction between code and data and neither does lambda calculus. Linux makes a distinction (code, data, stack segments) for kernel security and optimisation purposes, but all the PHP code we write will end up in either the data segment or the stack.

    As a bit of fun, here is the code for a list structure:
    PHP Code:
    function empty_list() {
        return function () { return 
    false; };
    }

    function 
    cons($head$tail) {
        return function (
    $op) use ($head$tail) {
            return 
    $op($head$tail);
        };
    }

    function 
    head($list) {
        return 
    $list(function ($head$tail) { return $head; });
    }

    function 
    tail($list) {
        return 
    $list(function ($head$tail) { return $tail; });

    The code above does not assign a single variable.

    The cons() function creates a list by prefixing an existing list with an item. So to create an single item list:
    PHP Code:
    $list cons('hello'empty_list()); 
    A two item list would be:
    PHP Code:
    $list cons('hello'cons('world'empty_list())); 
    You can verify that this works by plucking out the second item:
    PHP Code:
    print head(tail($list)); 
    You can even write a function to display the list like so...
    PHP Code:
    function show_list($list) {
        if (
    head($list)) {
            print 
    head($list) . ' ';
            
    show_list(tail($list));
        }

    So you can now go:
    PHP Code:
    show_list(cons('hello'cons('world'empty_list()))); 
    Where is the data? You could compile the above line of code on Linux without ever using malloc().

    Funky eh?

    yours, Marcus

    p.s. The example comes courtesy of Alonzo Church.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #86
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I disagree. Logic is lines of program code while data is groups of variables. Code is not data, therefore variables are not logic. Data may be transformed, processed or manipulated by logic, but it is not part of that logic.
    To work out the total number of pages you need to:
    -Query the database using a count(*) query with the same WHERE as you're using to fetch the current page
    -Calculate $totalRecords / $recordsPerPage

    This is logic. However you want argue this, it's not data. You're working something out. It's also only ever going to be used by the view. It's display logic.
    I disagree. Display logic is that program code which creates the HTML output, and that program code only exists in the View. Just because I have a piece of data which is passed from the Model to the View so that the data can be shown to the user does not mean that the data, when it is in the Model, is part of the display logic. It is data, not code.

    Quote Originally Posted by TomB View Post
    This is where you're very confused. You have things in the model which are related to a single view that may or may not ever use the model. This is wrong, plain and simple. You appear to be blinded by what your code can already do to see the disadvantages of it. Either that or you're trying to defend it because you don't want to admit when you're wrong.
    I have things in the Model whch can be used by any View, not just a single View. All possible variables are made available, and it's up to each individual View whether it uses all those variables or not. This is not confusing to me, nor does it have any obvious disadvantages.

  12. #87
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    I disagree. Display logic is that program code which creates the HTML output, and that program code only exists in the View. Just because I have a piece of data which is passed from the Model to the View so that the data can be shown to the user does not mean that the data, when it is in the Model, is part of the display logic. It is data, not code.
    Working out the "total number of pages" requires logic... why should the model have a concept of a "page"? It's no concern of the model how it may be displayed.

    I have things in the Model whch can be used by any View, not just a single View. All possible variables are made available, and it's up to each individual View whether it uses all those variables or not. This is not confusing to me, nor does it have any obvious disadvantages.
    They can be used by any view, but wont. Any logic regarding "pages" will only be used by the pagination view. What about your other views? Do you have logic related only to them in the model too? Your model could potentially become huge.

  13. #88
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Working out the "total number of pages" requires logic... why should the model have a concept of a "page"? It's no concern of the model how it may be displayed.
    Exactly. How the contents of the Model is actually displayed is determined by the code within the View where the HTML output is created. The Model does not create any HTML, therefore does not have any display logic. If a piece of logic does not create HTML, or is not in the View, then it is not display logic.

    Quote Originally Posted by TomB View Post
    They can be used by any view, but wont. Any logic regarding "pages" will only be used by the pagination view. What about your other views? Do you have logic related only to them in the model too? Your model could potentially become huge.
    You stated previously that any Model should have the capability of being used with any View. This is what I have achieved, yet you are saying that I'm still wrong. Please make your mind up.

  14. #89
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been told time and time again that my opinion that how the data moves between the Model, View and Controller is an implementation detail and not a "requirement" of MVC is totally wrong, and in a private message I have been directed to read How to use Model-View-Controller (MVC) as a "proper" definition of MVC.

    I took the time to read that document, and I found that it actually supports my argument. In the "Basic Details" section it states the following:
    In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task.
    • The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application.
    • The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate.
    • the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
    Notice that it concentrates on the responsibilities of the three components, and does nothing but "suggest" how the data may flow between them. Note the use of the term "usually" in the above list, and the phrase "commanding the model and/or the view to change as appropriate."

    In later sections it gives examples of how the flow may be implemented. In the section titled The Passive Model it states the following:
    The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model -- or the controller could specify to the view what has changed.
    The last sentence tells me that it is alowable for the Controller to pull data out of the Model and push it to the View.

    In the section titled The Model's Link to the Triad it states:
    Because only the model can track all changes to its state, the model must have some communication link to the view.
    The use of the word some tells me that this link can be implemented in a variety of ways, and is not restricted to a single way.

    In the section titled The View - Controller Link it states:
    both the view and the controller can send messages directly to each other
    This tells me that the flow of messages between the View and Controller may be two-way, and is not restricted to one-way.

    Note that these are nothing more than suggestions on how the data may be moved in certain circumstances. They are not rules which dictate how the data must be moved in all circumstances.

    I rest my case.

  15. #90
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    Notice that it concentrates on the responsibilities of the three components, and does nothing but "suggest" how the data may flow between them. Note the use of the term "usually" in the above list, and the phrase "commanding the model and/or the view to change as appropriate."

    To which you're inferring far too much. Sometimes the controller may need to request the models state. What it doesn't do is pass this on to the view. It may tell the view it needs to update but the view gets its data from the model... not the controller.


    The last sentence tells me that it is alowable for the Controller to pull data out of the Model and push it to the View.

    You stopped your quotation short in order to take it out of context. What it actually says is:

    So the view clearly must be informed of each change to the text so that it can update its display. Yet the model (which we will assume is an instance of String) need not take responsibility for communicating the changes to the view because these changes occur only by requests from the user. The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model
    The controller tells the view to update from the model It does not query the model and pass the result to the view... which was the only point of contention here.


    This tells me that the flow of messages between the View and Controller may be two-way, and is not restricted to one-way.
    Yet again, you're implying I've said otherwise. This is another straw man argument. I really wish you'd stop.

  16. #91
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by Tony Marston View Post
    I rest my case.
    I'll believe it when I see it.
    Per
    Everything
    works on a PowerPoint slide

  17. #92
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    Exactly. How the contents of the Model is actually displayed is determined by the code within the View where the HTML output is created. The Model does not create any HTML, therefore does not have any display logic. If a piece of logic does not create HTML, or is not in the View, then it is not display logic.


    You stated previously that any Model should have the capability of being used with any View. This is what I have achieved, yet you are saying that I'm still wrong. Please make your mind up.
    Please re-read what I have said more than once: If you need to redefine your model for the sole purpose of enabling the use of a view you have display logic -logic which is only required for the purpose of displaying the model in a very specific way-- in your model. This is display logic, you've just abstracted it to the point that it doesn't need to deal with outputting HTML. If it's used only by those functions which generate HTML it is clearly display logic. The fact that you've abstracted it to separate it out (which is most definitely not a bad thing) does not mean it belongs in the model.

    There is no argument here. I don't know why you continue with this.

    Yes. Your model should be usable by any view. It should have an API with generic methods to request its state. It should not, however, contain methods specific to a single view, that contain concepts (such as paginaton) which are related to how it might, one day, possibly be displayed.

    I really give up on this one. If you truly cannot see this now you never will. I have explained it over and over and you come back with no real retort other than "No I'm right!".

    Unless you can explain why the logic for working out the total number of available pages belongs in the model, your argument is void. I have provided reasons why it does not belong in the model. Perhaps it should, perhaps I'm missing something obvious. What you haven't done is actually address this issue, only skirt around it by changing the subject.

    It is certainly easier to put this logic in the model (especially when your view is not allowed to choose which data to display from the model...). This could well be a valid reason in smaller systems where you may not have many views, an extra function in the model (all models...) really isn't going to make any difference.

    My point is, you've done nothing to argue your own case, only argue against mine.

  18. #93
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Please re-read what I have said more than once: If you need to redefine your model for the sole purpose of enabling the use of a view you have display logic -logic which is only required for the purpose of displaying the model in a very specific way-- in your model. This is display logic, you've just abstracted it to the point that it doesn't need to deal with outputting HTML. If it's used only by those functions which generate HTML it is clearly display logic. The fact that you've abstracted it to separate it out (which is most definitely not a bad thing) does not mean it belongs in the model.
    I disagee. Display logic is restricted to that code which directly produces HTML output, and that code exists only in the View which incorporates any data it has been given into the HTML output. The production of data variables which are later incorporated into the HTML output is not display logic. If the Model does not contain any code which produces HTML output then it does not contain any display logic.

    Data is not logic, otherwise you could say that when the Model reads data from the database which is then passed to the View then the existence of this data in the Model constitutes "display logic".

  19. #94
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Unless you can explain why the logic for working out the total number of available pages belongs in the model, your argument is void

  20. #95
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Unless you can explain why the logic for working out the total number of available pages belongs in the model, your argument is void
    I disagree. I put the calculation of certain variables in places that I deem to be appropriate, and that is where I generate the values for limit and offset which I incorporate in the SQL query.

    This is not display logic as it does not directly generate any HTML. It is the production of HTML which defines diaply logic, not the production of data variables which may be incorporated into an HTML document.

  21. #96
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by TomB View Post
    Unless you can explain why the logic for working out the total number of available pages belongs in the model, your argument is void
    .

  22. #97
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Your model should be usable by any view. It should have an API with generic methods to request its state. It should not, however, contain methods specific to a single view, that contain concepts (such as paginaton) which are related to how it might, one day, possibly be displayed.
    You are nitpicking over trivialities. My Models can be used by any View, which means that they contain methods which can be used by any of those Views. If a particular method is not needed it is not called. Why should this be a problem?
    Quote Originally Posted by TomB View Post
    I really give up on this one. If you truly cannot see this now you never will. I have explained it over and over and you come back with no real retort other than "No I'm right!".
    Let's say that we're both right and leave it at that. As far as I am concerned they are just differences in implementation. My method works for me, your method works for you.

  23. #98
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Quote Originally Posted by Tony Marston
    Notice that it concentrates on the responsibilities of the three components, and does nothing but "suggest" how the data may flow between them. Note the use of the term "usually" in the above list, and the phrase "commanding the model and/or the view to change as appropriate."
    To which you're inferring far too much. Sometimes the controller may need to request the models state. What it doesn't do is pass this on to the view. It may tell the view it needs to update but the view gets its data from the model... not the controller.
    Do the words usually,and/or and may not indicate that these are options and not requirements? Where do you see always and must?

    Quote Originally Posted by TomB
    The controller tells the view to update from the model It does not query the model and pass the result to the view... which was the only point of contention here.
    The article I quoted distinctly said "or the controller could specify to the view what has changed." This allows the Controller to include any values which have changed. It does not state that the Controller cannot include any changed values, or that the View must obtain these values from the Model itself. If it doesn't explicitly say so then it's not a requirement.

    Look at the following statement:
    So the view clearly must be informed of each change to the text so that it can update its display. Yet the model (which we will assume is an instance of String) need not take responsibility for communicating the changes to the view because these changes occur only by requests from the user. The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model -- or the controller could specify to the view what has changed.
    The phrase "the view clearly must be informed of each change" does not specify how it is to be informed of any changes, so it is presumptuous of you to say othewise. The highlighted words do not indicate imperative statements, therefore they are options, not requirements.

  24. #99
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    You are nitpicking over trivialities. My Models can be used by any View, which means that they contain methods which can be used by any of those Views. If a particular method is not needed it is not called. Why should this be a problem?
    2 reasons:

    1) it puts logic in the model which has no reason to be in there.
    2) It breaks reusability. (Now this is not a real world example so it doesn't really make sense in this case but...) consider this:

    The requirements change: I need to add a view where the total number of pages are calculated in a different way.

    In some places I still need to use the old view. In one place I need to use the new one.

    In your system, I can't just extend the view and override the calculation function.

    I have to: add yet another method to my model base class, create an extension of the view to reference this new function in the model.

    You now have two functions in the view doing a similar job.

    Ok for pagination it's not really a problem as the calculation is unlikely to change, however apply this to handing other things, dates, ranges, currencies, etc and it starts to become more apparent.

    Once again though, you cannot provide reasoning in favour of putting it in the model. Nor can you provide reasoning in favour of keeping it out the model. I have provided both of these.

  25. #100
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    989
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    Do the words usually,and/or and may not indicate that these are options and not requirements? Where do you see always and must?
    This is irrelevant. It still states that the controller does not feed information to the view.


    The article I quoted distinctly said "or the controller could specify to the view what has changed." This allows the Controller to include any values which have changed. It does not state that the Controller cannot include any changed values, or that the View must obtain these values from the Model itself. If it doesn't explicitly say so then it's not a requirement.

    Look at the following statement:
    The phrase "the view clearly must be informed of each change" does not specify how it is to be informed of any changes, so it is presumptuous of you to say othewise. The highlighted words do not indicate imperative statements, therefore they are options, not requirements.
    Again you're inferring too much. When the controller tells the view what has changed, it is telling the view to fetch an updated piece of specific information from the model. It's not sending that data from the model to the view! There is no need! The view already has access to the model, why would the controller now act as a model?

    One of the earlier papers on the subject is this, unfortunately Steve Burbeck doesn't provide any references but he would almost certainly have been building on this (along with Goldberg and Robson, 1983)

    Quote Originally Posted by http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf
    The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary. Controllers may change their method of interaction depending on the new state of the model.
    Which agrees exactly with what Burbeck says. Only it does specify that views only ever inquire from the model, and not get passed data from the controller. You are inferring too much from the sentence "or the controller could specify to the view what has changed". Burbeck's wording here is perhaps a little vague, but there are plenty of other papers out there on the subject. Read a few of them. They all say the same thing... the view only ever gets data from the model. There is a reason for this: the model is the only place which holds data.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •