SitePoint Sponsor

User Tag List

Page 5 of 16 FirstFirst 12345678915 ... LastLast
Results 101 to 125 of 384
  1. #101
    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 Ezku
    Perhaps we could have an ApplicationController that creates states and transitions by means of FlowController chaining. I'll look into it tomorrow.
    Freaky thought! But would it ever be needed ?

  2. #102
    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
    Edit:

    It springs to my mind that if the Request-class does strip slashes, it actually should be a singleton, to prevent stripping from happening twice.
    Just include it as a procedural snippet at the bottom of the file which you put the Request class in. It will only ever be run once, because if you try to include the file twice, you will get "Request class already defined" errors.

    Quote Originally Posted by kyberfabrikken
    Freaky thought! But would it ever be needed ?
    YANGI doesn't seem to be a priority in this thread

    Douglas
    Hello World

  3. #103
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Freaky thought! But would it ever be needed ?
    Suddenly, my sarcasm-scanner activated, emitting a faint *blip*.

  4. #104
    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 kyberfabrikken
    I have added a context-object in the same go, though I'm still a bit lukewarm about that.
    I just had the idea - wouldn't it make sense to put the errorlogger in the Response-object ? In that case, we don't need the Context-object.
    (Well, actually I was reading the wact sources, and they do this.)

    Quote Originally Posted by Ezku
    Suddenly, my sarcasm-scanner activated, emitting a faint *blip*.
    Actually I weren't. I can't think of a situation where you would need that option. Except maybe that we could use it to apply some lazy-loading.

  5. #105
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I just had the idea - wouldn't it make sense to put the errorlogger in the Response-object ? In that case, we don't need the Context-object.
    There's certain logic to that. Trash the Context for now, I don't think we want to introduce it needlessly.
    I can't think of a situation where you would need that option.
    I have to admit I haven't thought it through. Could be about how you think of dispatching to an ApplicationController.
    Except maybe that we could use it to apply some lazy-loading.
    Considering lazy loading; WACT had this nice idea of triggering events to invoke Delegates that wrap an object. Something along the lines of this:
    PHP Code:
    /**
     * Calls a method on an object upon invocation
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 12, 2005
     */
    class Delegate implements IDelegate
    {
        protected 
    $subordinate NULL;
        protected 
    $method NULL;
        
        public function 
    __construct($subordinate$method)
        {
            
    $this->subordinate $subordinate;
            
    $this->method $method;
        }
        
        public function 
    invoke($args NULL)
        {
            
    $callback = array($this->subordinate$this->method);
            return 
    call_user_func_array($callback, (array) $args);
        }
    }

    class 
    EventHandler
    {
        
    /**
         * @var array    2-dimensional IDelegate map
         */
        
    protected $listeners = array();
        
        
    /**
         * Register listener for event
         * @param    object    IDelegate
         */
        
    public function register($eventIDelegate $delegate)
        {
            
    $this->listeners[$event][] = $delegate;
        }
        
        
    /**
         * Trigger event listeners
         * @param    string    event
         */
        
    public function trigger($event)
        {
            if (isset(
    $this->listeners[$event]) && is_array($this->listeners[$event]))
            {
                foreach(
    $this->listeners[$event] as $delegate)
                {
                    
    $delegate->invoke();
                }
            }
        }

    The trick is that if you pass the Delegate a Handle object, the actual class can be lazy-loaded nicely upon triggering the event. Don't know if this is cool or YAGNI, but I couldn't resist when you brought it up.

  6. #106
    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 Ezku
    Input validation can be used wherever you want it. This could be either at the ApplicationController stage (which we're now designing to) or the Action itself.
    I think we should rename the Input Controller to something more meaningful then...perhaps InputSanitizer?

  7. #107
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overunner
    I think we should rename the Input Controller to something more meaningful then...perhaps InputSanitizer?
    I believe I've already expressed my wish to rename the InputController. Sanitizer won't quite do, but I'd be glad to have further suggestions!

  8. #108
    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 Ezku
    Considering lazy loading; WACT had this nice idea of triggering events to invoke Delegates that wrap an object. (...) The trick is that if you pass the Delegate a Handle object, the actual class can be lazy-loaded nicely upon triggering the event. Don't know if this is cool or YAGNI, but I couldn't resist when you brought it up.
    I think it's both cool and YAGNI. Form a FormController, the overhead of creating a few Handlers, that aren't going to execute is dimminishingly small. I actually think it would add up to introducing a lazy-load mechanism. I believe we came to the same conclusion about RequestMappers in the frontcontroller package.

    Quote Originally Posted by Ezku
    I believe I've already expressed my wish to rename the InputController. Sanitizer won't quite do, but I'd be glad to have further suggestions!
    I agree that it should be renamed. It's the only class named Controller, which doesn't implement IHandler. I'm not keen on InputSanitizer. Perhaps InputProcessor ?

  9. #109
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I agree that it should be renamed. It's the only class named Controller, which doesn't implement IHandler. I'm not keen on InputSanitizer. Perhaps InputProcessor ?
    That's a good suggestion.

    Regarding Context: wouldn't it be a nice place to store Session objects and the like? I was about to start stuffing Session, Cookie etc. to the Request when I realized that Context would probably be where they really belong. Context could also be used as a messaging service between layers (along the lines of $context->data->set('errors', $logger->getMessages());). It would prevent cluttering both Request and Response. Is this A Bad Idea (TM)?

  10. #110
    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 recieved a PM from tharos, but since I think it's relevant to the discussion, I'll reply here.

    Quote Originally Posted by tharos
    In "MyForm" class, rules are declared like this:
    PHP Code:
    $this->addRule(new Rule_Required("foo"));
    $this->addRule(new Rule_Email("foo")); 
    What I'm trying to do is to declare rules in a xml file. Something like this:
    Code:
    <rules form="MyForm">
    	<rule condition="Rule_Required" fieldname="foo" errormsg="Field required" />
    	<rule condition="Rule_Email" fieldname="foo" errormsg="%s should be a valid email-address" />
    </rules>
    I know how to manipulate xml with php. It's not the problem.
    But I don't know exactly how and where to add my code without breaking the MVC approach.
    I imagine a class which will retrieve xml data with specifics methods and will call "$this->addRule(...)"

    What do you think about that ?
    That's a good idea. There were a brief suggestion by me and ezku to create a factory-class which would do something like this. We just haven't come to that yet.
    I reckon we could rely on the ConfigReader classes from the skeleton-thread.

    Quote Originally Posted by tharos
    And now when the form is submitted, how to save fields values into a database. Same probleme here
    I don't see how and where to integrate my classes with yours. How to make these links.
    Basically, you would want to substitute the ServerPage("page/formdone.php") with an Action that handles the submit. It could be along the lines of :
    PHP Code:
    class MySubmitHandler
    {
        var 
    $redirect "?page=afterform"// or whatever

        
    function execute(&$request, &$response) {
            
    $model =& new Model();
            
    $model->import($request);
            
    $response->setRedirect($this->redirect);
        }
    }

    class 
    MyForm extends FormController
    {
        function 
    MyForm() {
            
    parent::FormController(
                new 
    ServerPage("page/forminit.php"),        // handler to handle state=init
                
    new ServerPage("page/forminvalid.php"),        // handler to handle state=invalid
                
    new MySubmitHandler()                            // handler to handle state=valid
            
    );
            
    // rules to be met in order to become valid
            
    $this->addRule(new Rule_Required("foo"));
            
    $this->addRule(new Rule_Email("foo"));
        }

    Quote Originally Posted by tharos
    Do your have a php5 version of your code.
    Sorry. I stick with php4. But some of the classes have been converted from Ezku's posts, which were php5. I'm sure that once we get things a bit more consolidated, somebody will port it.

  11. #111
    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 Ezku
    Regarding Context: wouldn't it be a nice place to store Session objects and the like? I was about to start stuffing Session, Cookie etc. to the Request when I realized that Context would probably be where they really belong.
    Yes and no. I'm a bit afraid of the context-object as I mentioned earlier. Session stuff definately doesn't belong in the request object IMHO. I like to see session as sort of persistence and thus clearly belonging to the Model-layer. Cookies might belong in the Request-object - I'm not sure about that.

    Quote Originally Posted by Ezku
    Context could also be used as a messaging service between layers (along the lines of $context->data->set('errors', $logger->getMessages()).
    Yes, but I think this is where we get very close to MagicContainer. I'd rather have that Controllers use the Model-layer to communicate with each-other if they need to.

    I won't rule out a Context as a ServiceLocator alltogether, but I'd rather wait to implement it when we actually need it. And I don't think we do quite yet.



    flowcontroller0.4.zip
    Here's a minor update to the code, which removes the context-object again, and places the errorLogger in the respose-object.
    I also renamed InputController to InputProcessor as agreed.
    I have updated tests and added a test for DataSpace. Still need to port the tests for rules (if we decide to stay with the Logger ...)
    Lastly I added magic-fix back to the Request code in the way that DougBTX suggested (copy&paste from WACT)

    About the naming. Since InputController have been renamed to InputProcessor, maybe we should rename FlowController to InputController ? Would that make sense ?
    Attached Files Attached Files

  12. #112
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I think it's both cool and YAGNI. Form a FormController, the overhead of creating a few Handlers, that aren't going to execute is dimminishingly small. I actually think it would add up to introducing a lazy-load mechanism.
    This is less a reply to kyberfabrikken, who's probably seen WACT stuff before, if only by way of explanations in Selkirk's posts. Newer readers may have a greater interest.

    With WACT, it gets better than that. The handlers inside delegates need not be instantiated objects, but so-called 'Handles'. If the particular Delegate wrapping that Handle is invoked, the Handle is instantiated as the handler object.

    I'm in awe of Selkirk for creating this most elegant mechanism!
    Zealotry is contingent upon 100 posts and addiction 200?

  13. #113
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Yes, but I think this is where we get very close to MagicContainer. I'd rather have that Controllers use the Model-layer to communicate with each-other if they need to.

    I won't rule out a Context as a ServiceLocator alltogether, but I'd rather wait to implement it when we actually need it. And I don't think we do quite yet.
    The Context could be implemented in a more strict manner, providing getters and setters for pre-defined specific objects (Request, Response, Messages, User, Session, etc), not just any key/value pair. In that case, a MagicContainer would not be a bad place to start; let it eat everything and later on, when things clear up (what can and what can't be in it), one could (and should) refactor it to a more strict context class.

  14. #114
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dbevfat
    The Context could be implemented in a more strict manner, providing getters and setters for pre-defined specific objects (Request, Response, Messages, User, Session, etc), not just any key/value pair. In that case, a MagicContainer would not be a bad place to start; let it eat everything and later on, when things clear up (what can and what can't be in it), one could (and should) refactor it to a more strict context class.
    I wouldn't object (no pun intended) to that. The fact is we do have quite a load of objects to be passed around in the Handlers. They can't all go in Request/Response.

    auricle: My thoughts exactly. As for my relating code above, I was just guessing based on the description at WACT. It's probably quite different in reality.

  15. #115
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    The fact is we do have quite a load of objects to be passed around in the Handlers. They can't all go in Request/Response.
    They could go into the request, they do in rails. The logic of such an approach depends on how you want to define the term "request"; the narrow definition would include only what's in the POST, GET and the URI itself, a broader definition would include Cookies, Sessions, etc. A possiblity would be to rename the object to something more inclusive, like Context, and within it place the Request, Cookies, Sessions, etc.. passing it around in the handlers.

  16. #116
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    They could go into the request, they do in rails.
    Wouldn't that effectively transform Request into a less organized Context?
    A possiblity would be to rename the object to something more inclusive, like Context, and within it place the Request, Cookies, Sessions, etc.. passing it around in the handlers.
    Isn't that exactly what we were talking about? Or do you mean passing around Context and Response, as opposed to just Context? What's the point in that?

    I'm starting to believe we really need a Context container that collects data together and encapsulates common data used throughout the system (Encapsulate Context, Allan Kelly).

  17. #117
    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 Ezku
    Or do you mean passing around Context and Response, as opposed to just Context? What's the point in that?
    There's some sort of logic in Context=>input and Response=>output.

    The thing which I don't like about having a Context-object is that it makes it harder for newcomers to understand the codebase. The benefits of such a container lies in the scalability of the system, but it's at the price of simplicity. Depending on the system you are building with it this may be good or bad.

  18. #118
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    There's some sort of logic in Context=>input and Response=>output.
    How about an InputContext with an OutputContext? InputContext with, say, Request and Session and OutputContext with Response, Logger and whatnot. If you browsed the linked article, there's talk about separating the Context object into bits like this. I think it'd be pretty logical, but does that pose the same problem with understandability? I'd concern that pretty minuscule however. Does it radically differ from having the necessary stuff embedded in Request/Response?

  19. #119
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    There's some sort of logic in Context=>input and Response=>output.
    Yes, exactly.

    Quote Originally Posted by kyberfabrikken
    The thing which I don't like about having a Context-object is that it makes it harder for newcomers to understand the codebase. The benefits of such a container lies in the scalability of the system, but it's at the price of simplicity. Depending on the system you are building with it this may be good or bad.
    To be honest, I don't think that's much of an issue, considering there are other parts of the codebase that are much more complex. It seems to me that the main goal so far has been flexibility, rather than simplicity...

  20. #120
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    How about an InputContext with an OutputContext?
    Does anyone like this idea? I'd like to try it.

    Context, I understand, is already generally agreed on? Assuming I refactor my code to Context+Response, where do Logger or the error messages go?
    Last edited by Ezku; Jul 14, 2005 at 16:03.

  21. #121
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    How about an InputContext with an OutputContext?
    That could work, and it would provide a place for logging and errors, as you mention.

  22. #122
    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 Ezku
    How about an InputContext with an OutputContext?
    Quote Originally Posted by 33degrees
    That could work, and it would provide a place for logging and errors, as you mention.
    Now we're just changing the names aren't we ? I mean ... Context implies a global span, which would include both input and output. If we are having seperate objects for in/out, why not keep the names Request/Response ?
    I'd want to have either one Context object or a Request + a Response.
    Quote Originally Posted by Ezku
    Assuming I refactor my code to Context+Response, where do Logger or the error messages go?
    Since they are output, I'd say in the Response.

  23. #123
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Now we're just changing the names aren't we ? I mean ... Context implies a global span, which would include both input and output. If we are having seperate objects for in/out, why not keep the names Request/Response ?
    Alright, how about if the current Request and Response would be stored at $request->http and $response->http respectively? There's a nice logic and it allows for a clean context object.

    Off Topic:

    I should really learn to think before posting


    Why the sudden loss in interest?
    Last edited by Ezku; Jul 15, 2005 at 06:12.

  24. #124
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's some code.
    PHP Code:
    /**
     * Context containing Request-related objects
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 15, 2005
     */
    class Request
    {
        
    /**
         * @var    object    HttpRequest
         */
        
    protected $http NULL;
        
        
    /**
         * @var    object    FILES DataSpace
         */
        
    protected $files NULL;
        
        
    /**
         * @var    object    COOKIE DataSpace
         */
        
    protected $cookie NULL;
        
        
    /**
         * @var    object    SERVER DataSpace
         */
        
    protected $server NULL;
        
        public function 
    __construct()
        {
            
    $this->http = new HttpRequest;
            
    $this->files = new DataSpace($_FILES);
            
    $this->cookie = new DataSpace($_COOKIE);
            
    $this->server = new DataSpace($_SERVER);
        }
        
        public function & 
    __get($name)
        {
            return isset(
    $this->$name) ? $this->$name NULL;
        }

    PHP Code:
    /**
     * HTTP request data: GET and POST
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 15, 2005
     */
    class HttpRequest extends DataSpace
    {
        
    /**
         * Request method is GET
         */
        
    const METHOD_GET    'GET';
        
    /**
         * Request method is POST
         */
        
    const METHOD_POST    'POST';
        
        
    /**
         * @var    int    Request method
         */
        
    protected $method NULL;
        
        
    /**
         * @var    object    GET DataSpace
         */
        
    public $GET NULL;
        
        
    /**
         * @var    object    POST DataSpace
         */
        
    public $POST NULL;
        
        
    /**
         * Request constructor
         * @param    int    request method, optional
         */
        
    public function __construct()
        {
            
    $this->method = (strcasecmp($_SERVER['REQUEST_METHOD'], 'POST') == 0) ? self::METHOD_POST self::METHOD_GET;
            
            
    $this->data $_REQUEST;
            
    $this->GET = new DataSpace($_GET);
            
    $this->POST = new DataSpace($_POST);
        }
        
        public function 
    getMethod()
        {
            return 
    $this->method;
        }
        
        public function 
    isPost()
        {
            return (
    self::METHOD_POST == $this->method);
        }

        
    /**
         * Cleans arrays ruined by MagicQuotes=On.
         */
        
    static public function fixMagicQuotes($aList$aIsTopLevel true)
        {
            
    $gpcList = array();
            
    $isMagic self::$magic;
            foreach (
    $aList as $key => $value)
            {
                if (
    is_array($value))
                {
                    
    $decodedKey = ($isMagic && !$aIsTopLevel)?stripslashes($key):$key;
                    
    $decodedValue self::fixMagicQuotes($valuefalse);
                }
                else
                {
                    
    $decodedKey stripslashes($key);
                    
    $decodedValue = ($isMagic)?stripslashes($value):$value;
                }
                
    $gpcList[$decodedKey] = $decodedValue;
            }
            return 
    $gpcList;
        }
        
        static public 
    $magic NULL;
    }

    /**
     * Fix magicquotes
     */
    if (HttpRequest::$magic get_magic_quotes_gpc())
    {
        
    $_REQUEST    HttpRequest::fixMagicQuotes($_REQUEST);
        
    $_POST        HttpRequest::fixMagicQuotes($_POST);
        
    $_GET        HttpRequest::fixMagicQuotes($_GET);
        
    $_COOKIE    HttpRequest::fixMagicQuotes($_COOKIE);

    PHP Code:
    /**
     * Context containing Response-related objects
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 15, 2005
     */
    class Response
    {
        
    /**
         * @var    object    HttpResponse
         */
        
    protected $http NULL;
        
        
    /**
         * @var    object    LogManager
         */
        
    protected $logs NULL;
        
        public function 
    __construct()
        {
            
    $this->http = new HttpResponse;
            
    $this->logs = new LogManager;
        }
        
        public function & 
    __get($name)
        {
            return isset(
    $this->$name) ? $this->$name NULL;
        }

    PHP Code:
    /**
     * HTTP response data: headers, status, redirection, content.
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 15, 2005
     */
    class HttpResponse
    {
        protected 
    $headers = array();
        protected 
    $redirect NULL;
        protected 
    $status NULL;
        protected 
    $content NULL;
        
        public function 
    setHeader($key$value=NULL) { $this->headers[$key] = $value; }
        public function 
    getHeaders() { return $this->headers; }
        
        public function 
    setRedirect($url) { $this->redirect $url; }
        public function 
    getRedirect() { return $this->redirect; }
        
        public function 
    setStatus($status) { $this->status $status; }
        public function 
    getStatus() { return $this->status; }
        
        public function 
    setContent($content) { $this->content $content; }
        public function 
    getContent() { return $this->content; }
        
        public function 
    out()
        {
            if(
    $this->redirect)
            {
                
    header('Location: '.$this->redirect);
                die;
            }
            else
            {
                if (
    $this->status)
                {
                    
    header('HTTP/1.1 '.$this->status);
                }
                
                foreach (
    $this->headers as $key => $value)
                {
                    
    header($key.': '.rawurlencode($value));
                }
                
                echo 
    $this->content;
            }
        }

    PHP Code:
    /**
     * A container for Loggers.
     * 
     * @author        Ezku (dmnEe0@gmail.com)
     * @since        Jul 15, 2005
     */
    class LogManager
    {
        
    /**
         * @var    array    ILogger storage
         */
        
    protected $logs = array();
        
        
    /**
         * Set Logger by a name.
         * @param    string    Logger name
         * @param    object    ILogger
         */
        
    public function __set($keyILogger $logger)
        {
            
    $this->logs[$key] = $logger;
        }
        
        
    /**
         * Get Logger. If one doesn't exist, a basic Logger will be created by the given name and returned.
         * @param    string    Logger name
         */
        
    public function & __get($key)
        {
            if(!isset(
    $this->logs[$key]))
            {
                
    $this->logs[$key] = new Logger;
            }
            return 
    $this->logs[$key];
        }

    Changed Request to HttpRequest and put it in a new Request-context, the same for Response. Created a LogManager as a place to store Loggers, put it in Response.

    I need your thoughts!

  25. #125
    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)
    While I can't really conjure up rational arguments, I'm still not keen on changing the signature of IHandler->execute()
    Regarding you latest post, I think the LogManager may be overkill. Why would we need multiple logs ?

    If we are going to pass all sort of stuff (such as $_FILES, $_SERVER and LogManager) around, I'd prefer a single ServiceLocator (Context) rather than split it into two. For example, the Loggers are output to some scripts, but input to others, which makes them odd to put in the right spot. (Though Response is possible better than Request)

    Maybe we could give it a rest and bring it back up in a while ?

    I'd be much more interested in peeking into a form-factory class as the one tharos was calling for. For a start, I suppose that we could just extend the FormController class ?


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
  •