SitePoint Sponsor

User Tag List

Page 2 of 6 FirstFirst 123456 LastLast
Results 26 to 50 of 138
  1. #26
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  2. #27
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  3. #28
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Christopher

  4. #29
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, I've done some thinking, and I believe I have a reply to McGruff.

    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 :
    PHP Code:
    class MyUpdateModelAction extends Action 

        function 
    bind() 
        {
            
    $model =& new MyModel();
            if (
    $model->update()) {
                
    $this->view =& new Forward('?action=MyUpdateSuccessAction');
            } else {
                
    $this->view =& new Forward('?action=MyUpdateFailedAction');
            }
        }

    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?
    Pretty straightforward really, but here goes (removed comments):
    PHP Code:
    class ListIterator
    {
        var 
    $_data=array();
        var 
    $index=0;

        function 
    ListIterator(&$data)
        {
            if (!
    is_array($data)) {
                
    trigger_error("Wrong parameter given. Array expected."E_USER_ERROR);
            }
            
    $this->_data =& $data;
            
    $this->index 0;
        }

        function 
    hasNext()
        {
            return 
    $this->index < ($this->count()-1);
        }

        function 
    hasPrev()
        {
            return 
    $this->index 1;
        }

        function 
    advance()
        {
            if (!
    $this->hasNext())
                return 
    false;
            ++
    $this->index;
            return 
    true;
        }

        function 
    retreat()
        {
            if (
    $this->index 1)
                return 
    false;
            --
    $this->index;
            return 
    true;
        }

        function & 
    next()
        {
            if (!
    $this->advance())
                return 
    false;
            return 
    $this->current();
        }

        function & 
    prev()
        {
            if (!
    $this->retreat())
                return 
    false;
            return 
    $this->current();
        }

        function & 
    reset()
        {
            
    $this->index 0;
            return 
    $this->current();
        }

        function & 
    end()
        {
            
    $this->index $this->count()-1;
            return 
    $this->current();
        }

        function 
    count()
        {
            return 
    count($this->_data);
        }

        function & 
    current()
        {
            if (
    $this->index >= $this->count() || $this->index 0) return null;
            if (
    $this->count() == 0) return null;
            return 
    $this->_data[$this->index];
        }

        function 
    push(&$value$refMode=null)
        {
            if (
    is_null($refMode)) {
                
    $refMode is_object($value);
            }
            if (
    $refMode) {
                
    $this->_data[count($this->_data)] =& $value;
            } else {
                
    $this->_data[count($this->_data)] = $value;
            }
        }


  6. #31
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Germany
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation Back to the main problem...

    I found some interesting links about the Composite View; it was a good suggestion to look after that!

    Core J2EE Patterns - Composite View

    Blueprints - Composite View

    They talk about a template (represents a complex page layout) which include subsections like banner, footer, some boxes …

    HTML Code:
    <html>
    <body>
    <jsp:include 
      page="/jsp/CompositeView/javabean/banner.html" 
      flush="true"/> 
    <table width="100%">
      <tr align="left" valign="middle">
        <td width="20%">
        <jsp:include 
        page="/jsp/CompositeView/javabean/ProfilePane.jsp" 
          flush="true"/> 
        </td>
        <td width="70%" align="center">
        <jsp:include 
          page="/jsp/CompositeView/javabean/mainpanel.jsp" 
          flush="true"/> 
        </td>
      </tr>
    </table>
    <jsp:include 
      page="/jsp/CompositeView/javabean/footer.html" 
        flush="true"/> 
    </body>
    </html>
    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?!

    Core J2EE Patterns - View Helper

    To my opinion the Proton approach is not so complex like the kyber approach. I would prefer Protons suggestion.

    My question now, what do you think about my theories? Have I misunderstood everything or I am right?

    Perhaps we could create some easy to understand sample code for the Proton approach? :-)

    Greetings from Germany
    -----------------
    http://www.xbox-profis.de :: The german Xbox Community

  7. #32
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If I understand you right kyber, you said the data is assembled by subactions, so every subaction matches one subsection?!
    Yes. And as I put it in my previous post (witch you didn't read, because we posted simultaneously), the class that I call Action may in this case be a View.

    To my opinion the Proton approach is not so complex like the kyber approach. I would prefer Protons suggestion.
    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.

  8. #33
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  9. #34
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think my take is a kyberfabrikken / Proton mix

    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')
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  10. #35
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    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.

    Quote 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.

  11. #36
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    I believe it's actually more of a domain layer (model) object, according to Fowler. I haven't got the book at hand here, otherwise I would look it up.

  12. #37
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

    I get the idea, but I'll argue that the ViewHelper belongs to the Controller-layer.
    I'd have to beg to differ Kyber... A View Helper can be seen as being a part of a View, in the tradiontal sense of what a View is, but in a few cases I've seen, this isn't the case.

    There had been no presentation at all in the View Helpers.

  13. #38
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe it's actually more of a domain layer (model) object
    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 ?

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Admittedly - I stay corrected.
    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.

    Recursion has never been my strong point

  15. #40
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To add more confusion to this discussion, or maybe to help give a clearer picture, I've quoted from an article on MVC from object arts dot com,

    What we really want, though, is a tight coupling between AM and View but a loose coupling between Domain Model and View. Rotate the triad slightly and we get the Model-View-Presenter framework.
    Where AM is an Application Model.

    http://www.object-arts.com/Education...tterns/MVP.htm

  16. #41
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    I've yet to see any example that implies a View Helper has any involvement with a Controller [MVC]
    That's what I meant to say. You're right.

    Quote Originally Posted by Dr Livingston
    Anyways, to answer your question I stated earlier the Composite View?
    Obviously - but how does the concrete implementation look ? code-samples please

    Quote Originally Posted by Dr Livingston
    Yup ... I read that as well, and I think it's a good point to keep in mind the distinguishing between DM and AM.
    By the way : http://msdn.microsoft.com/architectu...tml/DesMVC.asp


    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.:
    PHP Code:
    class DisplayArticleAction extends Action
    {
        function 
    bind()
        {
            
    $this->view =& new Template("article.tmpl");
            
    $this->view->setValue("title""Title of the Article");
            
    $this->view->setValue("body""Lorem Ipsum ...");
        }

        function & 
    getOuterAction()
        {
            if (
    rand(0,1) == 1) {
                return new 
    MainSectionAction();
            } else {
                return new 
    AlternativeSectionAction();
            }
        }


  17. #42
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Watch my upcoming thread "To hopefully clear up some confusion about 'To hopefully clear up some MVC confusion...' "
    Just kidding

  18. #43
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but how does the concrete implementation look
    Nothing concrete at the moment, just pieces of script flying all over the place For a rough idea of what I have, refer back to the thread 'Using Composites' I started as I'm tearing that apart.

    Once I do have something of worth, I will post the script on these forums, but I've not had the time recently to look into it more.

    As I've said, the problem I have is recursion over the structure. What I need is a Walker to walk through it but the script I posted (Using Compsites) has a bug which I've yet to solve

  19. #44
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

    Quote 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.

  20. #45
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello,

    code-samples please
    Still a bit thin on the ground though currently I'm looking at an XPATH solution, here is an idea?

    Code:
    <?xml version="1.0" encoding="iso-8859-1"?>
    <templates>
    <!-- a very typical example of a webpage structure -->
    	<template id="page">
    		<template id="header" parent="page">
    			<template id="searchbox" parent="header" />
    		</template>
    		<template id="body" parent="page">
    			<template id="leftside" parent="body">
    				<template id="news" parent="leftside" />
    				<template id="polls" parent="leftside" />
    				<template id="signon" parent="leftside" />
    			</template>
    			<template id="rightside" parent="body">
    				<template id="breadbrumbs" parent="rightside" />
    				<template id="content" parent="rightside">
    					<template id="menu" parent="content" />
    					<template id="document" parent="content" />
    				</template>
    			</template>
    		</template>
    		<template id="footer" parent="page" />
    	</template>
    </templates>
    The XML is kept simple at the moment, using attributes for labeling but using nodes shouldn't be a problem, ie

    Code:
    ...
    <template id="blahblahblah" parent="blahblahblah">
    <url>segment-template.tpl</url>
    <handler>../handlers/segment-controller.php</handler>
    ...
    </template>
    ...
    Some script, which I might add I'm embarrassed to post

    PHP Code:
    $dom = new DomDocument;
        
    $dom -> load'recursion.xml' );
        
        
    $xp = new DomXPath$dom );
        
    $fragments $xp -> query"//template[@id='page']" );
        
    // DOMNodeList

        
    $id $fragments -> item) -> getAttribute'id' );
        
    $tmp[$id] = array();
        
        
    $fragments $xp -> query"//template[@parent='".$id."']" );
        foreach( 
    $fragments as $fragment ) {
            
    $node $fragment -> getAttribute'id' ); echo( $node.'<br />' );
        } 
    Would certainly welcome suggestions from SleapEasy btw (hint hint)

  21. #46
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Germany
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Post Still searching for ...

    ... the perfect solution (a complex page with MVC in php5) ...

    At the moment I study some interesting things:


    A sample shopping application:

    http://www.asp.net/IBS_Store/
    => Take a look at the documentation ;-) :
    http://www.asp.net/IBS_Store/docs/docs.htm



    Design and Implementation Guidelines for Web Clients

    Frontcontroller Pattern

    ...

    Perhaps "Using page inheritance" is a solution approach ?!
    -----------------
    http://www.xbox-profis.de :: The german Xbox Community

  22. #47
    SitePoint Member
    Join Date
    Aug 2004
    Location
    Germany
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    and still searching ...

    Another solution, but very complex:

    HMVC: The layered pattern for developing strong client tiers





    What do you think about that? Sounds like a nice solution?

    Perhaps we could translate that into a nice and small PHP example in order to discuss that?!

    Do you think such an approach is usefull for a web application?

    (It looks a littlebit like Kybers Actionchaining?!)
    -----------------
    http://www.xbox-profis.de :: The german Xbox Community

  23. #48
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think this is the approach that WACT takes with a hierarchy of controllers. It would be interesting to see a basic Application Controller implementation with parent/child capability.
    Christopher

  24. #49
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sambox
    PHP Code:
    class FrontController
    {
        function 
    run()
        {
            switch (
    $_GET['page'])
            {
                case 
    'add':
                    
    $command = new UserAddCommand;
                    break;

                case 
    'edit':
                    
    $command = new UserEditCommand;
                    break;

                case 
    'list':
                    
    $command = new UserListCommand;
                    break;
            }

            
    $command->execute();
            
    $view $command->getView();
            
    $view->render();
        }

    Just refactored a little:

    PHP Code:
    class FrontController
    {
        function 
    run()
        {
            
    $command getCommand($_GET['page']);
            
    $command->execute();

            
    $view $command->getView();
            
    $view->render();
        }

        function 
    getCommand($command) {
            switch (
    $command)
            {
                case 
    'add':  return new UserAddCommand;
                case 
    'edit': return new UserEditCommand;
                case 
    'list': return new UserListCommand;
            }
        }


    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.

    Douglas
    Hello World

  25. #50
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    ...
    function 
    getCommand($command) {
            switch (
    $command)
            {
                case 
    'add':  return new UserAddCommand;
                case 
    'edit': return new UserEditCommand;
                case 
    'list': return new UserListCommand;
            }
        } 
    ... 
    This part still could be refactored as SWITCH is a bad code smell


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
  •