Difference between revisions of "Calendarv2"
From GeeklogWiki
(New page: What needs to be done till the alpha release? - Fix Ical Support. - Render recurring events immediately after it was created not just on page load. Future plans/improvements:) |
(→Thoughts:) |
||
| (11 intermediate revisions by 2 users 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> | ||
| + | * 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 [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.
