SitePoint Sponsor

User Tag List

Page 6 of 6 FirstFirst ... 23456
Results 126 to 142 of 142
  1. #126
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can understand how people are having problems with form validation, composite views, and all that other crap. Because most of these 'problems' arise when we define our application from the user's perspective, and they become completely befuddling when we combine these misconceptions with the ultimate anti-pattern in web applications; an MVC-based architecture.
    Right on the spot here. People have tried to solve the problem of form validation by looking at the representation of the form (the HTML form that the user sees in his/her browser), instead of looking at the logical meaning of a form: just a bunch of values that come in as $_POST or $_GET variables to PHP. To name a few of these solutions: PEAR QuickForm, Manuel Lemos' form package (can't think of the name right now, probably metaform ). These were designed with the representation of the form in mind and fail to adequately separate (which is not the same as 'customizable'!) the validation of this bunch of $_POST values from the displaying of a HTML form. Instead, these two distinct problem were tightly packaged into one almighty UberForm class because 'that makes it so easy for users to create forms'.

    MVC, or whatever frameworks us SitePointers propose that bear remarkable similarity to one another's not-quite-MVC-frameworks )), does provide the foundation for separating these two distinct problems. By foundation I mean the architecture, or layering, which supports separation of these problems.

    That is exactly the reason that form packages like the above mentioned are so hard, if not impossible, to 'integrate with MVC', simply because they were designed for a different purpose. A perfect example of how users pay the price for trying to use classes that were designed to do too much.

    If the concept of a page is meaningless, the the term Page Controller is confusing. Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions. (That, in turn, is a confusing term, but less so.) I can see now that Fowler, on whom I've been leaning heavily, is also confused and doesn't quite know what he's talking about. Neither does anyone else, I think.
    Agreed, Fowler is vague. Most of his PoEAA pattern names have so many possible interpretations ('Action', 'Controller', 'Page', 'Front'??) that they loose half of their meaning. What I believe is that he has the right idea but can't come up with an explicit (perhaps even formal) definition of that idea. Instead the idea is given implicitly in his descriptions.

    I believe the same is true of (not-quite)-MVC: it advocates some design principles that provide benefits to web apps, even if those benefits are not always visible on short term, but a formal definition of the pattern still has to be given.

    But if you think of it, all of the 'classic' Design Patterns [GoF] also started out as vague ideas of things that didn't turn out to be patterns until somebody formally described them.

    Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions.
    I know it's vague but that is what a Page Controller is all about: handling actions. They handle things that users want to do with an application (that is even more vague, hehe).

    Enough vagueness for now.

  2. #127
    ********* 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 Azmo
    These two terms both have strong ties with the user's experience created by following a chain of requests using a web browser. And while this is how the majority of our applications will be used, it has NO relation to the actual workings of web applications.
    I don't think that this is the right approach. A web application as defined by the business will be built around the conceptual view of...er...a view. This means that as business needs change the schisms will occour along these lines. If our own development model is cut along different lines we will be in trouble.

    If I had an ideal framework (on the control side) I would like to write code like this...
    PHP Code:
    Class MySite extends Site {
        function 
    MySite() {
            
    $this->Site();
            
    $this->addPanel(new MyMainMenu());
            
    $this->attachToPanel('main', new MyForum());
        }
    }

    class 
    MyForum extends Forum {
        function 
    MyForum() {
            
    $this->setEntryPoint(new ForumEntryPoint());
        }
    }

    class 
    ForumEntryPoint extends ? {
        function 
    ForumEntryPoint() {
            
    $this->addTemplates(...);
            
    $this->addPanel(new MyMainMenu);
            
    $this->addPanel(new ForumSignUp());
        }

    It would then be compiled into nice fast scripts . I would want to be able to change the navigation and plug things in with ease. That would be a controller worth having.

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

  3. #128
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    I'm afraid your architecture could be described as MVC anyway. Your Responses and Documents would be the View. Whatever you use to process the Request is your Controller. And presumably there's some data and possibly some business logic (even though you neglect to mention it), which would be the Model.
    Yup. You're absolutely right. It could be described as MVC. But there are thousands of approaches you can use to describe this problem, and the vast majority of them don't help you in any way. For example, I could describe my application in terms of Barbie dolls (only the Ken object is allowed to drive the MobileHome object, and Barbie doesn't talk to Ken, because he's an instance of the Sexist******* class). How does this describe the problem domain we're working with? Well, it doesn't, but we could describe our applications using these terms if we forced ourselves.

    And that's exactly the problem with MVC. You end up discussing things for ages, but it's never clear what anybody's talking about. And that's because the vocabulary doesn't fit the problem domain.

    Quote Originally Posted by dagfinn
    Then there's the Action. Fowler would place that as part of the Controller in the Front Controller pattern.

    You may not like it and you're free to reject it, but what I think is that it's good to be able to think of a design from different perspectives.
    My point is that some perspectives are not productive, or even counter-productive. IMO the whole notion of MVC is one of these dangerous approaches. You end up thinking in terms of the User's experience, not in terms of the actual application or problem domain.

    And, quite frankly, I couldn't care less about what Martin Fowler says. He's posted some interesting stuff on his website, and I'll definitely buy his refactoring book when I finally have some cash, but I'm quite pissed off at him and the GoF for spreading all that nonsense about design patterns. But that's a rant for a later date.
    Last edited by Azmo; Apr 17, 2004 at 06:21.

  4. #129
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    Yup. You're absolutely right. It could be described as MVC. But there are thousands of approaches you can use to describe this problem, and the vast majority of them don't help you in any way. For example, I could describe my application in terms of Barbie dolls (only the Ken object is allowed to do the drive the MobileHome object, and Barbie doesn't talk to Ken, because he's an instance of the Sexist******* class). How does this describe the problem domain we're working with? Well, it doesn't, but we could describe our applications using these terms if we forced ourselves.

    And that's exactly the problem with MVC. You end up discussing things for ages, but it's never clear what anybody's talking about. And that's because the vocabulary doesn't fit the problem domain.
    I think the problem is that the vocabulary that fits the problem domain hasn't quite been invented yet. MVC helps, but not enough. We're still groping for it.

    And, to add one more thing. I think our discussion demonstrates why MVC is helpful: looking at your design from the MVC perspective allows us to see that there are two important things you have not made explicit: 1) business logic and storage (Model) and 2) interpreting the HTTP request (Controller). So knowing about MVC helps me ask intelligent questions about your design if I want to learn about it.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  5. #130
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    There are HTTP GET requests and HTTP POST requests. GET expresses the intention to view something, POST expresses an intention to process something. Isn't that pretty close to the distinction you're making here?
    Almost - but a site search (ie a submitted form) is a request to view something.

    There might also be some processing if you were, for example, logging searches made on an ecommerce site for marketing info.

    Actually, ANY request to view something could also involve various processing tasks (email notification, file logging - whatever).

    I think MVC fails when you try to use the Controller to manage the entire app. You might instead embed MVC, ie the MVC Controller is passed whatever it needs to get page vars from a model layer, and print them in a view layer (a post-client output email notification would embed another MVC routine to print emails, and so on for file writing or anything else read by a person as opposed to a machine). It does NOT attempt to do anything else. Many descriptions of the MVC Controller would seem to drive a coach and horses through the principle of RDD.

    The View (or whatever other name has less baggage) and Model layering is important but I think it's best to forget all about the Controller and manage the application workflow (pre-client tasks --> client output --> post client tasks) as you see fit .

  6. #131
    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)
    Quote Originally Posted by McGruff
    Almost - but a site search (ie a submitted form) is a request to view something.
    For which you could:
    a) as you were thinking - have the form post
    b) have the <form method="get"> and we are back to a GET request
    c) have a post to an actions, uses header('Location: ...); to get to a view

    I tend to use c becuase I primarily develop for an Intranet environment that is low latency, and this eliminated the "refresh post message" that bugs my users so much.

  7. #132
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    For which you could:
    a) as you were thinking - have the form post
    b) have the <form method="get"> and we are back to a GET request
    c) have a post to an actions, uses header('Location: ...); to get to a view

    I tend to use c becuase I primarily develop for an Intranet environment that is low latency, and this eliminated the "refresh post message" that bugs my users so much.
    The search engines tend to use b) and I think this is the most logical thing to do. But it's true--you can choose to use GET or POST for almost anything. I'm not trying to make any rules about implementation; this is conceptual thinking.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  8. #133
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    I think the problem is that the vocabulary that fits the problem domain hasn't quite been invented yet. MVC helps, but not enough. We're still groping for it.
    But MVC is almost always presented as 'the way' to interpret and discuss web applications. It has become like dogma in a way. If you're still searching for the right vocabulary, you need to be willing to drop or replace definitions that don't fit. Hardly any attempts to do this seen to have been made.

    MVC also comes with a set of rules which really don't work in web applications. The terminology is confusing, extremely limited, inappropriate, and misleading. Sure it can help in some way, but so can Barbie. I would prefer to see people use neither of these, and use a vocabulary that comes more naturally. People have been talking about Actions, Blocks, and Documents on these forums. Everyone knows what they are (I don't even have to explain these terms to people who haven't read a tutorial or something). But 'View', 'Model', and 'Controller' are unclear to quite a number of people, and as they read more about the MVC pattern, they often gain confusion rather than insight or understanding.

    Many problems we face simply can't be solved if you allow yourself to remain restricted by the MVC straight-jacket. Things like form validation and composite views become alarmingly easy to solve once you accept that there's a different way of viewing things. I should know, because I've solved them.

    Quote Originally Posted by dagfinn
    And, to add one more thing. I think our discussion demonstrates why MVC is helpful: looking at your design from the MVC perspective allows us to see that there are two important things you have not made explicit: 1) business logic and storage (Model) and 2) interpreting the HTTP request (Controller). So knowing about MVC helps me ask intelligent questions about your design if I want to learn about it.
    I haven't given you any details of my design yet. I'm just mentioning the vocabulary I use to understand the problem domain:

    Controller: Action, Parameter, Block

    Model: Data, DataSource, DataManager

    View: DocumentComposer, Document, Content, Response, Template, DocType

    Other: Authenticator, Authorizer, Request, Client, Server, User

    This list isn't complete, but you can already see I can use more terms to describe the problem than MVC would allow, without having to resort to derivates like 'subMVC' and such.

    And let's not forget I'm not the one with the problem here.

  9. #134
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't given you any details of my design yet.
    Are you going to ?

  10. #135
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Are you going to ?
    I'm planning to, but first I need to write some documentation for the core classes, register the domain, and GPL the code.
    Last edited by Azmo; Apr 17, 2004 at 06:23.

  11. #136
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hurry up then. Please

  12. #137
    SitePoint Evangelist cyngon's Avatar
    Join Date
    Aug 2001
    Location
    Livonia, MI, USA
    Posts
    513
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Azmo
    I'm planning to, but first I need to write some documentation for the core classes, register the domain, and GPL the code.
    I'm quite intrigued by the concepts you discussed, and I'd like to take a look at your architecture. Would it be possible for you to make your code available now so those of us with interest can start tinkering?

    I realize the tendency to want to hold off until you can get the documentation in good order and the like, but I believe the "release early, release often" mantra applies here.

    If your worried about having to field lots of questions that arise because the code isn't documented yet, you could handle that with appropriatly placed warnings of the code's pre-Alphaness. Perhaps consider making it available via CVS or other version control system instead of a zip download.

    If you still don't feel ready for a controlled, public, proof-of-concept release, would you please consider e-mailing the code to those of us following your developments that are interested?

    Thanks.

  13. #138
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Would you mind having to wait two more months? By that time I'll have some of the basic functionality ready and stable (user registration, login, permissions, BBCode, ...). I'm also still working on a licensing solution, as the GPL would probably cause me a lot of headaches: some of my customers don't want the features I write for them to be released under the GPL, and I myself am not too keen to hand out commercial software for free either. (I've recently started my own company, and I sort of need to make money. )

    I also need to invest quite a bit of time in a testing suite, as I am about to remove a number of features from the framework, among them the debugging system I added about a month ago. Things were starting to get so complex even I had problems understanding what was going on. Screw 'mixins', screw 'aspects', and screw 'namespaces': simplicity ownz.

    I could email you the current framework, but I'd rather wait until I have some real functionality to display, so people can fool around with it, and get an idea how this thing is supposed to work (the framework consists of ~7 classes, and it doesn't really give you any idea of how the application built on top of it works).

    Would it be OK if I announced the first pe-alpha release of my framework in a topic on this forum? At that point I could even post the framework's code here (along with whichever licence I decide to use ).

  14. #139
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, we can wait

    But not too long mind, we get bored very easily As for profiting, fair game, we all need to make a living, to avoid upsetting your clients, you could just release the basics.

    That would be enough for us all to get an idea of how your framework works, and why it works the way it does, etc. Thus, your protecting your own interests as well

  15. #140
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Really looking forward to getting my hands on this!
    Garcia

  16. #141
    SitePoint Zealot
    Join Date
    Sep 2003
    Location
    Melbourne, Victoria, Australia
    Posts
    115
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Cool

    So, 2 months is up! Have I missed it?

    Af.

  17. #142
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Afro Boy
    So, 2 months is up! Have I missed it?

    Af.


    I totally didn't expect anyone to still show an interest in my work after this time. And yes, you did miss it

    I posted the core source code in this topic. Since then I haven't had a lot of time for development, but recently I did make some serious modifications to the structure and ideas behind the framework/application (no more components, just modules). I'll post the new source in the somersault thread when I've had some time to clean it up. Right now I'm kinda busy setting up the new company fileserver.


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
  •