To Sub-Categorize or not to Sub-Categorize

BIOS LEVEL by Obsidian 1 Comment »

So I’m sitting here working on the updates I promised and I have a dilemma. The update in question is the reviews section. Why am working on that section over others? Because once it’s done, regardless of the rest of the site, we can start posting content and driving traffic. And then you ask what the dilemma is, and I answer: How far should one sub-categorize?

This blog for example, only has 1 level of categories. At the moment, our reviews section has 2. From the “base” category, to sub-categories of the base, to sub-categories of that level.

  • hardware
    • videocards
  • accessories

How far do I go down? Do I break Videocards down by Chipset, Chipset by Vendor? I don’t anticipate people to look that in-depth, nor do I expect to have a great variety of similar products from different brands. So is the “videocard” category complete as is?

Should I choose to break it down farther, or at least leave the option to break a category down as far as possible in the future? The issue comes in with the code involved. The database is simplistic: Category ID, Parent, and Name. That should be self-explanatory. But when trying to retrieve all children, you’re going to end up relying on either several loops, or some recursion in your code.

 function getChildren($id,&$db)
  {
    $cats = "";
    $parent = $id;

    $sqCat = "SELECT id,title FROM acats WHERE parent = $id";
    $qCat = $db->query($sqCat);

    if (DB::isError ($qCat))
     die ("SELECT failed: " . $qCat->getMessage () . "<br/>" . $sqCat . "<br/>" . $id[3]);

    while ($rCat = $qCat->fetchRow())
    {
      if(!($cats == ""))
      {
        $cats .= "|";
      }
      $cats .= $rCat[0] . ":" . $rCat[1];
    }

    // id:title|id2:title2
    return $cats;
  }

So the above function pulls all the children of category $id, if any. This is a shortened version of what I’m using currently, there are no checks in it, nor a control to keep the string in line (note the “:” that will appear on the end). Regardless of features, it works the same for our purposes. Now we need some code that will call upon getKids() for all the categories.

  function showCats($id,$db)
  {
    $sRet = "<ul>";
    $children = getChildren($id,&$db);
    $i = 0;

    while( ($kids = explode("|",$children)) && ($kids[$i] != "") )
    {
      $parts = explode(":",$kids[$i]);
      $sRet .= "<li>$parts[1]"; // shows the name

      if($parts[0] != "")
      {
        $sKids = showCats($parts[0],$db);
        if ($sKids != "<ul></ul>")
        {
          $sRet .= $sKids;
        }
      }

      $sRet .= "</li>";
      $i++;
    }
    $sRet .= "</ul>";

    return $sRet;
  }

So, this second function is designed to format the information we got from getKids() and display it in an unordered list. At the same time, for each item returned to us by getKids(), it calls itself to check for children of each category all the way down the list. This should be an effective way of future-proofing our category system, allowing us to add as many sub-categories as we wish. Then it will just be a question of sanity and user-friendliness.

On a side note, I wrote this post to reason out the code needed to achieve this purpose. =P

To Digress

BIOS LEVEL by Obsidian No Comments »

Before Nick writes his final report on his Skype Challenge, I’d like to make mention that Pittco just held its 7th event over St. Patrick’s Day. It was a great time, and I think we broke record attendance, though we’re not sure due to a malfunction in our software. Anyone that missed it (Brian) is a loser. =P

On a more serious note (not that Pittco isn’t serious), I’ve become engrossed in Unreal Tournament 2004. It’s been sucking up all my free time, and I apologize. The other PHP developers are all off on their own adventures as well:
* Colin: Senior Project (college)
* JD: Job and being a senior (college)
* John: School web-work and… uhhh… right.

So that leaves me, right? And if I’m stuck in Unreal Tournament, then I guess we’re just screwed. No, but really, we are progressing, albeit slowly. I’ve made a few adjustments today, mostly just altering how fonts are displayed in certain sections. I also fixed up the “About Us” page. It’s still a little plain, so I feel like I have to add some background colors. I’m not sure, though. Thoughts?

Hopefully there’s more done by the end of the weekend.

For your consideration: Object-Oriented PHP and OpenID

BIOS LEVEL by Obsidian No Comments »

Taking a break from Nick’s Skype Challenge, I want to look at BIOS_LEVEL’s new look and backend.

Graphical Changes

While the new design is still unfinished, it remains functional. A few graphical elements still need to be finished, mainly the tabs under the logo and the logo itself. I’d also like to add a gradient to the logo area (just a simple gradient, not another glass-like bar) as well as to the Menu headings on the left hand column. Then I think the CSS needs touched up a bit for the news; add in some color to separate all the different elements (title, links, content). Since I’m on Spring Break this upcoming week, maybe we’ll all see a little change.

Object-Oriented Design?

When we started the new design, we also changed how the page was written to the screen. We moved from my simplistic template engine (if you can call ereg_replace() that) to Smarty. We’re not using Smarty for anything spectacular, just as a template engine. Colin knows a lot more about Smarty than I, but we haven’t tried anything beyond simple element replacement and insertion.

Anyways, using Smarty meant I had to re-write a lot of the backend. Mainly, object-UN-orient it. That’s how you see it right now (and why more than 1/2 of the pages don’t work). Frankly, it feels inefficient. After re-writing the “About Us” and “Profile” pages to not use the OO-approach, I realized it is. For the simple calls I had to do with the OO backend, I now have to pass a million variables. These are taking up unnecessary amounts of memory, especially considering passing by reference is disabled in many cases (objects, primarily). Instead of accessing $this->user for session variables, I now have to pass the $user variable to every function that needs access to it. Same goes to the database connections.

I don’t like it. Along with the graphical changes mentioned above, I’m probably going to re-write the backend this week as well to take a more object-oriented approach once more.

OpenID

I first started considering implementing OpenID on my own blog, but decided against it in favor of remotely accessing BIOS_LEVEL’s userbase. Now that sites such as Digg and others have announced support for OpenID, Colin feels we should join the bandwagon. I’m inclined to agree. More functionality for us, and easier migration for anyone who joins our forums that already uses OpenID. At first, we thought we may have to find a new forum that supports OpenID, but I just found phpBB-OpenID. I haven’t tried installing it yet, but it looks simple enough to use for admins and users alike. Keep your eyes open for it.

And for your enjoyment, BIOS_LEVEL on Apple’s 30″ display.

Welcome to BIOS_LEVEL Staff Blog

BIOS LEVEL by Obsidian No Comments »

We’ve implemented a wordpress blog to share our progress with BIOS_LEVEL and other developments. We’ve got a blogroll on the sidebar for all the staff’s personal blogs, you should check those out, too. Expect updates here when we finish something on bios_level or run into a significant annoyance while developing something bios_level-related. We also have an interesting experiment that should be introduced in the next post or two.

This is only a temporary blog, as it will eventually be replaced with a custom-CMS so it works in conjunction with both our forums and front page. For now, however, this is it!


WordPress Theme & Icons by N.Design Studio
Entries RSS Comments RSS Login