This is a fairly simple concept, but it really allows you to do alot more dynamic template work while staying firmly rooted within vBulletin's template system.
First lets talk about the basic use of Bitfields. Lets imagine that you have a list of 20 items. These items have the following 3 identifiable features:
Item Name || Item Type || Item Owner
Now lets say that you have 20 of these items stored in your database each with a value to go under one of the three aforementioned fields. Surely you would not want to manually enter in all 20 items directly into the database. Instead you would need to use bitfields:
PHP Code:
$items=$vbulletin->db->query_write("SELECT FROM " . TABLE_PREFIX . "Items name,type,owner");
The above script queries the database to retrieve all results within table Items and then goes through each row one by one and evaluates the individual row as an array within the template.
In the template itembits we have the following code:
And we can display all of these bits that were processed in the php script (all 20 of them displayed in the format setup in the template itembits) by adding the following variable into our templates: $itembits.
Now all this is fine and dandy and pretty basic.
But you run into a small problem if there is the potential to have an infinite number of owners stored in an array each with its own specific details. Lets imagine that we want to display all the owners of the item and each of those owner's personal details in the same list. However, we do not know how many owners there are.
Lets pretend that $item['owner'] is stored in the database as a serialized multi-dimensional array and contains the identities and personal details of 200 owners (10 for each of the 20 $items).
There is an $owner[0] through $owner[19] for every item (20 in all). But remember we do not actually know how many there will be as new owners can be added at any time.
If we were to try to edit the template "itembits" to contain all the information of the owners we would have quite a job on our hands, and would be writing messy templates. Perhaps the best solution is to simply avoid this kind of issue all together but for those of you who want a way around it here is the solution:
PHP Code:
$items=$vbulletin->db->query_write("SELECT FROM " . TABLE_PREFIX . "Items name,type,owner");
//This variable will tell us which $itembit we are on.
$i=0;
//
while ($itembit = $vbulletin->db->fetch_array($items))
{
$itembit['owner']=unserialize($itembit['owner']);
$itembit['owner']=unserialize($itembit['owner']);
//this variable tells us which iteration of the $owner array we are on.
$m=0;
//
foreach($itembit['owner'] as $value){
$itembit['owner'][$m]=$value;
/*here is the key, we make the bitfield variable for Owner an array with an autoincrementing pointer value so that it will output a different listing of owners depending on which item is being processed.*/
eval('$itemownerbits[$i] .= "' . fetch_template('itemownerbits') . '";');
//autoincrement the value $m so we process all owners for this item.
$m++;
}
//The old bit of code. The values of $item['owner'] $item['name'] and $item['type'] are still available here.
eval('$itembits .= "' . fetch_template('itembits') . '";');
//Auto incrementing this value moves us to the next item, $m (the array pointer for owner) is then reset to 0 and we cycle through it which a new set of Owners for the new item.
$i++;
}
Is this example rather ridiculous? Is the solution rather simple? Is this solution (especially in this example) an inefficient solution to the problem?
The answer is probably "Yes" for all of the above.
However, I have come across certain specific situations that have required this kind of implementation, and I figured I would share a solution that has aided me a couple of times.
Next Article: Transdimensional Bitfields Within Transdimensional Bitfields
(Using a new object instance for each bitfield call... and two database queries...!!!!!!!111!1!!eleven)
08-07-2007, 10:00 PM
but for those of you who want a way around it here is the solution:
