Jump to content
bracketfire

Use cases for Page FieldType returning NullPage vs. null?

Recommended Posts

I see when creating a Page fieldtype, under details, you can have the API return either a NullPage or actual null if the page is not found. 

I'm wondering why anyone would want a NullPage.

It seems like the common use case would be

if ($page = selector) {
     $page->stuff...
} else {
     // not found stuff
}

The documentation states "so that your API code doesn't have to always check that the returned Page is valid before using it", but that doesn't compute for me.  I must be missing something.

Why would someone operate on an invalid Page?

I've searched the forums and couldn't find any examples of the benefits of returning NullPage.

Since I'm trying to apply best practices while I learn PW, I just thought I'd ask the community.

Share this post


Link to post
Share on other sites

Simple explanation:

// Type Null (variable with no value)
echo $p->id // throws error.

// Type NullPage (object type of NullPage)
echo $p->id // outputs 0, evaluate to false

if(!$p->id) {
  echo "We have a NullPage";
} else {
  // we have a valid Page
  echo $p->title;
}

Not relevant to your question:

/**
 * Here $page is always that selector, so always true.
 * You need atleast a double ==
 * I prefer the tripple version === , then type also matters
 */
if ($page->id !== 0) {
     $page->stuff...
} else {
     // not found stuff
}

// little bit changed, to clarify

take a look: comparison operators

Edited by Martijn Geerts
  • Like 1

Share this post


Link to post
Share on other sites

One value of a NullPage is in cases where you have output code. Lets say you are outputting a table of skyscrapers, with the columns of city, architect, architectural_style and floors. Lets also say that city, architect and architectural_style are single page references. If we are allowing a NullPage for these single page references, our output code can look like this:

foreach($skyscrapers as $item) {
  echo "
    <tr>
    <td>$item->title</td>
    <td>{$item->architect->title}</td>
    <td>{$item->city->title}</td>
    <td>{$item->architectural_style->title}</td>
    <td>$item->floors</td>
    </tr>
    ";
}

The code above doesn't have to examine whether each property is present or not before outputting it.

If we instead chose the option of Page or NULL (rather than NullPage), then we'd have to check every single one of those page references before outputting them, or we'd get a PHP error. So it would make our output code more complex:

foreach($skyscrapers as $item) {
  echo "<tr>";
  echo "<td>$item->title</td>";
  if($item->architect) echo "<td>" . $item->architect->title . "</td>";
    else echo "<td></td>";
  if($item->city) echo "<td>" . $item->city->title . "</td>";
    else echo "<td></td>";
  if($item->architectural_style) echo "<td>" . $item->architectural_style->title . "</td>";
    else echo "<td></td>";
  echo "<td>$item->floors</td>";
  echo "</tr>";
} 

The above is certainly just fine too. But if you are using a NullPage, your code will always be dealing with the same derived type (a Page) as opposed to two types (Page and NULL). This can make your code simpler in some situations, and make your site less fragile. But there's also a case to be made for NULL, as you may actually want to account for every unset page reference and want an error when your code isn't handling it. That's why I thought it was best to let people decide what worked best for them in this case. 

  • Like 8

Share this post


Link to post
Share on other sites

Awesome explanation, thanks for taking the time to document this.  I'm rapidly acquiring a real taste for this thing they call processwire :-)

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...