Tiki Wiki CMS Groupware

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 ... [More] 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: lib/core/Services/Broker.php lib/core/Services/Comment/Controller.php templates/comment/*.tpl [Less]

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 ... [More] 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: lib/core/Services/Broker.php lib/core/Services/Comment/Controller.php templates/comment/*.tpl [Less]

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 ... [More] 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: lib/core/Services/Broker.php lib/core/Services/Comment/Controller.php templates/comment/*.tpl [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it’s not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]

Tiki8 is coming up with a few minor changes. The permission definitions were moved out of the database, allowing for easier maintenance and adding of new properties. The category permission screen no longer lists the global-only permissions and the ... [More] object permission lists now also display additional permissions that can be applied to the object outside of the direct type. When making the permissions global, the correct list is also extracted, fixing long time issues with scope checking of permissions. The newest change is the introduction of a Signal/Slot type of mechanism to handle events within Tiki. It will allow to connect features through hooks rather than having to go directly in the code to check the feature and adding an extra call, leading to extremely long functions with sequential operations. As a side benefit, it will also allow customizers to plug in new behaviors without affecting the core, making it easier to contribute and to maintain, for those cases where the feature is too specific to be contributed back. So far, it has been partially deployed for wiki page update and creation. Much of the functionality in there still needs to be extracted, but the skeleton is in place. Events are organized in hierarchies, allowing for functionality that applies to all object types to be bound at a single location. For example, $tikilib->update_page(...) will trigger tiki.wiki.update, which chains to tiki.wiki.save, which chains to tiki.save. Each event can have multiple functions or methods bound to it. At this time, binding happens in a single location: lib/setup/events.php. This will change in the future to allow late event binding and speed up the setup process. However, since there is very little at this time, it's not much of an issue. From Admin > Features > Programmer, you can see a graphical representation of the events in the system, updated live as they are deployed. The graph engine used by transitions was refactored to reduce code duplication and can now be used with very few lines of code. [Less]