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 seperate 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: `$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. Sty tuned :)


Comments powered by Disqus