Home » Forums » The Future of Zoop

Zoop URL handling

30 Jul 2008 justin

A couple of thoughts on Zoop's current URL handling:

IMHO, camelCase URLs should die a speedy but painful death. I understand that Zoop URLs aren't actually case sensitive, but zone/updateuserrecord is even worse than zone/updateUserRecord. I think a good solution would be to have zone/update-user-record call pageUpdateUserRecord(); just like zone/updateUserRecord would... Not a vital issue, but I'd sure appreciate it :)

The second, and perhaps more important issue, is that random urls will always return 200, spitting out the default page of the default zone if nothing else. This is a huge SEO issue, as well as a violation of the intent of response headers. Unless there is a zone/page combo that actually handles a URL, that URL should return 404.

A third issue: currently zone/addUser is handled the same way as zone/addUser/ (note the trailing slash), with the exception of $inPath parameters. The $inPath of the first is array( 'addUser' ) The second is array( 'addUser', '' ). Shouldn't these URLs be the same? The possibility of an empty param at the end of the $inPath prevents using the array length to determine how many parameters were passed.

Thoughts?

‹ Zoop Auth Usage :: Issue with Late Static Binding Zoop branding and logos ›

Good Thoughts

Your first thought is not a difficult addition, and can live side by side with current implementations. It seems like a pretty good idea to me.

Your second thought: The idea of zone_default and pageDefault are that they are defaults. They show up when nothing matches. If your app needs to be SE optimized, then you can throw a 404 in pageDefault if you want:

<?php
class zone_default extends zone
{
  function pageDefault($p, $z)
  {
    if(!isset($p[1]))
      $this->redirect('login');//or some other entry page;
    header("HTTP/1.0 404 Not Found");
    $this->guiDisplay('404.tpl');
  }
}

You can also use pageDefault as a search function, or like shady dns providers, generate ad revenue. I think that having zoop step in to serve 404's here would be a mistake. But having your pageDefault handle it makes sense.

your third thought: Seems reasonable, Although we should have a placeholder when a parameter is meant to be empty. zone/addUser/- vs. zone/addUser/ the first should have $inPath[1] == '', the second has no $inPath[1]. This is a little more dangerous, since it is a change from current behavior. It should be fine to do in 2.0.

john 31 Jul 2008

re: default zones and 404

My issue with this is that, by default, Zoop is set up to lie to users. I'd be a lot more comfortable if it told the truth by default (returns 404), and could be overridden if needed.

justin 04 Aug 2008