This new release of 1.3x of the Orbit42-Base class brings us up to the stable marker after which work on varients for other data systems can be begin in ernest.
I have also released a simple example pack that cntains the development copy of the "responder" class.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it now a PHP5 class. I still have no clue what callback is for...
All you have to do is make a constuctor and call db_connect in it. Also just add public to every function (cept the private ones) and then you have a PHP5 class.
I have been working on some webservices for second life and i really like using orbit. I like to embed orbit into another class. For example in one of my classes i put
class test
{
protected orbit_local;
function __contruct()
{
$this->orbit_local() = new orbit_base;
$data = 'SELECT * FROM BLAH';
$result = $this->orbit_local->db_sql_return($data);
}
}
It is pretty cool. Like i said i still i have no clue how to do the callback and most of the other functions. So far I have only used the data access functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very technically it is a php4 class but it should work as both.
Callback requires a call back processor (another class) so that class->function can be called when a subscribed event is triggered. In 1.x you had to call the callback yourself in 2.x you simply fired a $this->hook(...) to create a name-space for child classes patterned extender_hookname_classname($data) with event_hookname as the event.
This gives you scale-scope and a plug-in system ready made (well, an admin area for subscribing your plugs to events would be needed but that's a CMS issue).
3.0.x which is just around the corner uses the same syntax and API as 2.x with the easy to run with database calls but separates them into files one for each layer of the cake. (foundation, callback, data, baseclass). In theory 3.0.x should drop in where 2.x was and carry right on working (same for 2.6 over 1.3). However, 3.0.x has a separate connection manager allowing multiple connections to be handled. This also stops the chain of connection passing errors and a few other issues that can happen with the current system.
2.6 came out today as "BLOGCLUE Edition" because blogclue.com are using it and this led to a half dozen bug fixes.
I'm hoping 3.0.x will be even more nice to use and with any luck 3.1.x will have a rudimentary callback manager as standard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This new release of 1.3x of the Orbit42-Base class brings us up to the stable marker after which work on varients for other data systems can be begin in ernest.
I have also released a simple example pack that cntains the development copy of the "responder" class.
Is it now a PHP5 class. I still have no clue what callback is for...
All you have to do is make a constuctor and call db_connect in it. Also just add public to every function (cept the private ones) and then you have a PHP5 class.
I have been working on some webservices for second life and i really like using orbit. I like to embed orbit into another class. For example in one of my classes i put
class test
{
protected orbit_local;
function __contruct()
{
$this->orbit_local() = new orbit_base;
$data = 'SELECT * FROM BLAH';
$result = $this->orbit_local->db_sql_return($data);
}
}
It is pretty cool. Like i said i still i have no clue how to do the callback and most of the other functions. So far I have only used the data access functions.
Very technically it is a php4 class but it should work as both.
Callback requires a call back processor (another class) so that class->function can be called when a subscribed event is triggered. In 1.x you had to call the callback yourself in 2.x you simply fired a $this->hook(...) to create a name-space for child classes patterned extender_hookname_classname($data) with event_hookname as the event.
This gives you scale-scope and a plug-in system ready made (well, an admin area for subscribing your plugs to events would be needed but that's a CMS issue).
3.0.x which is just around the corner uses the same syntax and API as 2.x with the easy to run with database calls but separates them into files one for each layer of the cake. (foundation, callback, data, baseclass). In theory 3.0.x should drop in where 2.x was and carry right on working (same for 2.6 over 1.3). However, 3.0.x has a separate connection manager allowing multiple connections to be handled. This also stops the chain of connection passing errors and a few other issues that can happen with the current system.
2.6 came out today as "BLOGCLUE Edition" because blogclue.com are using it and this led to a half dozen bug fixes.
I'm hoping 3.0.x will be even more nice to use and with any luck 3.1.x will have a rudimentary callback manager as standard.