SitePoint Sponsor

User Tag List

Page 2 of 16 FirstFirst 12345612 ... LastLast
Results 26 to 50 of 397
  1. #26
    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 arborint
    As I recall, an extract and include is actually slower than a file read and str_replace in most cases.
    That's probably true for templates satisfied by str_replace. Note that for more complex templates, Smarty "compiles" to PHP:

    "Smarty reads the template files and creates PHP scripts from them." http://smarty.php.net/faq.php#3

    Can we get back to making a lightweight "skeleton"? In the lightweight department, I think we already want to pick PHP templates, anything else will have more code, no?

    Douglas
    Hello World

  2. #27
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can we get back to making a lightweight "skeleton"?
    I agree. And I agree that sticking with PHP templates for the minimum makes sense.

    In the original post cadmiumgreen shows a switch based Front Controller. He did not deal with the App Controller that would inevitably be in each of his included files.

    I am actually interested in people's views on what is the minimum (i.e. skeleton) controller. I would say that an Input/Application Controller is the basic controller. It should be able to work standalone.

    Then an optional Front Controller to allow you to centralize some functionality and add mappings that go beyond individual PHP files each containing an Input/Application Controller.

    Frameworks like Mojavi, WACT, etc. have controllers crammed full of code to support the specifics of the framework. This makes them not very resuable. So what is the minimum Input/Application Controller and Front Controller? And what other classes are needed: Request, Handle, etc.?
    Christopher

  3. #28
    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 Dr Livingston
    That is true in some (most?) cases, but now that we have such a thing as the ViewHelper pattern, why not just separate out the presentation logic anyways?
    Formatting and data gathering are two different things. You might want to output the same set of data on different pages of a website with different markup, or you might want to output in a range of formats: CLI, pdf, etc.

    If you don't apply formatting in a template file, I don't see how you can keep things nicely separated.

    Classes which gather the data can roam across the domain or go straight to the data access layer to get what they want, then make this data available to a template file as iterator lists, simple vars or whatever. In templates you need to loop through lists, apply conditionals, and print values. That can be achieved with a custom template language or equally with php itself.

  4. #29
    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 DougBTX
    Can we get back to making a lightweight "skeleton"?
    Excuse me - agreed time to move on.

  5. #30
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So what do the minimum Application and Front Controllers look like. Let's see some code. Picking up on BerislavLopac's post, index.php would be:
    PHP Code:
    include_once 'AppController.php';
    $controller =& new AppController(new Request());
    $controller->execute();  // or $controller->run(); ? 
    Here is a very basic Request class to kick things off:
    PHP Code:
    class Request {
    var 
    $_request = array();
        
    function 
    Request() {
        if (!
    strcasecmp($_SERVER['REQUEST_METHOD'], 'POST')) {
            
    $this->_request =& $_POST;
        } else {
            
    $this->_request =& $_GET;
        }
        
    $this->_request['PATH_INFO'] = $_SERVER['PATH_INFO'];
        if (! 
    get_magic_quotes_gpc()) {
             
    $this->removeSlashes($this->_request);
        }
    }

    function 
    removeSlashes(&$str) {
        if (
    is_array($str)) {
            foreach (
    $str as $key => $val) {
                if (
    is_array($val)) {
                    
    $this->removeSlashes($val);
                } else {
                    
    $array[$key] = stripslashes($val);
                }
           }
        } else {
            
    $str stripslashes($str);
        }
    }

    function 
    get($name) {
        return 
    $this->_request[$name];
    }
        
    function 
    set($name$value) {
        if (
    $name) {
            
    $this->_request[$name] = $value;
        }
    }
        

    Christopher

  6. #31
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Yep but there is such a thing as layering, and separating those layers. It is surprising and disappointing to realise that there are developers out there, who use OO and design patterns every other day, and still put PHP in HTML.
    PHP in your templates has nothing to do with layering and everything to do with personal preference?

    - matt

  7. #32
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    PHP in your templates has nothing to do with layering and everything to do with personal preference?

    - matt
    Woops, time to move on. Didn't read the whole thread.

  8. #33
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok, one more time?

    Anyone want to show an absolutely minimal Front or Application Controller that would be an OOP and patterns based implementation of the code that cadmiumgreen originally posted? Again, I am assuming that the switch is a Front Controller and that in each of the included PHP files there would be an Application Controller. We also said that templates would be PHP templates for simplicity sake. I threw in a simple Request class.

    Or perhaps someone would like to propose the requirements for the minimum Front and Application Controllers so we have an idea of what the target is.
    Christopher

  9. #34
    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
    Here is a very basic Request class to kick things off:
    Surely, if we want a minimal setup, you shouldn't include a Request object ? It's basically just an object-oriented wrapper over an already available feature in php.

  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)
    Making a "minimal" FrontController probably isn't feasible. The method of mapping the request varies greatly, as you can see from some of the posts in theese forums. A solution to that is to use a ChainOfResponsibility with requestmappers, which is flexible but hardly minimal.

    I'm not entirely sure that a bare-bones setup should define a framework for the the script which comes after the FrontController. You call it an ApplicationController, but I don't think that's the right term to use ... I never really understood what an ApplicationController is to be honest. I think a more proper word would be Dispatcher, which also implies that the Dispatcher may be simply a ServerPage, or something more complex like a class-based Controller.

    Anyway, to join in on the fun, here's a swing at a really lean FrontController ;
    PHP Code:
    class InputController
    {
        var 
    $requestMapper=NULL;

        function 
    InputController(&$requestMapper) {
            
    $this->requestMapper =& $requestMapper;
        }

        function 
    execute() {
            
    $dispatcher =& $this->requestMapper->mapRequest();
            
    $dispatcher->execute();
        }
    }

    /**
       * @abstract
       */
    class RequestMapper
    {
        
    /**
           * Maps the request to a proper controller. Use whichever strategy you want.
           * @returns Dispatcher
           */
        
    function & mapRequest() {
    }

    class 
    RequestMapper_DefaultMapper extends RequestMapper
    {
        function & 
    mapRequest() {
            return new 
    Dispatcher_ServerPage('default.php');
        }
    }

    /**
       * @abstract
       */
    class Dispatcher
    {
        function 
    execute() {}
    }

    class 
    Dispatcher_ServerPage extends Dispatcher
    {
        var 
    $fileName;
        function 
    Dispatcher_ServerPage($fileName) {
            
    $this->fileName $fileName;
        }
        function 
    execute() {
            include(
    'ServerPages/' $this->fileName);
        }

    index.php
    PHP Code:
    $frontController =& new InputController(new RequestMapper_DefaultMapper());
    $frontController->execute(); 

  11. #36
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is what I'm working on at the moment, can only put down the Interfaces at the moment, though as I'm still working on it

    PHP Code:
    interface IDispatchController {
    public function 
    __constructIRequestHandler $handler$mapper );
    public function 
    invoke();
    }

    interface 
    IRequestHandler {
    public function 
    __constructHttpRequest $reqHttpResponse $res );
    public function 
    getRequestParameter$parameter );
    public function 
    getLang();
    public function 
    getId();
    }

    interface 
    IComponent {
    public function 
    getId();
    public function 
    hasChildren();
    public function 
    getChildren();
    public function 
    attachIComponent $component );
    }

    interface 
    IAction {
    public function 
    isSecure();
    public function 
    setTemplate$template );
    public function 
    getTemplate();
    }

    interface 
    IHandler {
    public function 
    __construct$controller );
    public function 
    setHandler$handler );
    }

    interface 
    IActionChain {
    public function 
    attach$handler );
    public function 
    process$request );
    }

    interface 
    ProcessMapper {
    public function 
    computeIDataSource $ds );

    Almost forgot, here is an example which will kick things off

    PHP Code:
    $dispatch = new RequestDispatchController( new Request( new HttpRequest(), new HttpResponse() ), AdjacencyListFactory::create() );
    $dispatch -> invoke();
    // ... 
    At the moment, I'm working on the mapper, which maps the requested action to the required file(s) to be fetched. The mapper eventually could be database based, or XML, or a web service I'm pondering on?

  12. #37
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think a more proper word would be Dispatcher, which also implies that the Dispatcher may be simply a ServerPage, or something more complex like a class-based Controller.


    As you can see, this is the view point that I've taken also Kyber. I also agree with you on the point you've made about the Chain of Responsibility as well. This pattern I believe plays has an important role to fufill.

  13. #38
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are we answering his question correctly:
    I would like to know the general practice that most PHP developers use when designing a website that generally has the same menus, but the content changes.
    Most PHP developers don't use design patterns. They often do something along the lines of what he is doing. And, for personal webpages, that actually might just be better than complicated OO applications then quick and dirty webpages with no special, complicated needs.

    PHP Code:
    <?php
    require('common.php');

    $actions = array(
    'news'     => 'file' => 'news/news.php',
    'profiles' => 'profiles/profiles.php',
    'links'    => 'links/links.php',
    'help'     => 'help/help.php',
    );

    $default_action 'news';

    if (
    array_key_exists($actions$_GET['content'])) {
        
    $title ucwords($actions[$_GET['content']);
        
    default_header($title);
        require(
    $actions[$_GET['content']]);
        
    default_footer();
    }
    else {
        require(
    $actions[$default_action]);
    }
    ?>
    common.php could include functions to make a header and a footer, shared variables and pull in common libraries. Each file could then call what they want. Is it the best design? No. Would I code my website like this? If the site was as simple as this, maybe I would. Hell, SSI sometimes suffices.

    He has to weigh his needs. Does his site need to be highly extensible? Is he going to be adding things everywhere, changing functionality continously, etc. Or is the site going to be fairly static, with simple updates only to content.

    I fully support good development practices, but sometimes it better to KISS (Keep It Simple Stupid). I might get hearty disagreement, or his site intentions may be much more complicated, but oh well.

  14. #39
    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 Dr Livingston
    As you can see, this is the view point that I've taken also Kyber. I also agree with you on the point you've made about the Chain of Responsibility as well. This pattern I believe plays has an important role to fufill.
    How would you write this WRT Ryan Wray's comments?

    From what you said, I'd assume you've done it before: do you have any code you can share?

    Douglas
    Hello World

  15. #40
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ryan Wray
    I fully support good development practices, but sometimes it better to KISS (Keep It Simple Stupid). I might get hearty disagreement, or his site intentions may be much more complicated, but oh well.
    I whole-heartedly agree. The poster posted a question perhaps better suited to the regular PHP forum, and received answers diluted in patterns and unnecessary complications.

    I think that, judging by the code in the original post, talk of such patterns is likely more confusing than helpful.

  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)
    @Dr Livingston
    I see that you too are suggesting a Request-object. Wouldn't you agree that it's overkill for a bare-bones setup ?
    The Response-object is another story. I would likely add that in very early, but I'm not sure if it should be in a minimal setup ?

    Quote Originally Posted by Ryan Wray
    Are we answering his question correctly
    Probably not. This thread went astray many posts back.

    Quote Originally Posted by Ryan Wray
    Most PHP developers don't use design patterns
    If by that you mean, that most php-developers aren't aware that they are following a common design-pattern, you may be right. But the original question was exactly related to which is the common pratice. He may not be using the word "design-pattern", but it's what he meant.

    To address the original question ;
    What you show us is some markup, with a switch-statement in the middle, that includes other scripts. In academic terms, the script is a hybrid of two components. The php-block with the switch within is called a Controller. The rest of the script (the html-markup) is called the View. It is very common to seperate View and Controller, and is generally consider good practice. That's why I suggested to seperate the two in my first post.

    There is another aspect of your code though - I suppose that your "skeleton"-script is the main entry-point for the application. Te scripts main pupose is to dispatch control to another script (you do that by the include-statement). This behaviour is called the FrontController-pattern - It is a very common technique. So in regard to that, the answer to your question would be "yes". The exact implementation could be improved though - using a switch-statement is a bit clumsy.

  17. #42
    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 DougBTX
    How would you write this WRT Ryan Wray's comments?
    It's kind of impossible to implement Chain of Responsibility without using an object-oriented approach. Someone in another thread called CoR an object-oriented switch-statement. I think that really captures the pattern.

    Or did I completely miss out on your question ?

  18. #43
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    WRT?? Don't know what that abbrev. is for, but to answer your other question I can't share any script.

    I wish that I could but that isn't the case at the moment, sorry.

  19. #44
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would likely add that in very early, but I'm not sure if it should be in a minimal setup ?
    Kyber, I would have to differ on this point... You could I suppose get away without using the Response class, but for a basic, minimum setup, a Request class is required. If not, how else could you access $_GET, et al in a standardised fashion through out the application?

    I couldn't use $_GET, $_POST, etc directly. Previously I've passed around both the Request and Response objects yes? Not now, I just pass around the Request object, which encapsulates both Request and Response now.

    This way, Request and Response remain re-usable, and if I need to add functionality for a specific application, this is done in the Request object. So at the end of the day what I'm saying is that the Request object is disposable.

    I think this just increases the re-use of Request and Response, but I wouldn't have that accessability if I excluded them

    or something more complex like a class-based Controller.
    Your class based controller, the setup would proberly be of a composite based structure. Ideally this is the direction in which you are looking for. I've implemented it (only recently though ), and now Selkirk is looking into it as well for WACT from what I read on a thread the other month there?
    Last edited by Dr Livingston; Jun 11, 2005 at 09:28. Reason: adding a new comment

  20. #45
    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 couldn't use $_GET, $_POST, etc directly.
    Why is that ?
    I can only see two reasons for encapsuling them: a) To simplify testing, and b) to allow for other-than-web enviroments (eg. commandline).
    If you don't do unittests a) is useless overhead, and let's face it b) is a rarity with php.

  21. #46
    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
    Your class based controller, the setup would proberly be of a composite based structure. Ideally this is the direction in which you are looking for.
    Could you expand on that ? I'm not sure I follow you.

  22. #47
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry, but was you referring to within the context of this thread or in general? If in the context of this thread, and to keep things simple I suppose you could do without a Request object (and a Response object for that matter).

    But it's just not something I would do lightly. It's one thing scripting a simple solution for a basic website, but to tear down the bridges you cross on the way, to get there is another.

    You may find that the website expands quickly (we wish) in regards to the number of visitors, it's content, etc and the initial solution is no longer upto the task. You need to refactor, quickly and easily.

    Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.

  23. #48
    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
    Sorry, but was you referring to within the context of this thread or in general? If in the context of this thread, and to keep things simple I suppose you could do without a Request object (and a Response object for that matter).
    I meant in regards to arborint's challenge to make a minimal FrontController, so that would be in context of this thread.

    In a general context I wouldn't go without the Response-object, but I fail to see the real need for a Request-object. I really don't see the harm done in using the superglobals directly.

    Quote Originally Posted by Dr Livingston
    Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.
    It couples your code to the framework.
    If you use the superglobals, you could take the code out of your framework and run it elsewhere. That may also be true for the Response-object, but I think it's more appropriate there, since the Response would deal with other things than simply providing a wrapper over existing functionality.

  24. #49
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I see...

    It couples your code to the framework.
    If you use the superglobals, you could take the code out of your framework and run it elsewhere.
    This is an important point I think. But if the said framework, if your developing this yourself, as an ongoing concern (as in my case) then retaining the Request (within framework) is less of an issue, if there is to be greater flexibility from an application devleopment point of view.

    Well, that's how I see it anyways, and as I've said earlier you can increase the re-use of both Request and Response easily as I have done... The encapsulating Request object is throwable.

    You chuck it away, once you've finished with in, and script another one which is more specific and suitable to your needs. I got this tip from a Java developer, so if they're using this approach, there can't be much wrong with it

  25. #50
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    WRT?? Don't know what that abbrev. is for...
    I think WRT means With Regards To, but that is only a guess.

    Quote Originally Posted by kyberfabrikken
    If by that you mean, that most php-developers aren't aware that they are following a common design-pattern, you may be right. But the original question was exactly related to which is the common pratice. He may not be using the word "design-pattern", but it's what he meant.
    Yes, I was leaning more towards alot php-developers would not be aware they are using design-patterns. It fair to say that, even his original code is a Front Controller.

    Quote Originally Posted by Dr Livingston
    Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.
    Alot of trouble if he doesn't understand the code he is using. But you do make a good point.

    cadmiumgreen: PEAR probably would not help (a CMS would). You're approach should work fine (though, can you echo a require?), but if you're site is going to expand and change alot, you may run into problems. To make things easier, in the beggining, seperate atleast most of you're code from you're presentation. This way, changes in the structure of you webpage (ie. say you decide to change from tables to using generally more accepted methods) will not mean you have to go through multiple PHP pages looking for things to change.

    If you're time and needs warrants it, produce high-quality code. It will definetly save you time if in the future you want something more sophisticated. In should also give you reusable libraries, components, etc to use on further projects, which is one of the best benefits (and the most intended benefit of such coding).

    Good Luck


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
  •