LCMS Changelog

From Dokeos

Jump to: navigation, search

This page lists (semi-)important changes to the Dokeos 2.0 code in chronological order. The list is not supposed to be an overview of every single change made, but only those which will more then likely affect other contributors. Feel free to list big changes in your own (sub)projects though.

Contents

May 2008

2008-05-29

  • The commonly used RepositoryUtilities (build_toolbar, underscore_to_camelcase, etc) has been replaced by DokeosUtilities and moved to the common library folder. It was being used about 45 time sin the repository and over 170 times on the rest of the platform, so it does make more sense to have it there.
  • Tables were somewhat more generalized therefore eleminating 5 files for every kind of table. Their functionality was identical apart from some differences in namegiving of 2 functions in the DataProvider-class of each table. These names were generalized and the shared classes moved to the common libraries folder. BrowserTable- and BrowserTableDataProvider-classes should now extend the ObjectTable- and ObjectTableDataProvider-classes. The BrowserTableCellRenderer- and BrowserTableColumnModel-classes still extend a DefaultBrowserTableCellRenderer- and DefaultBrowserTableColumnModel. This prevents us from having to redefine some recurring columns in different types of similar tables. (e.g. RepositoryBrowserTable and RecycleBinBrowser). These Default-classes do extend the general classes as available in the common libraries folder.

2008-05-28

  • File and foldernames were / are being standardized. Please also take a look at the PEAR coding conventions. Dokeos 2.0 will try and follow them as much as possible, apart from the naming conventions. For class-names we use camelcase only (so no underscores) and for methods and functions we use lowercase only AND underscores. Filenames in Dokeos 2.0 should use lowercase and underscores (as opposed to quite a few files which had lowercase but no underscores right now), the same applies to foldernames wherever possible. These rules, of course, do not apply to external packages you might want to use in the project. A complete Dokeos 2.0 Coding Conventions page will be provided in the near future.

2008-05-07

  • PlatformSession was renamed to Session (issues due to identical names have been resolved, so why not make it shorter). You should ALWAYS access session variables via this class and NOT via $_SESSION
  • Cookie-class introduced to allow manipulation of cookies, again use this class INSTEAD of $_COOKIE
  • Request-class introduced to retrieve data from global variables like $_GET, $_POST, $_FILES, $_SERVER and $_ENV. The class filters / will filter (work in progress) the content of POST- and GET-variables thus protecting against a whole variety of attacks.
  • Security-class introduced, porting a number of different functions from Dokeos 1.8.x to 2.x
  • CSS code cleaned and split per application where and if possible, please keep it clean !

April 2008

2008-04-17

  • Theme-class introduced. Dokeos 2.0's theme can now be configured. (finally) The Theme-class is also used to retrieve the paths to the css files and the icon folders. (given that they depend on the theme selection and that it didn't make sense to push it all into the Path-class). The class is located in /common/html/. Nice side-effect: it should be possible to set set a different theme for every single page on the platform. (Dokeos Company introduced something similar for courses / users in 1.8.5)
  • PlatformSetting-class introduced. When getting an instance of this class it'll automatically load all configurable settings into an array. Values can be retrieved by using the same kind of syntax previously used in the Path and Translation-classes. That is: PlatformSetting :: get(). It'll automatically create an instance of the class, in case it doesn't exist yet. The function takes 2 parameters: the variable to look up and, non-obligatory, the application. In case no application is given, the admin (= platform) will be taken. One can still contact the AdminDataManager directly to get a specific Setting-object. But for retrieval of settings this new class should be somewhat more transparent.

2008-04-15

  • Personal Calendar application rewritten / restructured. It should now be far easier to extend it. Object-changes: PersonalCalendarEvent has been replaced by CalendarEventPublication. PersonalCalendarEvent has become a container of sorts to allow calendar input from a variety of applications.

2008-04-08

  • Breadcrumbs are now rendered via their own classes. BreadcrumbTrail for the entire thing and Breadcrumb for each individual step. Examples can be found in about every component throughout the system. The 2 classes are located in ~/common/html/
  • Translation :: get_lang() renamed to Translation :: get()
  • Path :: get_path() renamed to Path :: get()
Personal tools