Loading...
 

In the trenches

January 17th, Montreal

Louis-Philippe Huberdeau Monday 17 January, 2011

It is often criticized that the source code in Tiki is not object-oriented enough. There are several issues this brings up when adapting the code to new needs. Most of which are code duplication, inconsistency in behavior and growing functions with loosely coupled concepts. There have been multiple proposals in the past which resulted in little to no results. The following factors may be the cause:

  1. Lack of involvement, multiple +1 but no actual actions taken
  2. Drastic changes required, effort needed is higher than what anyone can commit to
  3. Problem more complex than it appeared, implementation eventually abandoned
  4. Implementation essentially done, but not deployed all the way through and left unfinished, rotting into obsolescence


To this day, one of the most successful refactoring made in Tiki was the dynamic preferences even if it required a massive effort and extended over multiple releases (hello pkdille!). The reason that lead to success were:

  • Clear benefits to end users (consistency in UI, additional documentation, configuration search)
  • Significant clean-up of the code making it easier for developers too
  • Easy to understand and deploy
  • Can be deployed gradually without causing drawbacks


Not all required changes are as easy to deploy and will have as a direct benefit to the end user, but it is almost guaranteed that changes that are purely aesthetic will fail to gain traction. Simply going 'object oriented' won't cut it. Design methods using object oriented are good, but not a holy grail or a goal to aim for. Great design patterns are built and described using object oriented features, but implementing a pattern is not an objective either. Desired properties and behaviors of the code must be identified, than a design can be selected.

The classes used as function libraries are not a bad thing in themselves. TikiLib is an issue because it is too large and contains completely unrelated functions, but the other ones provide a good overview to what is available for a given feature. Something that is often crucially missing in well design object oriented libraries. The concept is entrenched in Tiki and thinking it will go away is wishful thinking.

The problems lie within those libraries, not in their existence. Tiki should provide better utilities for developers than it does now, but going for a share parent class will only bring back to the same issues we have right now with TikiLib.

There are a few common patterns in Tiki that lead to code smell. Targeting those patterns would lead to better code. It may be subtle, but work has begun a long time ago.

  • Listing functions in the libraries have a growing number of arguments. The ordering is only based on the evolution of the function itself. Multiple filters and formatting options appear and cause the hand-built SQL to be low-performing, hard to debug and generally unstable
  • CRUD functionality is essentially composed of a hand-built SQL query. Depending on some preferences, the data may be altered or the operation may be prevented at all. After the actual update of the data, various other operations are performed, like updating indexes, user scores, backlinks, contributions and a whole series of other manipulations. Somewhere in the process, notifications are sent out.
  • The PHP files in the Tiki root simply perform too much work and have no consistency on how tasks are performed.


The Unified Search project aims at the listing issue by providing a flexible search index interface allowing for customizable output formatting and advanced filtering. The need for these parameters will be scaled down as we move forward. Perhaps we can begin to remove them.

The SQL query building part could easily be solved using database utility methods. It would reduce the amount of errors made and simplify the code. It can easily be deployed over time

The pre and post behavior could be triggered through the SignalSlot pattern, allowing external code to hook into the save process without affecting the actual library. A data container could be sent around for the pre hooks to allow them to alter the data or interrupt the chain altogether. The cross-feature behaviors could be registered only once and apply where needed.

A drawback of this approach is that the code becomes harder to trace. As there are more dynamic bindings, knowing which pieces of code run becomes more of an issue. To mitigate this, the data container could contain a debug log for the different pieces of code to indicate that they ran and summarize what they did, allowing developers to look into what happened.

Forms are always defined in template file. The PHP file then collects the input in a ad-hoc manner, converts the format into what is expected by the library (which is close to the database in most cases). The library then pushes the data to the database. Better facilities are required to collect the data from the request and in many case, the format taken by the library has to be standardized. Just like list functions, the order of the arguments is arbitrary in most cases.

Tiki should provide functionality to support form validation, both on the PHP side and on the browser side. This could be done in a number of ways, but could be composed of form field configurations and smarty plugins to include within the forms. The additions should remain a toolkit rather than an obligation to allow for gradual deployment and preserve the flexibility.

Preserving the environment is always an issue. Compatibility has to be maintained, expectations must be met. Developers have been used to flexibility in Tiki and any framework that constrains what can be done (remember Magic?) is likely not to gain support. The codebase is large and not everything can be done within a single release cycle.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools