New comp running, bugtracker API ideas

In case you wonder why I didn’t post for some days… On Friday, my 480W PSU arrived, and I got my new comp up & running! Yeah! :) Had to move my development environment from my old disk to the new one, install all the tools I’m used to etc. so I didn’t have time for updating my blog. It really rocks, and although it sports 7 fans, it’s damn silent (thanks to temperature control). Really comfortable. After looking at the Mantis source code, I also started thinking about some API for my bugtracker. It should allow plugin developers to access core functionality in a clean, consistent manner, and also separate the core functions from the processing logic and the display logic.

Bugtracker API

At the moment, the API does support modules and classes. The difference between the two is:

• A class is - well, a class, that needs an instance in order to work properly, as it stores some local data. An example is the Bug class, after a getData() call it stores the results for reuse. Classes can be loaded by the API using API::getClass ('className', [... constructor]);. In order to get this working, two things have to happen:

  • A class instance has to be created.

  • The constructor needs to be called Unfortunately, I couldn’t find a way to call the class constructor directly, so I use this workaround:

    php $instance = @new $class_name (); // Silence the missing parameters call_user_func_array (array (&$instance, '__construct'), $args); // Now the real one

    This one does work, the warning that parameters are missing is silenced and everything is fine.

• Modules are basically classes that have only static methods - there is no need to create a class instance, you can directly call the functions. They’re accessed using API::getModule ('moduleName');.

I’ll move over all includes I can find to the API and try to clean up the code a bit before I continue working on the bugtracker. Stay tuned :)