JThing v0.1

First and foremost, JThing is one of many little pet projects I do in my spare time (or when I really need a break from whatever current project). This effort is a personal exploration utilizing PHP5 and JSON, and is not intended to be (nor do I assert) that it is in fact useful, or even good. So, with that out of the way, I'll explain what JThing is and does.

The "J" in JThing is JSON, but the idea of Thing is something that I've picked up from the software company that employs me. A Thing is, .. well, just that; an object representing something, usually a record out of the database such as a User, Product, Transaction, Supplier, etc. (Oddly, ) I didn't find this explained in the Thing Documentation for the Knickers Framework authored by folks I work with, but it's an easy concept to get. While the Knickers Thing can do a heckuva lot more, a JThing can basically load, save, get, and set.

What's remarkable about JThing (imho) is that it stores data in files as JSON versus using a database. Two reasons really spring to mind when I think about why I wanted to go this way (beyond just scratching the itch):
•1) I had made (and remade several times, and will again) a clone of a psuedo trading card battle game. Naturally, games, players, and cards where stored in a DB, but when I last dusted it off to play a few rounds with my girlfriend, something occured to me. Card records in the DB never change. They are there and searchable, but every time a card appears in the game, some query is executed to fetch the same data it had dozens of times before. One thing that I learned from working on botzilla (an irc bot in php), is that working with flat files for data storage can sometimes be a better solution than using a DB. It depends on what you're doing I guess. Adding name to a list of "known users" is as easy as pushing onto an array and saving it thusly for next time: echo "username" >> known_users
•2) I wanted to be able to easily extend certain particulars of a single instance beyond the characteristics of a class. I often use baseball players as analogies when explaining classes and objects to people that don't know. One could program a basic BaseballPlayer class that has all of the basic throw(), catch(), run(), bat() methods, but any fan of the game knows that there are some specialties that other players have — and I use Pitcher and Catcher to explain inheritence by extention. class Catcher extends BaseballPlayer Catcher is now free to add any additional methods it needs to do its job, and remains a class that produce many new Catchers for the whole league. Pitcher likewise is an extended class, but with an overridden throw method. For JThing, I wanted to get a little personal with these guys, adding room for properties unique from other players.

/* $joeBlow = new BaseballPlayer($joeID); */ // old/common way

$joeBlow = JFac::get("BaseballPlayer" , $joeID); //get from JThing Factory

// "color" joe's personal life
$joeBlow->set( array
	(
		'tattoos'=>array
		(
			'left-shoulder'=>"I <3 urmom",
			'chest'=>"dragon crest"
		),
		'drinking_problem'=>true,
		'marital_affairs'=>3,
		'scars'=>array
		(
			'left-acl',
			'right-wrist'
		)
	)
);
// other instances of BaseballPlayer may not have these.

This could also be helpful in times where every instance of a class can be unique for its own sake. Take for example, a WoW type series of weapons. (Disclaimer: I don't play WoW, never have. So I don't know how accurate this is, but humor me). Say that there is a basic axe, a better axe, and an amazing axe.

class Axe extends JThing
{
	/* basic axe properties; 
	two handed, slow moving, beefy */
}

class BattleAxe extends Axe
{
	/* larger size, higher player level requirement,
	   slower swing, bigger hit */
}

// Now lets' create a one of a kind amazing instance

$axeOnFire = JFac::get("BattleAxe"); // a new BattleAxe
$axeOnFire->set( array
	(
	'weight' => $axeOnFire->get('weight') / .75,  // lighter to carry
	'elemental'=>'fire', // attacks with fire
	'visualiztion'=>array
		(
			'effect' => 'on_fire',
			'visible' => 'always'
		)
	) 
); // this also saves the instance to BattleAxe/{newid}

Whether or not these modification mean anything to your application, the data is available for this object from now on. There is a directory of all the BattleAxes ever made, but this one is on fire!!.

Storage

This is to me the beauty of JThing. It stores data in type based directories, using ids as file names as JSON. This is good for botzilla and a few other small applications that I'm working on (or dreaming up); but obviously not ideal for all situations. No database connection/query overhead. Records just are what they are.

~/_json/Game/1
	{"players":[{"JThing":"User","type":"Player","id":1},{"JThing":"User","type":"Player","id":2}]}
~/_json/Game/2
	{"players":[{"JThing":"User","type":"Player","id":2},{"JThing":"User","type":"Player","id":3}]}
~/_json/Player/1
	{"name":"bibby", "password":"passwd", "wins":1, "losses":0}
~/_json/Player/2
	{"name":"bibbles", "password":"passwd", "wins":1, "losses":1}
~/_json/Player/3
	{"name":"bbby", "password":"passwd", "wins":0, "losses":1}

The problem however is searching. Right now, grep appears to be the best answer without parsing all records. Also, "reporting" is off the table for now. But now that the data is stored as JSON, there's a lot of different things that can access it freely, either directly with javascript (if world readable) like a weather/news service, or by something like botzilla that can decode and use it as an application component.

Source

Check out the current source for JThing and its Factory JFac. This sortware is free.

Here is a test page that sets some scalar values to property names you decide. I've noticed that it segfaults when the last item is removed, so beware of that ;) obvi this is not compeltely done.