XF 2.0 ->user_id fails empty checks, [''] does not...

Jaxel

Well-known member
I've been using $params->user_id in my code, coming from the ParameterBag. It's normally worked perfectly fine.

However, I was having issues with the following code:
Code:
        if (empty($params->user_id))
        {
            return $this->actionAuthors($params);
        }
This code has been failing 100% of the time.

I noticed however, if I switch it from $params->user_id to $params['user_id'], it starts working fine.

Why is this happening? Should I go back through my code and change all the object identifiers to array identifiers?
 
If you search for "class ParameterBag" in the XF2 folder, you'll find it at XF\Mvc\ParameterBag. As you can see by the functions, it is an object that allows you to access the parameters (defined in the $params property) via object or array notation (ArrayAccess interface: http://php.net/ArrayAccess ).

Digging further, you'll see this function:
PHP:
    public function get($key, $fallback = null)
    {
        return array_key_exists($key, $this->params) ? $this->params[$key] : $fallback;
    }

Therefore, using if (!$params->user_id) runs the array_key_exists, meaning you would not receive any error messages if user_id did not exist in the ParameterBag object. If it did not exist, you'd effectively be running if (!(NULL)), which returns true, and your actionAuthors would run.

I would recommend you go over all your existing code and make sure you do not call empty or isset on ParameterBag options, instead either use if conditions like the one I highlighted above, or make use of the $fallback parameter if you wish to default to a set value if needed.

In short, the answers you seek can usually be found by looking at the source class for the XF2 code :)

PS: Instead of your original code block, please consider using this code instead:

PHP:
        if (!$params->user_id)
        {
            return $this->rerouteController(__CLASS__, 'authors', $params);
        }
So that you are compliant with the XF2 standards :)


Fillip
 
Interesting... Whats inherently wrong with this though?
Code:
return $this->actionAuthors($params);
 
Interesting... Whats inherently wrong with this though?
Code:
return $this->actionAuthors($params);
Looking at
PHP:
    public function rerouteController($controller, $action, $params = [])
    {
        $match = new RouteMatch($controller, $action, $params, $this->responseType);

        return $this->reroute($match);
    }
It's clear that rerouting the controller does more than simply execute the new controller. I don't exactly know 100% what changing the RouteMatch would do, but if I'm going to take a stab in the dark I'm going to assume it affects things like preDispatch / postDispatch calls in the controller, Who's Online activity, etc.

If I'm developing an app in native XF2 code rather than using middleware tools, I'm going to go out of my way to follow the standards, so this is a case of "I don't know why it's right, but I do it because it's right" :P


Fillip
 
Yeah... thats generally my ideology too... but since converting from XF1 to XF2, I now am more interested in knowing why. For instance, my XenRio mod does a lot of cURL operations. I use XF's built in http functions for that... but if I had simply used PHP's built in http functions, I wouldn't have had to rewrite so much code.
 
Yeah... thats generally my ideology too... but since converting from XF1 to XF2, I now am more interested in knowing why. For instance, my XenRio mod does a lot of cURL operations. I use XF's built in http functions for that... but if I had simply used PHP's built in http functions, I wouldn't have had to rewrite so much code.
Sure, but on the flipside, you are responsible for a LOT more hassle if you use cURL directly. I don't know if you've ever had to deal with SSL certificate validation issues, response redirect issues, changes in response type (what used to be JSON is now XML or HTML, etc), just to name a few. I have, and that is why I am very happy to simply use XF's wrapper for the Guzzle objects so that it handles all of that for me.

That's exactly why such libraries exist, why frameworks exist; so that us mere mortals can rest assured that we don't have to get involved in whatever black magic the libraries use to make things work. I see no reason why I should have an intimate knowledge of the internals that are so close to the metal that I would never normally need to deal with it.


Fillip
 
Back
Top Bottom