A few weeks ago, Mats Bryntse (mankz on the ExtJS forums) asked me if I would be interested in taking a look under the hood of his Ext Scheduler application. There has been a great deal of buzz in the ExtJS community over his tool, so I jumped at the chance to peek into his source code. We’ve never actually met in person, but Mats seems like a good guy and he has a lot of good insight on the ExtJS forums. Apparently Mankz is also a DJ; I did not know that!
Disclaimer: Mats granted me a free license to use the tool in exchange for my review.
After unzipping the source code, I poked through a few of the examples. At first glance I was very impressed! The download came packaged with six demos, each of which utilizes different ExtJS features and gathers data via different sources (eBay, Google Calendar, among others). My only immediate complaint was that the API documentation wasn’t included in the ZIP file. It is however freely available on the Ext Scheduler website here.
Let’s Build Something Fun!
Rather than just saying what the Ext Scheduler does… let’s build something! Since Ext Scheduler’s website already has a handful of examples, I’d like to try building something new — let’s use the Twitter API and map when our tweets are posted.
A quick note: I didn’t realize something important until I was almost done with this application – the Twitter API doesn’t allow you to grab tweets based on a given time frame. You’re only allowed to grab the last X tweets… which I think is pretty lame. Had I know that before starting this application, I would have chosen a better example. *Facepalm!*
My journey through the Ext Scheduler started with a quick look through the API docs. The basis for the entire application is the Sch.SchedulerPanel() class, which is an extension of the Ext.grid.GridPanel(). If you read the API docs for this class, you’ll learn that it depends on two data stores: the first (“Store”) defines the various categories/rows for your application, while the other (“EventStore”) defines the events displayed on our schedule.
For my sample application, the “Store” will consist of a single Twitter user and the “EventStore” will be filled with this user’s 50 most recent Tweets. Thus, my application only has one row on the grid (boring, I know). I chose to display my grid as a 24 hour day so we can see our user’s Twitter activity over the course of a single day. Toolbar buttons allow us to move forward/backward by day. (Since the Twitter API doesn’t take start/end date parameters, this functionality is somewhat pointless.)
Take a moment now and try my sample application. We’ll explore it in more detail below, but see the source code here.
Learning Curve
My only real complaint with the Ext Scheduler code is the fact that there’s a slight learning curve. The examples provided in my ZIP folder are great, but there’s so much going on in each demo that it’s hard to figure out the basics. It took me the better part of a day to get my application working, so be prepared for a little bit of frustration.
Don’t get me wrong – this is an awesome tool, and I had the same complaints about ExtJS when I first started too. As such, I’m hoping this review can be a step-by-step demonstration on how to get started.
Step One: Define Your Categories
The “CategoryStore” is used for our left-hand grid labels – the entities to which the events are associated. In some of the other Ext Scheduler examples, the “Categories” were often people; the “Events” were often meetings or other appointments.
I started my application by prompting the user for their Twitter username. If you open my source file, you’ll see that I take the user’s input and insert it as a new data record into my TwitterApp.Scheduler.categoryStore (an Ext.data.JsonStore()). That was easy!
Next, I call the init() method on my TwitterApp.Scheduler object (a generic literal), which calls a series of other methods. In essence, here’s what they do:
- Set this.start and this.end (values needed to properly display data in our schedule)
- Create and load our “EventStore” (we’ll come back to this in a moment)
- Create the scheduler grid and render it to the UI
Step Two: Define Your Events
As I just mentioned, we need to create and load the event data to display on our schedule. See the following code:
Our “EventStore” is another simple Ext.data.JsonStore() object; however, I’m pulling the data for this store from the Twitter API (based on the supplied username).
Take note of the “start” and “end” base parameters on this store. Although Twitter doesn’t really need them (which is why this example kinda sucks), the Ext Scheduler classes do! If you don’t add these parameters you’ll get an error!
When this store finishes loading (see my LOAD event), I manually set the “EndDate” property for each record because Ext Scheduler needs this information.
Step Three: Create the UI
Once we have our categories and events defined, we have the data we need to display the Ext Scheduler UI.
The Sch.SchedulerPanel() class is an extension of the ExtJS GridPanel(). The only things we really need to be aware of are the autoViews property and the eventTemplate since they’re the two things which really affect the appearance of our tool.
For the autoViews, you have your choice of displaying the grid by days/week, hours/day and a few other options. Since we’re using Twitter, I thought hours/day was most appropriate.
For the eventTemplate, it’s important to create an Ext.Template() object that means something to your users. Looking at the other examples of Ext Scheduler, you might see the name of the event, its start/end times, or other descriptive information. My example isn’t as cool… but you get the idea.
The only other thing I should point out is that your users will probably want a way to change the date range displayed by our scheduler grid. I added “Previous” and “Next” buttons which essentially alter the start/end date and reload our “event” data.
Step Four: Brag about your tool!
As I already pointed out, the Twitter API was a terrible choice for this demo because it doesn’t allow me to search for tweets by a selected date range. It was also a bad example because tweets don’t have start/end dates. Note to self: choose better examples next time!
Overall, my impression is that the Ext Scheduler will be an invaluable tool for most developers working with “events”. It’s easy to work with, offers an impressive set of features and should impress a lot of end-users. I would encourage everyone to check out the other Ext Scheduler examples and see for yourself!
