A few days ago, a new Calendar contributor, Fred Jendrzejewski, fixed bug 455728 and bug 455733. I believe that what he experienced here might be beneficial for other would-be contributors, so I asked him to write about his experience in the calendar codebase. Here is his report:
-
Some introducing things
Few weeks ago I started to work on the mozilla calendar code. My first interesting patches became available in the nightly builds last week and I would like to report about my experience. As this is my first blog post for the mozilla community, I will introduce myself shortly. I am a German 22-year-old physic student in his last year. Since two years I have the great pleasure to live in Paris and to get to know the French way of life (I love it).A few months ago, I started to work on the Spicebird project, but the problems in the calendar code also catched my attention. I began working on the task / event lists and didn’t like that everything was written twice. The idea was that tasks and events are very similar. This property is used almost everywhere in the code( by the calIItemBase object), except those trees. So I decided, highly motivated, to rewrite the two trees and to work on the simpler code.
So, I asked Philipp and Berend for there opinions and they liked it, but over time, the tree code became so complex that it was almost impossible to review the patches nicely. I had to step back and simplify the code first. Following Berends proposition, I started to sort out the hole mechanism for sorting and filtering items in the trees.
-
The new way of sorting and filtering
So I sorted out functions, modified the code and abstracted it. If you want to sort a item array now, you don’t need to write this function completely by your own: you can use a preset of sort functions in the calUtils.js file. Even more practical is the solution for the filtering. We now have a calFilter object, which can handle the most common filtering mechanisms for you. We now have built-in solutions for property filtering and date filters.First, you can associate a text field for text search to the filter object, just by passing the id as a string to the text-field to the filter. Another possibility is to set a property filter out of the property filter bag (a predefined set of filter functions) in the calFilter object. This code is just one string away from usage, as the text-field filter. If you don’t like any of the built-in functions, you also can write your own filter function and set it as the property filter of the calFilter object.
Here again, the date filter can use a predefined set of times (today, this week…). But you can also write your own date filter. To filter out the next 8 days you have to pass the string to the calFilter and it should work already. You’ll still have the possibility to set the start and the end date manually. This is done in only one line.Why is it nicer? I think that these are some nice functions that developers of the core code and for extensions can use. If they find other very common filter functions the filter bags can be extended easily. So actually I have cleaned up the trees now and we have created a first common set of filter and sort functions in the calendar code, that can be used as a standard implementation.
-
What will come?
Now I started to work on a unification of observers and tree internal mechanisms. It seems possible to have only one tree implementation with only minor modifications for the event or task tree. Wait and see…