SitePoint Sponsor

User Tag List

Page 15 of 16 FirstFirst ... 5111213141516 LastLast
Results 351 to 375 of 397
  1. #351
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I might have missed a naming discussion a while back but do you think the InputController should be renamed "Request"? The current name kind of threw me initially until I realised what it was.

    I'd make validateRequest and filterRequest "private" (the php4 way prefixed with an underscore...) if that isn't already your intention.

    Also - these things are a matter of personal preference - I'd rename processRequest to isValid. Then you have:

    PHP Code:
       // set everything up..
       
       
    if($request->isValid()) {
           
    // continue with the script
       
    } else {
           
    // bad syntax 400 page
       


  2. #352
    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)
    The Front Controller is a pretty straightforward design, and we have managed to settle on a more or less consensus about how to implement it in php. We have had discussions about which level of complexity to support (should it add filters for example), but if we decide on a given feature-set and complexity-level, I think we would always end up with more or less the same result. I'm afraid that the Application Controller isn't as easy a task.
    A few hundred posts back we had a discussion about what exactly this term covers. I think we're still not in the clear here. Could we perhaps try to find a clear definition of what an Application Controller is, before moving on ? If anybody has a good article we might take offset in that ?

    Anyway - regarding forms I agree that filtering and validation are two basic mechanisms that are truly useful in as good as all applications. As I see it, they are a set of utilities that are used in conjunction with the concept of a form. For most applications it makes sense to use the form as a pivot for a set of classes, which it seems to me is more or less what you are talking about, when you say ApplicationController ?

    I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.

    The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer. The relationship between FormHandler<->Command may be through inheritance (the programmer would extend FormHandler and implement a hook-method) or through composition (the programmer would pass the Command as a parameter to the FormHandler)

    We may choose to let the FormHandler actually decide between displaying a view (FormView) or dispatching to the Command, but I prefer to leave this to the FrontController. The FormView would thus be an entrypoint when displaying the form, while the FormHandler would be the entrypoint for the submit of the form. Depending on the validity of the submit, the FormHandler may either execute the Command or redirect back to the FormView.

    Is this an overall model we can decide on ?
    Is there anything more to the concept ApplicationController than this ? If so - what ?

  3. #353
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It may be nice to branch off into a seperate thread to discuss the Application Controller -- considering this thread was really only concerned with a Front Controller. That way any comments about the Front Controller can be seperated from the Application Controller, and people can become aware that the Application Controller is being developed, instead of maybe getting lost in the development of the Front Controller leading up to it.

    What do you think?

    Oh, and excellent work guys!

  4. #354
    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 Ryan Wray
    What do you think?
    I agree.

  5. #355
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The Front Controller is a pretty straightforward design, and we have managed to settle on a more or less consensus about how to implement it in php. We have had discussions about which level of complexity to support (should it add filters for example), but if we decide on a given feature-set and complexity-level, I think we would always end up with more or less the same result. I'm afraid that the Application Controller isn't as easy a task.

    A few hundred posts back we had a discussion about what exactly this term covers. I think we're still not in the clear here. Could we perhaps try to find a clear definition of what an Application Controller is, before moving on ? If anybody has a good article we might take offset in that ?
    I don't know if there is a good definition, but I get the sense that an Application Controller can handle pages, forms and groups of relateed pages and forms. This is different from a controller that manages only one or a few predefined states like a Form Controller. As I have said, I think a Form Controller is an example of as specific case Application Controller.
    Quote Originally Posted by kyberfabrikken
    Anyway - regarding forms I agree that filtering and validation are two basic mechanisms that are truly useful in as good as all applications. As I see it, they are a set of utilities that are used in conjunction with the concept of a form. For most applications it makes sense to use the form as a pivot for a set of classes, which it seems to me is more or less what you are talking about, when you say ApplicationController ?
    I think where a Form Controller focuses specifically working like HTML forms work, an Application Controller treats a form and any other page (or groups of pages) as the same thing -- a collection of related states.

    Quote Originally Posted by kyberfabrikken
    I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.
    If you want to implement MVC using these parts it should be easy to do, but I'm not sure it should be required. The Skeleton Front Controller doesn't force MVC, but it can help implement it.

    There was some discussion whether to implement a Form Controller first as the problem was familiar to most people and then expand it to an Application Controller.
    Christopher

  6. #356
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.

    The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer. The relationship between FormHandler<->Command may be through inheritance (the programmer would extend FormHandler and implement a hook-method) or through composition (the programmer would pass the Command as a parameter to the FormHandler)
    I think if we built a Form Controller it should be probably create some sort of View Helper object that the View would use to get the form values, error messages, etc. You could consider it the "Form Model" as well I guess. I don't think the Form Controller should know anything about the View other than the minimum any controller would need to know.

    As for the Model, it would probably be good to define a Gateway interface as the "Form Model". We could supply a simple Table Data Gateway that would be sufficient for forms that just do SELECT, UPDATE, INSERT on a single table.

    This would probably be a similar configuration to if you used the Application Controller to manage a form, so these related classes (for the example) could also be used for that.
    Quote Originally Posted by kyberfabrikken
    We may choose to let the FormHandler actually decide between displaying a view (FormView) or dispatching to the Command, but I prefer to leave this to the FrontController. The FormView would thus be an entrypoint when displaying the form, while the FormHandler would be the entrypoint for the submit of the form. Depending on the validity of the submit, the FormHandler may either execute the Command or redirect back to the FormView.
    I think the Front Controller would dispatch the Form or Application Controller, which would then dispatch the appropriate "handler". As I recall we ended up calling any Command that has the method: execute($request, $response) is called a Handler. Our Front Controller ended up being a Handler that dispatched Handlers, and the other Controllers will probably be the same.
    Christopher

  7. #357
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer.
    I don't really see the point of creating a FormModel that's distinct from an ordinary model; the latter should contain all the information the FormHandler needs to validate the form, since the model should be validating the data it recieves in the first place.

  8. #358
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I don't really see the point of creating a FormModel that's distinct from an ordinary model; the latter should contain all the information the FormHandler needs to validate the form, since the model should be validating the data it recieves in the first place.
    There are a couple of reasons why we might want to create a "FormModel". One might be as a Value Object to use while controlling the form until there are no errors. Then the FormModel would be used as the source of data for the Model. For example the FormModel might maintain data in the session while the Model used a database.

    Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. My experience is that it certainly make it easier for single table forms to only need to provide the table name, key field, field names, etc. to a generic Table Data Gateway than to rewite it every time. Plus it makes it so you can describe the table easily in data to create a RoR style CRUD interfaces.
    Christopher

  9. #359
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    I might have missed a naming discussion a while back but do you think the InputController should be renamed "Request"? The current name kind of threw me initially until I realised what it was.
    Well I don't think it is done yet. What we have so far is a Request Processer which is a pretty handy piece of code that we may want to split out later to use standalone. But an Input Controller does a little bit more. The problem is: I'm not exactly sure what that "more" is because ultimately it is the common code refactored out of Controllers that use the Input Controller as a front-end.

    Overrunner and I were discussing building a Form Controller next to show an example that people were familiar with. Most of the coders here have probably written some sort of Form Controller. That might give us a hint on both common code and the direction for an Application Controller.
    Quote Originally Posted by McGruff
    I'd make validateRequest and filterRequest "private" (the php4 way prefixed with an underscore...) if that isn't already your intention.
    As this code will probably be used/inherited by another controller, I thought there might be the possiblity that one might want to put some code between the two calls. Plus I think if we ever get to the end of the "skeleton script", we should go back, refactor, standardize naming, etc. and then do a proper PHP5 version.
    Christopher

  10. #360
    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 arborint
    There are a couple of reasons why we might want to create a "FormModel". (...) For example the FormModel might maintain data in the session while the Model used a database.

    Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. (...)
    And it may act as a pseudo-model for forms, where there really isn't an underlying model. The FormModel may also describe specifics to the form, such as rules/filters and field editing-types. (Should a TEXT column be edited through a <textarea> or through some wysiwyg gizmo, for example).

    Either way ... can't we keep the discussion in the thread I put up yesterday. (here)

  11. #361
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    And it may act as a pseudo-model for forms, where there really isn't an underlying model. The FormModel may also describe specifics to the form, such as rules/filters and field editing-types. (Should a TEXT column be edited through a <textarea> or through some wysiwyg gizmo, for example).
    Field editing types are a bad example, IMO, because that definitely belongs in the View layer. That's sort of my issue with the FormModel concept in general; In my view of MVC, models are never tied to specific views. If the view needs something that it can't get from the model, it should use a helper class.

    Quote Originally Posted by arborint
    There are a couple of reasons why we might want to create a "FormModel". One might be as a Value Object to use while controlling the form until there are no errors. Then the FormModel would be used as the source of data for the Model. For example the FormModel might maintain data in the session while the Model used a database.
    This is a good point, but there a different ways of dealing with this; one would be to have the model use different data mappers for persisting to different sources. That way the model could maintain data in the session until there are no more errors, then store it in the database.

    Quote Originally Posted by arborint
    Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. My experience is that it certainly make it easier for single table forms to only need to provide the table name, key field, field names, etc. to a generic Table Data Gateway than to rewite it every time. Plus it makes it so you can describe the table easily in data to create a RoR style CRUD interfaces.
    I'm not sure exactly what you mean by rewrite it every time? Regardless, I'm very reticent to provide multiple ways of accessing the same data; in my experience, I've never come across a problem whose best solution was to do so. In any case, I do think we need to work on the ApplicationController before getting into how the model layer will work.

  12. #362
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    but there a different ways of dealing with this; one would be to have the model use different data mappers for persisting to different sources. That way the model could maintain data in the session until there are no more errors, then store it in the database.
    True, but we need to provide some generic capability for things like an email form where the model is an Emailer class and there is no database.
    Quote Originally Posted by 33degrees
    I'm not sure exactly what you mean by rewrite it every time? Regardless, I'm very reticent to provide multiple ways of accessing the same data; in my experience, I've never come across a problem whose best solution was to do so. In any case, I do think we need to work on the ApplicationController before getting into how the model layer will work.
    I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.
    Christopher

  13. #363
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.
    I forget myself when it comes to domain design patterns, so excuse me, but what I would do if there was only the one database table, would be to have a generic object which would deal with the Create, Read, Update and Delete.

    This generic object would therefore, use Reflection to access the properties (already these properties would hold the data from a form prior to being passed to the generic object) from another object, instead of using Inheritance as a solution, no?

    I like using Reflection btw

  14. #364
    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 33degrees
    Field editing types are a bad example, IMO, because that definitely belongs in the View layer. That's sort of my issue with the FormModel concept in general; In my view of MVC, models are never tied to specific views. If the view needs something that it can't get from the model, it should use a helper class.
    The FormModel, as I described it, would be an internal Model, not the application-wide model. The MVC paradigm would in this case apply to the form (In an abstract sense), rather than the whole application. So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).
    Anyway - rather than taking it from the bottom and up, I'd rather see a discussion on the overall structure of this so-called ApplicationController, than the implementation-specifics. What exactly is it we're dealing with here?

    Quote Originally Posted by kyberfabrikken
    Either way ... can't we keep the discussion in the thread I put up yesterday. (here)
    Seriously ?

  15. #365
    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 kyberfabrikken
    So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).
    Sure it made sense

    Example: you want ViewHelpers to make <input> fields which get data from the Models. Error message helpers can then just get data from the Models in the same way, so it fits to put validation in the Models.

    Douglas
    Hello World

  16. #366
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The FormModel, as I described it, would be an internal Model, not the application-wide model. The MVC paradigm would in this case apply to the form (In an abstract sense), rather than the whole application. So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).
    I would say that yes, it's a ViewHelper, and it should be called a ViewHelper

    Quote Originally Posted by arborint
    True, but we need to provide some generic capability for things like an email form where the model is an Emailer class and there is no database.
    Nothing wrong with having an Email model that doesn't save to a database, this is precisely why I suggest using DataMappers to do the persistance instead of using the ActiveRecord approach. What I'm against is having, say, a CustomerModel as well as a CustomerFormModel, the latter of which is used only by the CustomerForm class.

    Quote Originally Posted by arborint
    I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.
    The potential need for this approach really depends on how the Model layer is implemented, and I agree with kyberfabrikken that now is not the time to be looking into this. Let's keep working from the top down.

  17. #367
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    I forget myself when it comes to domain design patterns, so excuse me, but what I would do if there was only the one database table, would be to have a generic object which would deal with the Create, Read, Update and Delete.
    That's what I was proposing, a simple Table Data Gateway class that would be the Model for the simple single table Create, Read, Update and Delete case (which are pretty common). Just inherit and go.
    Christopher

  18. #368
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I would say that yes, it's a ViewHelper, and it should be called a ViewHelper
    I agree it is more a ViewHelper than a FormModel (which I noted originally).
    Quote Originally Posted by 33degrees
    Nothing wrong with having an Email model that doesn't save to a database, this is precisely why I suggest using DataMappers to do the persistance instead of using the ActiveRecord approach. What I'm against is having, say, a CustomerModel as well as a CustomerFormModel, the latter of which is used only by the CustomerForm class.

    The potential need for this approach really depends on how the Model layer is implemented, and I agree with kyberfabrikken that now is not the time to be looking into this. Let's keep working from the top down.
    The only reason to mention them is that we have been doing examples for people to see how things work. That's easy for a Front Controller that just dispatches other code, but now we will need some simple Model implementations to provide as examples.
    Christopher

  19. #369
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey Overrunner (or anyone else interested) did you take a look a last round of the code here? Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone? I guess I am looking for any further design changes not small stylistic ones.

    Are these Rule/FIlter classes and the FilterChain/Validator style request processing the right way to go? Or are there better ways to solve this problem?

    I know I will start using Overrunners Rule classes rather than my own because the ability to have Match rules it a definite improvement over the non-Datasource ones I currently use. I have found places (e.g. password, verify_password) where it will improve the code.
    Christopher

  20. #370
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Hey Overrunner (or anyone else interested) did you take a look a last round of the code here? Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone? I guess I am looking for any further design changes not small stylistic ones.
    Yeah. (I'd like to see InputFilter, InputRule etc instead, though.)

    Are we moving to the new thread or staying here? I'd like us to separate the ApplicationController discussion from the FrontController one, just in order to be organized.

  21. #371
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone?
    Yepp. But I think you should let the concrete Filters inherit from the base class, otherwise the base class would be pretty much useless
    Quote Originally Posted by Ezku
    Are we moving to the new thread or staying here? I'd like us to separate the ApplicationController discussion from the FrontController one, just in order to be organized.
    I think we should move the discussion to the new thread here

  22. #372
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Either way ... can't we keep the discussion in the thread I put up yesterday.
    The response sounds familiar

  23. #373
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    The response sounds familiar
    If Overrunner and Ezku want to move it then let's move it. They have been actively involved.
    Christopher

  24. #374
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is old, but I just noticed it.

    Quote Originally Posted by sweatje
    PHP Code:
    function getTime() {
        
    $microtime microtime();
        
    $microtime explode(" "$microtime);
        
    $microtime $microtime[1] + $microtime[0];
        return 
    $microtime;

    ==
    PHP Code:
    function getTime() {
        return 
    array_sum(explode(' '$microtime));

    ==
    PHP Code:
    function getTime() {
        return 
    microtime(TRUE);

    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #375
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    PHP Code:
    function getTime() {
        return 
    microtime(TRUE);

    From TFM: Note: The get_as_float parameter was added as of PHP 5.0.0.


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
  •