First, sorry if this post is duplicated, I haven't found anything that explains my doubts.
I'm trying to develop a module to export at a user (admin) desired interval all the calendar entries to an iCalendar file (every course will have its own file), so programs like Sunbird can grab the file and process it.
Since it's gonna be my first module, any advise would be great.
Thank you in advance!
Hi Andreas,
I 'm not sure if you mean "module" as in "activity module", which IMHO would not be very appropriate, or generally as code. Assuming the second case:
You can do the most good of all by developing your program as an extension to calendar which people can add to their installations by following simple instructions. That way, we can possibly integrate it into the calendar so that it becomes part of Moodle eventually. In other words, it would be very helpful if you wrote the iCalendar conversion library in a way that allows it to be used from elsewhere as well. For example you could:
This way, you satisfy your requirements and also provide everyone else with icallib.php. I 'm sure there there will be many uses for it!
Good luck!
Jon
I 'm not sure if you mean "module" as in "activity module", which IMHO would not be very appropriate, or generally as code. Assuming the second case:
You can do the most good of all by developing your program as an extension to calendar which people can add to their installations by following simple instructions. That way, we can possibly integrate it into the calendar so that it becomes part of Moodle eventually. In other words, it would be very helpful if you wrote the iCalendar conversion library in a way that allows it to be used from elsewhere as well. For example you could:
- Put all "the real code" that converts to iCal format in a new file, e.g. /calendar/icallib.php. This would include any low-level functions as you see fit, plus at least one high-level function that accepts some parameters telling it what events to process and returns a string which can be written to a file (or maybe writes the file directly).
- Add all the code that you need for your application in a likely place, e.g. /admin/cron.php where it will get executed every once in a while.
This way, you satisfy your requirements and also provide everyone else with icallib.php. I 'm sure there there will be many uses for it!
Good luck!
Jon
Thanks for the quick reply!
When writing down the purpouses of this feature, I thought it would be great to let the user (admin) to choose when to write the calendar events to the iCal file.
Is it gonna be harder to let the user specify to do it after adding something to the calendar?
Thanks for your time!
When writing down the purpouses of this feature, I thought it would be great to let the user (admin) to choose when to write the calendar events to the iCal file.
Is it gonna be harder to let the user specify to do it after adding something to the calendar?
Thanks for your time!
With a good design it's not going to be harder at all. All it needs is a general-purpose high-level library function that accepts enough parameters to be instructed on what exactly to export. If you have that in your hands, then making a user interface with some forms and buttons to allow the admin to affect those parameters directly will be very easy.
For example: the calendar has a high-level function that displays a whole month. Inside this, it uses another high-level function that pulls events from the database given a time period and some filtering parameters. Using these two, it's very easy to display any month and give the user choice on what kind of events they want to see. The user interface is so simple it's almost an afterthought.
I don't mean to say that the UI is not important; indeed, in a way it's much more important than anything else in the code. My point is that a well-designed library can pretty much work with any UI you might design for it; this is good, because it lets you freely change and modify the (very important) UI until you get it just right.
Cheers!
For example: the calendar has a high-level function that displays a whole month. Inside this, it uses another high-level function that pulls events from the database given a time period and some filtering parameters. Using these two, it's very easy to display any month and give the user choice on what kind of events they want to see. The user interface is so simple it's almost an afterthought.
I don't mean to say that the UI is not important; indeed, in a way it's much more important than anything else in the code. My point is that a well-designed library can pretty much work with any UI you might design for it; this is good, because it lets you freely change and modify the (very important) UI until you get it just right.
Cheers!
I really apreciatt your help!
I'll give you a touch when the project is done. Hope it fits and helps others who looked for this.
Sincerely,
Andreas Calvo
I'll give you a touch when the project is done. Hope it fits and helps others who looked for this.
Sincerely,
Andreas Calvo
I'm trying to do something like that.
My question is: if i need to modify or add tables to control my options, wich whould be the best way: Adding it on "avtiity module installation" or with some aside web installation for my module?
Thanks.
My question is: if i need to modify or add tables to control my options, wich whould be the best way: Adding it on "avtiity module installation" or with some aside web installation for my module?
Thanks.
If you need to control options, there are two ready-made mechanisms that should suffice 99% of the time. Try to use those if possible, this will be much easier for you and also more Moodly! 
Jon
- For options common to everyone (i.e., configuration state of the program), you can use set_config('prefix_XXX', $value) where prefix is something short, unique and descriptive that will keep your options from conflicting with other options and XXX is the name of the option. You can then retrieve the options any time you like, e.g. echo $CFG->prefix_XXX;
- For options specific to each user, set_user_preferences and get_user_preferences (defined in moodlelib.php) will do just about the same as above.
Jon
I'm working on that already 
Whenever it is finished I'd like to show you to see if it is completely ok with moodle/calendar.
Whenever it is finished I'd like to show you to see if it is completely ok with moodle/calendar.
I 'll be very happy to see it!
Well, we're almost at 50% of the work, but we're seeing some things that are hard to understand...
how to handle a repeat event? Wouldn't be better to let the user specify the interval? What is the purpouse of repeatid column?
Well, after studying a little bit the iCal, we've noticed that there are a lot of new possibilities to add to the calendar (like a ToDo, alarms, ...), is this gonna be added to the calendar? What is the current ToDo of the calendar?
Thanks Jon for spending your time answering my questions.
how to handle a repeat event? Wouldn't be better to let the user specify the interval? What is the purpouse of repeatid column?
Well, after studying a little bit the iCal, we've noticed that there are a lot of new possibilities to add to the calendar (like a ToDo, alarms, ...), is this gonna be added to the calendar? What is the current ToDo of the calendar?
Thanks Jon for spending your time answering my questions.
Hi Andreas,
I don't quite understand the first two questions.
Currently repeat events work as follows: when an event is to be repeated three times, three separate events are created in the calendar. These three events have the same repeatid value to mark that they are part of the same series (otherwise, repeatid would be 0). Thus, repeatid does not refer to another table but instead a repeatid value != 0 for an event means that the event is part of a series. To get hold of the other events of the series, simply get all events with the same repeatid.
I agree that there are very interesting things that could be added to the calendar. Right now however I don't have much time to work on it, so the open calendar issues in the bugtracker are the unofficial todo list.
Also, look at your private messages.
I don't quite understand the first two questions.
Currently repeat events work as follows: when an event is to be repeated three times, three separate events are created in the calendar. These three events have the same repeatid value to mark that they are part of the same series (otherwise, repeatid would be 0). Thus, repeatid does not refer to another table but instead a repeatid value != 0 for an event means that the event is part of a series. To get hold of the other events of the series, simply get all events with the same repeatid.
I agree that there are very interesting things that could be added to the calendar. Right now however I don't have much time to work on it, so the open calendar issues in the bugtracker are the unofficial todo list.
Also, look at your private messages.
Andreas, I had some thoughts about an option for an iCal link in the calendar module. I posted the details on this forum. This is not as broad an application as your plans as alarms would depend on the client used (e.g. Sunbird) and repeat functions would be the domain of the current calendar. Still interested in your thoughts as it may be quicker to implement and could work within the current calendar module.
Wondering if there's been any progress on this enhancement to the calendar module? My experience with PHP and iCal is extremely limited but if we've come to a standstill on this i'd be happy to give it a shot. At least to add the very basic functionality of adding a link to download an individual item in icalendar format. The modification of the Moodle Calendar so that it can truly be used as an enterprise wide calendaring system is something we're very interested in and the ability to download its items into Outlook which is what our administrative users use is critical to that.