Well, it’s been a bit longer in the making than I had originally planned, but 1.6 is now ready for beta testing (definitely not yet ready for production use!). Of course the primary goal of this release has been to introduce support for recurring events, which is in place and working pretty well. In addition to that, a few other nice features have been added including the ability to copy events in the calendar and improved remote exception handling, as well as a lot of bug fixes. Check the release notes for details.
Before We Begin…
Recurrence is an extremely complex area to delve into. There are many different potential approaches to implementing it, and there is no single standard for doing so. The de facto standard for dealing with the data for recurrence is the RFC 2445 iCalendar standard, which specifies the syntax for recurrence (among many other things). The most practical reference I’ve found for using the RFC is here.
While the data format is (pretty) clearly defined, there is no clear-cut standard for actually implementing recurrence in a real system. It’s easy enough to construct and parse an RRULE string, but how do you actually translate that into a working set of calendar events? How do you handle the myriad ways in which recurring events can be edited?
It’s important to understand up front that the bulk of the complexity you’ll encounter in your own implementation will be on the back end. Luckily, all of the UI complexity has been (hopefully) taken care of for you by Extensible. I’ve also provided a basic example implementation in PHP, but it’s by no means a canonical, drop-in solution. In fact, it can still use some improvement (more on this below) and I am quite open to improving it before the final release. With that said…
Getting Started with Recurrence
I’m not going to get in depth on implementing the back end portion in this article. In fact, I’m planning a dedicated series of posts that will cover the overall theory and architecture of recurrence as well as all of the different choices to consider when dealing with it on the back end (this post will already be long enough!). For now, I’m going to focus on simply setting up recurrence in Extensible, which is quite simple.
To enable the recurrence field in the event edit form, you can simply add the new
recurrence config to your CalendarPanel:
title: 'Recurrence Calendar',
recurrence: true // That's it!
That’s all it takes to get this field to show up in your form (by default it is only in the detailed edit form, not the simple editing popup window):
Just be aware though that your server will have to be ready to accept and parse recurring events properly in order for this to be useful! The best place to start for now will be to look at the example implementation, the logic of which is primarily in the Event PHP model class. The source code is pretty heavily documented, so read through it to get an idea of what’s going on. I do realize though that it’s a bit intimidating, and a more detailed explanation and documentation is forthcoming…
Recurrence Data Mappings
The other addition on the Extensible side needed for recurrence are a few new model fields, which you can customize as usual via the
EventMappings class. They are
REditMode. Each new attribute is explained in the source, so take a look. Extensible already handles them on the client side, so you would simply add those into your existing data model code as needed.
Note that these model attributes are still subject to change if needed before the final release of 1.6!
Editing Recurring Events
Editing existing recurring events is where it gets a little more complicated, and for the UI side Extensible has a built-in component called the recurrence
RangeEditWindow, and it looks like this:
This is what sets the new
REditMode data attribute on your event, letting you know how to handle the recurrence edit action on the back end. Much more on this later…
So, Really… How Do I Use This?
The full beta release is available for download, or as always you can simply update from the master branch in Github if you’ve cloned/forked.
I know, I know. You need more documentation and more guidance on implementing the server side. I hear ya, and I’m working on that. Even though it’s a tad early from that perspective, I really wanted to put this release out now to start getting feedback on the usability of both the recurrence UI components and the API. I’m definitely hoping for some feedback during beta testing. I also expect that there are still a few bugs (and probably a regression or two) so please report any issues you find in the forums.
The hosted recurrence example is now live on the site, so even if you don’t feel like setting it up yourself right now you can still try it out and let me know what you think!
More to Come
As I’ve already mentioned, there is still a lot to do before 1.6 will be finalized. Here are the major items still on my plate:
I plan to complete all of the API docs, in addition to adding several tutorials and hopefully even a screencast before the final release.
- A Database Example
Initially I created the PHP example using the same session-based approach that the existing remote example uses, hoping it would keep things simple. While this does work, it’s become apparent to me that it requires too much code to essentially fake a data access layer. Not only is it complicated to maintain, it also makes the code overly complex for other developers looking at it, while reducing the reusability of the example. I very much hope to rewrite this example to use a simple DB implementation before final release (although it may not happen until afterwards, depending on the time required).
- Localization Improvements
At the moment, while the strings used inside the recurrence field can be easily changed, the layout of the interior fields cannot be. Before final release I plan to template these fields in such a way as to make their layouts fully customizable.
- Ext JS 3.x Support?
This may or may not happen. Originally I had intended recurrence to be the final major feature implemented for Extensible 1.0.x. However, after looking at how much effort it took to get recurrence to where it is now for Ext 4, porting it back into Extensible 1.0.x is looking increasingly not worth the effort. My sense is that most people are already moving to Ext 4, or will be soon, and I’d prefer to expend my energy creating new features to move Extensible forward. I am open to feedback from the community on this — if you are still using Extensible 1.0.x with no plans to upgrade and you were hoping to use recurrence, let me know soon. If I hear from enough people I may reconsider.
You Can Help!
Implementing the back end of recurrence is definitely going to be the hardest part for most developers, and my goal is to be able to provide useful starting points in more languages than just PHP. In my next post I’ll outline some existing third party recurrence libraries, but for now, if anyone integrates with an existing server library or API, or implements their own custom server-side recurrence handling, please post in the forums or send me a pull request to share back to the community!
Thanks for your patience if you read this far. I look forward to getting recurrence shipped and getting back to adding more new features to Extensible!