blog.php

<?php

class Controller_Blog extends Controller {

    /**
     * This is a simple example, the class does not exist.  There are much more
     * things you would be able to do, this is just an example.
     *
     * Yes, I know this is all (kind of) currently possible, but this encapsulates
     * the response and allows for nice things like advanced response caching.
     */
    public function action_article($slug)
    {
        try
        {
            $article = Article::find_by_slug($slug);
        }
        catch (Fuel_Exception $e)
        {
            return new Http_Response(new View('articles/missing'), 404);
        }
        
        $response = new Http_Response();

        if (Input::is_ajax())
        {
            $response->set_content(json_encode($article));
            $response->headers->set('Content-Type', 'application/json');
        }
        else
        {
            $response->set_content(new View('articles/view', array($article)));
        }
 
        return $response;
    }

}

A couple of questions:

• Does this also mean we get rid of the Output class and have headers set on the response object?
• How does this work with HMVC? You shouldn't have more than one response, and you can't really mix 404 and non-404.
• Will it do more than wrap the output string and set headers?

And two nitpicks:

• Why not just Response instead of Http_Response?
• Shouldn't we always use factories in Fuel? We do it almost everywhere and it would be better for consistancy...

I kinda like the concept, but I'm not sure if it adds enough yet and how it would work with Hmvc (multiple responses doesn't really make sense to me).

1. Output would (eventually) be renamed as Response as this is a better name anyway.
2. It would work fine. The response object would have a __toString so you could use it as a string response. It actually helps HMCV a lot actually. 404's in a sub-request are always an issue, either the way we have it now or with this. You could check the status of the HMVC request tho to handle it gracefully in the main request.
3. Ya, eventually we can add advanced Response cacheing and some other stuff.

Nit-picks:

1. Ya, Response would make more sense.
2. Factories should only be used where necessary. I.E. they need to do some pre-processing or something.

Only the Response received from the main request action will be processed and used to set the headers and such. So any sub-request's response will be handled by the main action then that will pass either that response on or create a new one.

Hey guys,

I agree with what your both saying, how does the HMVC stuff work in Fuel, I mean surely whether your using mulitple controllers and actions shouldn't matter, the user types in one url, and they get one response back... Which is why there should only be one instance of the Http_Request object, which will only have one response property.

(Take a look at my fork for the http_request stuff)