Tiki7 is yet to be released, but still there are some important changes are happening in trunk. Over the last few days, I rewrote most of the UI for comments. The objective was to use the same comments for trackers as for the rest of Tiki, but without having to handle those includes and global variables. The UI is now a full AJAX interface that merely requires linking from the template to be enabled. Old tracker comments were converted and now tracker comments benefit from threaded comments, locking, archiving, moderation and all of the other features that are expected from comments.
The new AJAX comment interface was also deployed everywhere object commenting was used. This transition allowed to clean up the old comments code that used to be shared between comments and forums (which still use the same database storage). From now on, comments.php and comments.tpl are only used for... forums. This should leave the code in a state that is much easier to understand and allow the forums to improve.
However, the big change comes with the comments. They are powered by a micro-MVC framework with the common controller/action paradigm. It handles content negociation, so it will return JSON or HTML depending on what is requested. When HTML is required, it will use a template matching the controller and action to render the data that would otherwise be sent to the client as JSON. If the call is made outside of an AJAX request, it will even render the request using the tiki.tpl frame. Essentially, there is a full MVC hidden inside tiki-ajax_services.php.
Even though the new AJAX interface appears to require JavaScript, it will work just fine without it as well. The user experience may be a step down from the previous one without JavaScript, but navigating without JavaScript is not really expected these days. As long as it works well enough for a crawler, it should be fine.
Of course, this is still very early stage. The javascript side of it is still in flux. Initially written for comments only, it is expected to evolve to cover more general cases. Much refinements are also required in the user interface for comments and some features might still be left to be converted.
What does this change?
Much of the controller code that was traditionally in the PHP file is moving to controller classes where helper methods can be created. Each action becomes an independent entity, reducing the amount of dependencies between code and the initialization mess typically found. Each action also now gets its own template as well, and those templates are separated into different directories by convention. Less files in the main folders might help keeping new developers. We also get a JSON API for free, although it's not the defined kind of API that will stay stable across releases.
The URLs are not pretty at this time. They would need rewrite rules if they get to be used significantly. The broker code can be called from other files at well. The set-up required is minor enough.
Check it out in trunk: