The Gamer Corner
You vant to go outside!? You vant to fisticuffs!?
Lost your password?

Gamer Corner Guides 4.0 Data Design

Gamer Corner Guides 4.0 Data Design – February 2, 2012 6:59 PM (edited 2/2/12 1:59 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
I have been considering a backend redesign, specifically of how data is handled, for the Gamer Corner Guides site for some time. I'm going to divide this post into sections (i.e., multiple posts) to make it a bit easier to digest. What I'm looking for is advice on how to handle the data in a way that allows me to display it in a flexible manner.

--
There is no Mythril Sword in Elfheim
Current Design – February 2, 2012 7:14 PM (edited 2/2/12 2:14 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
The current design is pretty simple, and is mostly procedural. Basically, there are four components for each data set: the page view, the data, the headers, and the table. Each is technically its own class, but they are used more as namespaces than actual objects at this point.

The Data
The data for a given table is collected by a catch-all function which returns an array of table rows. This function is used for both single-row and multiple-row (table) views, and handles searching, filtering, sorting, and some basic cross-referencing (e.g., anything that appears on a table).

The Page View
Most tables have two views: the table view and the individual pages. The table view is entirely determined by the headers and table components. I'm referring here to the individual page view. Most pages have three parts: the raw data, cross-referenced tables, and notes. The raw data is shown at the top in an entirely custom template, while the cross-referenced tables are basically just an array of appropriate tables that are displayed like any other. The notes are entirely independent.

The Table
To support having both basic and cross-referenced tables, there is a table class that can create an output table based on some simple parameters. This keeps track of which columns to show and how to alter the header text (for cross-referenced tables). All output tables use the same base template, which is populated based on the data provided here.

The Headers
I've never come up with a really good solution on how to deal with table headers. In the original design, all the tables had their own templates, but in going to a universal template, I had to stick all the formatting, help text, etc. somewhere. Because of how the table class handles columns (they can be added or removed at will, or even shared), it made sense to put them by themselves. However, this is basically just a huge array of strings.

--
There is no Mythril Sword in Elfheim
The Goal – February 2, 2012 7:22 PM (edited 2/2/12 2:22 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
Now, the goal is to unify the different display types, and add some more. Specifically, I want to be able to add a single table row as a sort of "widget" with the relevant data. (This would be for putting into walkthroughs as a quick reference, that sort of thing.) It could also be useful to have a single table with data from multiple sources - for instance, an "items of interest" table containing both bosses and treasure, or something like that. All of these ideas require different views for the same data.

It's also worth noting that the template engine I use (Smarty) supports objects, so optimally I could have something like:
$tableRow->showAsWidget()
$tableRow->showAsPage()
$dataSet->showAsTable()

Or something along those lines. Indeed, what I've come up with so far is much more object-oriented.

--
There is no Mythril Sword in Elfheim
New Data Design – February 2, 2012 7:30 PM (edited 2/2/12 2:30 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
I'm pretty sure I know how I want to handle the data, just not the display. I'm also pretty sure the two need to be separate, at least in part. (For instance, while displaying an individual item could be a function of a single table row, displaying a table can't because it needs headers and such.)

As far as the data, the design is pretty simple. Currently, the data is collected via queries and returned with associative arrays. Instead, each row would be an object instance. This has the added benefit of making "on demand" table data easy to ignore in cases where it's not needed.

There are two major questions as far as this method. First, how the data should be collected. Second, how granular the class design should be.

I'm inclined to have a single function that creates these objects, returning an array of them or a single instance, much like I am currently returning table rows. However, this begs the question of where the collection function would be defined. Probably the most logical solution is to make it a static function on the specific class for each object. However, I'm not sure having a different class for each table is really necessary. (Although having separate classes and therefore separate files for each table certainly would make maintaining any individual file.)

--
There is no Mythril Sword in Elfheim
New View Design – February 2, 2012 7:41 PM (edited 2/2/12 2:41 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
And that brings us to the reason for these posts: how to handle the actual data view. This is where I could really go in any direction. To start with, let's outline what I mean by this:

• First, I need the list of columns to show on a table of this type, including any changes for different references
• I also need a list of valid references (e.g., weapons can be filtered by character, but probably not by item, because there's no relation there) and how they affect the output
• Next, I need details about how to display each column (formatting, help text, etc.)
• Then, I need details on how to display these details on a page level - optimally, though, this would be the same as the table view in most cases, maybe with some specific extra fields that wouldn't fit on a table
• Finally, I need to reference a template for output of individual items as widgets, or any other custom view

I'm assuming there would be a 1:1 relation between these view classes and the actual data classes (e.g., FFVIIIWeaponView and FFVIIIWeaponInstance or something). That seems like a pretty decent start, but I'm not really sure where to go from there. For instance, how would this actually be used? I'm assuming you create an instance of the view, pass whatever data you have into the constructor, then call output functions to display it. That seems pretty simple... so is this even a good design? Is there a better one?

--
There is no Mythril Sword in Elfheim
Active Users: (guests only)
1 user viewing | Refresh