Difference between revisions of "Calendarv2"

From GeeklogWiki
Jump to: navigation, search
(Future plans/improvements:)
(Thoughts:)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== What needs to be done till the alpha release? ==
 
== What needs to be done till the alpha release? ==
 
  
 
* Fix Ical Support. <br>
 
* Fix Ical Support. <br>
 
* Render recurring events immediately after an event was created, not just on page load.
 
* Render recurring events immediately after an event was created, not just on page load.
 +
* Review Security (specifically user access rights to events)
 +
** Make use of SEC_createToken, SEC_checkToken to preven CSRF attacks.
  
 
== Future plans/improvements: ==
 
== Future plans/improvements: ==
Line 9: Line 10:
 
* When Geeklog moves to PHP 5.3 (or earlier, as time permits) switch to using MySQL Datetime types. PHP 5.3's enhanced DateTime class makes the switch easier.
 
* When Geeklog moves to PHP 5.3 (or earlier, as time permits) switch to using MySQL Datetime types. PHP 5.3's enhanced DateTime class makes the switch easier.
 
* Conversion script to convert existing Geeklog calendars to Calendarv2.
 
* Conversion script to convert existing Geeklog calendars to Calendarv2.
 +
* Use PHP's locale settings for Day of Week, Month Names, etc instead of the language file [http://php.net/manual/en/function.setlocale.php]
 +
 +
== Thoughts: ==
 +
 +
* AEvents Class
 +
** Should the _events array be an associative array with the events' EIDs as keys?
 +
* Event Class
 +
** Should the class be aware of whether the event already exists in the DB? That way it know which of "update_to_database" and "save_to_database" function is appropriate?
 +
** Should the class be aware of whether the event is the moderation or event table? That way the "modify" and "modify_moderation" functions wouldn't be necessary (the class would know the appropriate table automatically).
 +
* addslashes is used extensively to sanitize input. Should Geeklog's filter routines be used instead in places?
 +
* upload.php -- mentioned in a previous email, but we should be using the upload.class.php that comes with Geeklog.
 +
* Geeklog allows the use of InnoDB tables. The calendar should use whatever table type the rest of Geeklog is using.

Latest revision as of 06:47, 15 December 2010

What needs to be done till the alpha release?

  • Fix Ical Support.
  • Render recurring events immediately after an event was created, not just on page load.
  • Review Security (specifically user access rights to events)
    • Make use of SEC_createToken, SEC_checkToken to preven CSRF attacks.

Future plans/improvements:

  • When Geeklog moves to PHP 5.3 (or earlier, as time permits) switch to using MySQL Datetime types. PHP 5.3's enhanced DateTime class makes the switch easier.
  • Conversion script to convert existing Geeklog calendars to Calendarv2.
  • Use PHP's locale settings for Day of Week, Month Names, etc instead of the language file [1]

Thoughts:

  • AEvents Class
    • Should the _events array be an associative array with the events' EIDs as keys?
  • Event Class
    • Should the class be aware of whether the event already exists in the DB? That way it know which of "update_to_database" and "save_to_database" function is appropriate?
    • Should the class be aware of whether the event is the moderation or event table? That way the "modify" and "modify_moderation" functions wouldn't be necessary (the class would know the appropriate table automatically).
  • addslashes is used extensively to sanitize input. Should Geeklog's filter routines be used instead in places?
  • upload.php -- mentioned in a previous email, but we should be using the upload.class.php that comes with Geeklog.
  • Geeklog allows the use of InnoDB tables. The calendar should use whatever table type the rest of Geeklog is using.