Detecting Leaks with Siesta

Siesta, an awesome general-purpose unit and UI testing tool by the fine folks at Bryntum, includes a handy feature that allows you to automatically check for unexpected globals added during test runs. When setting up your test harness, you simply enable monitoring and define any expected globals like so:

Harness.configure({
    ...
    autoCheckGlobals: true,
    expectedGlobals: ['Ext', 'Extensible']
});

If anything unexpected shows up in global scope during testing it gets flagged as a test failure — awesome!

However, tracking down the offending code can sometimes be tricky. The simple approach is to search in your project for instances of variable assignment. If you are leaking a variable named foo, a search on “foo =” will likely locate the problem code pretty quickly. In my case, I was leaking a variable named el, which is only assigned about a bazillion times in Extensible. My initial search returned a ton of matches, so it was time to think of something quicker.

Locating any Leak Instantly

A cool trick you can do in JavaScript is to override getter and setter functions (in modern browsers at least, I’m using Chrome). Thinking about it, adding a global is really the same thing as “setting a property” on the built-in window object, so I figured you should be able to do something like this:

window.__defineSetter__('el', function() {
    debugger;
});

I threw that into the top of my test case and refreshed, and instantly the browser paused in the console right on the debugger; line. Looking at the previous line in the stack trace showed me this lovely piece of code in the calendar’s Month view:

if (el = e.getTarget(this.moreSelector, 3)) {

Oy. I don’t write code like that any more, but this was a holdover from several years ago that simply never got noticed before. A simple fix that literally took seconds to find with this handy little hack.

Don’t Forget to Remove Your Hack

One gotcha that took a few minutes for me to realize… this hack itself, by defining the setter function, is effectively adding the exact same property to the global scope (you end up with a property called window.el by doing this). So Siesta will still see window.el after the test and register a failure, but if you’ve fixed the actual bug, the debugger; line will no longer be hit. This was momentarily confusing, but once I realized what was happening and simply removed my temporary setter override, everything worked with no errors.

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.

Enabling Recurrence

To enable the recurrence field in the event edit form, you can simply add the new recurrence config to your CalendarPanel:

Ext.create('Extensible.calendar.CalendarPanel', {
        eventStore: eventStore,
        calendarStore: calendarStore,
        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 RRule, Duration, OriginalEventId, RInstanceStartDate and 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:

• Documentation!
  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!

Anyway… We’ve also moved the feed over to FeedBurner as long as things were already changing, so you might want to update your subscription to the new feed url (or take this opportunity to subscribe if you haven’t already!).

A quick update on Calendar Pro — the first release of recurrence is done and just about ready for a beta release. I’m finalizing it now and will be pushing out a release within the next day or two for testing and feedback. It still needs a lot of documentation and undoubtedly has a few bugs, but I’d love to start getting input from the community ASAP.  It’s been a longer road than expected, so I’m excited to get this thing shipped and start moving toward the next set of features.

Stay tuned!

I’ll have a lot of details about implementation along with a version for testing in my next post, coming very soon…

Ext.getVersion() is Your Friend

Earlier in the development cycle of Ext 4.1, I realized that all of my XTemplate subclasses stopped rendering output correctly. In Extensible I override the applyTemplate method in my custom template classes to customize the incoming data object before it gets applied and generated to markup. At the time of the issue, XTemplate had already been switched to support the new rendering pipeline which now requires an output buffer to be passed along so that new markup is captured for deferred rendering, rather than rendered immediately. Since then apply and applyTemplate have both been aliased so that they will still work as expected in 4.1 (and so this problem has been resolved), but at the time they simply broke and I needed to work around them.

The problem wasn’t fixing the code — that part was easy. My big issue as a component developer was fixing the code so that it still worked under all versions of Ext going back to 4.0.1 (4.0.0 is hopelessly broken for Extensible and is not supported). If I simply switched the method to return the output buffer (which would have fixed it for 4.1) I would have broken it for all versions of Ext prior to 4.1. So how to solve it generically across Ext versions?

Ext 4.0 introduced a very handy new class Ext.Version, which tells you everything you never realized you’d need to know about the currently-loaded version of Ext. Try typing  Ext.getVersion() into the console with Ext loaded:

The class also contains some useful comparison methods, which allowed me to effectively solve me problem by changing the last line of my XTemplate subclasses to look like this:

if (Ext.getVersion().isLessThan('4.1')) {
    return this.callParent([data]);
}
else {
    return this.applyOut(data, []).join('');
}

Like I mentioned, this specific XTemplate issue has been resolved, but the key point is the strategy that you can use in any scenario where you have to branch your logic or syntax based on the version of Ext currently loaded.

Version-specific Overrides

Another example is with overrides that I ship with Extensible, which is an even more common scenario for component developers. Ext 4.1 is introducing a brand new syntax for defining overrides (teased near the end of this blog post), but unfortunately since my code still has to work back to 4.0.1, I can’t take advantage of that yet. However I commonly have to provide version-specific overrides, including removing overrides for things that have been fixed in 4.1, while continuing to override them for 4.0.x!

Applying overrides conditionally by version is simple using Ext.getVersion. Here’s a quick example from Extensible (the issue being patched was fixed in 4.1):

if (extVersion.isLessThan('4.1')) {
    if (Ext.data && Ext.data.reader && Ext.data.reader.Reader) {
        Ext.data.reader.Reader.override({
            extractData : function(root) {
                // etc.
            }
        });
    }
}

In general it’s a wise approach to keep your overrides as limited as possible, including to the specific version(s) of Ext required to be overridden. This will limit your exposure to unexpected regressions due to changes in the code in future versions of Ext as well.

Extending Ext.dd.StatusProxy

Hopefully you haven’t had to do this yourself (I can’t imagine that it’s too common), but if you have then you may be in for a big surprise with 4.1. I have a StatusProxy subclass that uses custom markup internally to display extra information during drag operations. As of 4.0.7, this was quite a pain as all of the markup definition was private to the StatusProxy constructor (an unfortunate piece of legacy design that did not get updated during the migration from 3.x). Even worse, the class was not an Ext.Component — it simply extended the native Object — so there was no managed rendering process to hook your way into either. The only way to customize the markup under 4.0.x was to override the entire constructor and re-implement it.

In 4.1 the StatusProxy class has finally received its due attention and gotten a nice makeover. It extends Ext.Component, and now uses the standard renderTpl config to define its markup, making customization a breeze. So what’s the problem? Since I was overriding the constructor (and never calling a superclass constructor since it was not a Component previously) I was now inadvertently breaking the Component lifecycle (which caused runtime errors).

To fix this I essentially had to branch the entire constructor, keeping my existing legacy code for 4.0.x, but then also using renderTpl and deferring to the parent constructor under 4.1.  That new structure now looks like this (I’m leaving the entire legacy constructor in place just to demonstrate how nasty it was before to override):

// Override the template here for 4.1+
renderTpl: [
    '<div class="' + Ext.baseCSSPrefix + 'dd-drop-icon"></div>',
    '<div class="ext-dd-ghost-ct">',
        '<div id="{id}-ghost" class="' + Ext.baseCSSPrefix + 'dd-drag-ghost"></div>',
        '<div id="{id}-message" class="ext-dd-msg"></div>',
    '</div>'
],

// This is new in 4.1:
childEls: [
    'ghost',
    'message'
],

constructor: function(config) {
    if (Ext.getVersion().isLessThan('4.1')) {
        this.preComponentConstructor(config);
    }
    else {
        this.callParent(arguments);
    }
},

// Old non-Component constructor ported from 4.0.x
preComponentConstructor: function(config) {
    var me = this;

    Ext.apply(me, config);

    me.id = me.id || Ext.id();
    me.proxy = Ext.createWidget('component', {
        floating: true,
        id: me.id || Ext.id(),

        // This is the key hack here -- the 4.0.x version of StatusProxy does
        // not understand renderTpl (since it's not a true Component) and
        // will ignore it, but since we're defining it already for 4.1+ we can
        // simply reuse that definition rather than rewriting the markup here:
        html: me.renderTpl.join(''),

        cls: Ext.baseCSSPrefix + 'dd-drag-proxy ' + me.dropNotAllowed,
        shadow: !config || config.shadow !== false,
        renderTo: document.body
    });

    me.el = me.proxy.el;
    me.el.show();
    me.el.setVisibilityMode(Ext.core.Element.VISIBILITY);
    me.el.hide();

    me.ghost = Ext.get(me.el.dom.childNodes[1].childNodes[0]);
    me.message = Ext.get(me.el.dom.childNodes[1].childNodes[1]);
    me.dropStatus = me.dropNotAllowed;
}

I guess I should also point out that this branching technically could be done inside of Ext.dd.StatusProxy itself (hint hint, Sencha guys). Even though it’s probably an uncommon scenario, and even though it’s not technically an API change to refactor the guts of the constructor, the poor design of the 4.0.x version essentially means that anyone who might have needed custom StatusProxy markup will be broken under 4.1 by default.

I guess there’s an interesting discussion to be had about Ext / JavaScript compatibility in general and where to draw those lines. Examples like this also highlight the need for better “compile-time” tooling in the JavaScript world so that the end developer could strip such compatibility code for deployment if it wasn’t needed (Sencha’s SDK tools are headed in that direction). Backwards compatibility has always been one of my personal hot buttons, but I’ll save that rant for a future post

Wrapping Up

Hopefully this provided a little insight into the extra care it takes to support components used by others across different versions of Ext, especially with the changes in 4.1. I hope you found this series helpful — I know that I spent a lot of time figuring these things out during my upgrade from 4.0 to 4.1, so if I save anyone even a little time dealing with similar issues I’ll be very happy!

By the way, even though I’ve been focused in these posts on the difficulties I had in upgrading, I want to close by pointing out that 4.1 is an incredible release, especially for the performance improvements in legacy browsers. I’d like to publicly congratulate Don, Nige and everyone else on the team for all their hard work over the past year or so. Those guys are really tireless when it comes to putting out the best Ext releases possible!

See also: Part 1 | Part 2

Beware the Auto Layout

In my EventWindow class (the window used to edit calendar events), the layout simply stopped working as expected under 4.1. The form still rendered, but obviously Ext was not providing the correct layout logic as it had been previously.  It was looking something like this (note the fields overflowing the window body boundaries):

 After some fruitless debugging of resize events and layout logic, I finally realized that the window had no explicit layout set, and had been simply relying on the browser’s default DOM layout logic to size the form’s container (the window is fixed size, so this always worked as expected before). Even though it had been working previously, that was due more to luck than anything. Relying on auto layout is generally a no-no when dealing with Ext containers, and even though I know better, somehow this got missed.  This minor bug had been flying under the radar for quite some time and Ext 4.1′s revamped layout engine finally exposed it.

Ext.define('Extensible.calendar.form.EventWindow', {
    layout: 'fit',
    // etc.
});

Luckily the fix is very simple, just beware that if you’re still relying on auto layout in any containers, 4.1 may bite you!

Model.store -> Model.stores[]

In Ext 4.1 the previous Model.store : Object property is now Model.stores : Array. This is a simple change, and it’s documented in the existing API change notes, but I wanted to call it out because it’s an explicit breaking change that in fact impacted the calendar code.  I’m quite surprised to find this change in Ext 4.1 without a backwards compatibility patch frankly, especially as it seems that it would have been pretty easy to leave the existing property defaulted to the value of this.stores[0], which would always be valid for existing 4.0.x code.  It’s still beta as of this writing, so maybe someone on the core team will reexamine this before the final release…

Here’s an example of the calendar code that had to change. It takes a record generically and determines whether or not it needs to be added to the calendar’s event store.  I probably could have also checked the record’s phantom property instead, but the code worked just fine before:

onEventAdd: function(form, rec) {
    if (!rec.store) {
        this.store.add(rec);
        this.save();
    }
    this.fireEvent('eventadd', this, rec);
}

In fact this is the worst kind of error, because this code doesn’t actually cause a runtime error under 4.1 — it simply evaluates to true on every check, and thus leads to a silent regression (in this case, duplicate record adds). Ugh!

The fix is to either check rec.phantom, or perhaps rec.stores.length === 0.  In my case I still have to support the end user using 4.0.x as well so checking rec.phantom is the simplest fix. Since there is not one single way that this property could be used, it’s up to you to evaluate it if needed and fix it as appropriate to your own code!

Avoid Manual Creation of Component Elements

The exact issue I had was a bit of a random one, and not likely to affect most people specifically. However, the principle behind why this code broke under 4.1 is still very important to understand, as you might have a similar issue with the same root cause.

It is not uncommon in older versions of Ext, especially in custom components, to manually create the component’s underlying element during render if you need to customize the markup.  This particular bit of code, as happens a lot, simply got ported forward from some older code that’s always worked fine through version 4.0.7. Suddenly under 4.1, this component simply stopped rendering altogether, and it boiled down to this code in the constructor:

if (!this.el) {
    this.el = document.createElement('div');
}

If you’ve been keeping up with the rendering pipeline changes in 4.1, you’ll be aware that component markup is now batched in memory during render, and that DOM writes are managed and performed in bulk by the rendering engine. In the past, each component was free to independently create and insert its own markup into the DOM. However, under 4.1, you should no longer do this as it will not play nicely with the new rendering lifecycle.

The solution in my case was to simply delete that block of code and allow Ext to do the Element creation for me as part of its normal rendering process.  This logic was simply a leftover piece of code that was not needed, but did no harm (until 4.1).  If you really do need to customize markup, the appropriate place to look now would be the new beforeRender() method, or perhaps even better, customizing your component’s renderTpl (the preferred way to define custom markup under 4.x).

Fields Are Now Tables

I’m not exactly sure why this change was made now, though I assume it was mostly about squeezing every little extra bit of layout performance out of the browser. Tables allow you to line things up “for free” compared to adding overhead to calculate and resize divs to align labels, for example.  Fair enough.  However, there are a couple of things to watch out for here.  First, let’s see how the markup changed (note that the markup is abbreviated to focus mainly on the structure):

<div class="x-field" id="textfield-1018">
    <label class="x-form-item-label">My Field:</label>
    <div class="x-form-item-body"><input class="x-form-field" type="text" name="myfield" size="20" /></div>
</div>

<table class="x-field" id="textfield-1018" cellspacing="0" cellpadding="0">
    <tbody>
        <tr id="textfield-1018-inputRow">
            <td id="textfield-1018-labelCell" valign="top"><label class="x-form-item-label">My Field:</label></td>
            <td class="x-form-item-body" colspan="2"><input class="x-form-field" type="text" name="myfield" size="20" /></td>
        </tr>
    </tbody>
</table>

The first thing to note is that if you have written any custom CSS rules that rely on the previous structure (e.g. div.x-form-item-body) you may have to adjust them accordingly.

A much less common issue, but the one that affected me, relates to positioning custom elements inside a form field. This is commonly done with combo boxes, for example to add a custom icon for each item. This is exactly the case for my calendar picker custom combo, which displays a simple color icon to visually differentiate each calendar in the list. To achieve this, the containing element (previously the x-form-item-body DIV, now a TD, as highlighted above) must be position: relative (which it is) so that inner elements can be absolutely positioned.

In testing, only on Firefox, I was getting the result on the left after upgrading to Ext 4.1:

After some experimenting and Googling, I found that there’s an annoying bug wherein Firefox ignores positioning on table elements. Awesome! The only fix I could get to work was to make the offending element display: block, which feels like solving it with a sledgehammer, but I couldn’t get anything else to work reliably. At least I restricted my fix to Firefox and only to my widget by defining my override like so, to hopefully avoid creating unexpected issues downstream:

.x-gecko .ext-calendar-picker {
    display: block;
}

If you’re doing any kind of positioning inside of fields, this is definitely something to watch out for!

Double-Check Your Overrides

It’s very common to override existing Ext classes to patch issues or add functionality.  Because of that, this is really a general rule of thumb anytime you’re considering upgrading your Ext version — even typical minor versions can fix or alter something that might break or even remove the need for one of your overrides.

In the case of Extensible, this happened with an override to Ext.data.Reader required by the calendar components. Inside the extractData() method I have had to make the following fix for a while now, per the included comments:

// Assuming that the idProperty is intended to use the id mapping, if
// available, getId() should read from the mapped values not the raw values.
// Using the non-mapped id causes updates later to silently fail since
// the updated data is replaced by id.
//id = me.getId(node);
id = me.getId(values);

This is a pretty important fix — as the comments state, without it updates to data simply fail silently. Under 4.1, some internals of the Reader class were refactored, and some code was added to this function, without which the class no longer worked as expected. This was not an API change at all, yet because I’ve overridden private code, I now have to be extra careful to watch out for such internal changes!

To mitigate this you can often use tricks like createSequence or createInterceptor to work around offending methods AOP-stlye. Unfortunately though, sometimes the only solution is to override the entire method, in which case the only fix is to update the override accordingly (as in this case).

Is There More?

These have been a few of the various types of fixes I had to make in Extensible for Ext 4.1, but it’s not all of them. In the next part of this series, we’ll look at a couple of really tricky issues that required even more creative fixes! We’ll also discuss strategies for branching your fixes in order to support multiple versions of Ext simultaneously, a key requirement for anyone building custom components used by others.

See also: Part 1 | Part 3

There is a lot of important information about the impending 4.1 release, and it’s spread across blog posts, forum posts, release notes, videos, etc. This not only includes information summarizing the major changes and new features in 4.1, but also detailing the breaking API changes.  Unfortunately, though minor releases should always retain backwards compatibility, the dramatic nature of the changes in 4.1 means that existing code will likely be impacted at some level.

I thought it might be useful to provide a roundup of the existing resources I know of for 4.1, but also to highlight some of the issues I ran into specifically while upgrading Calendar Pro to support 4.1.  Some of the issues I hit were probably atypical — as a custom component developer I tend to do a lot more private overriding than the average developer — but as such, it also makes for interesting discussion about dealing with more advanced edge cases and supporting multiple Ext versions.

Let’s start off by simply gathering together all of the best resources about 4.1 into one place. Hopefully this will be a valuable reference for anyone planning to upgrade from 4.0.

Blog Posts

• Ext JS 4.1 Update: A few high-level summary statements about the performance issues, but mostly a mea culpa and marketing announcement. It’s there, but you can skip it
• Ext JS 4.1 Performance Preview: The release announcement for the initial developer preview download, but also the first technical overview of the performance issues and 4.1′s strategy for dealing with them. Also includes the first preview of the new Neptune theme. Worth a quick look, but more detailed and useful performance posts soon followed…
• What’s Coming in Ext JS 4.1: The first real meaty, in-depth overview of performance and new features for 4.1. In this post, chief performance guru Don Griffin outlines the new rendering pipeline and layout strategy, and if you do any nontrivial component development, you’ll want to really understand these sections.  He also introduces some of the major new features including new grid scrolling enhancements, new XTemplate features, BorderLayout improvements and the new syntax for overriding components. If you only read one post, read this one!
• Optimizing Ext JS 4.1-based Applications: Don is back with this more advanced post on strategies that you, the developer, can take to mitigate performance issues in your own code. He also unveils the new Ext JS Page Analyzer and Grid Tuner utilities for taking performance into your own hands and really getting into the nitty gritty of analyzing your own app’s real performance across different browsers. Awesome stuff.
  

Videos

• Ext JS 4.1 Performance Tips and Tricks: This is the recording of a screencast that Don and Animal did about application optimization and reviewing the new tuning tools outlined in the last blog post above. It’s a companion piece to that post, so you might choose one or the other depending on your preferred method for consuming info.
• SenchaCon 2011: Ext JS 4.1: Layouts, Performance, and API updates: If you didn’t attend SenchaCon 2011, you may have missed this video. In it Don explains in great detail all of the major changes in 4.1. It covers similar ground to the blog posts, but I would highly recommend it still as Don does an excellent job explaining everything, and the interactive aspects of the slides really help to drive home the details about how the new rendering system works. The companion slide show is also online.

Other

• Ext 4.1 Forum: You may not have noticed that there’s an entire forum section dedicated solely to Ext 4.1 testing, bugs and feedback. It might be worth your time to scan through some of the threads there and see if anything jumps out at you.
• 4.1 API Changes: This is a sticky thread in the 4.1 forum, but it might be easy to gloss over. In fact, it’s probably the single most important practical resource for every developer upgrading to 4.1, as it contains most of the landmines you’ll need to watch out for when upgrading.

If you know of any other official sources of information about 4.1 that aren’t listed here, please add them in the comments. Hopefully this is a pretty good start!

In part 2 I’ll discuss the issues I dealt with in upgrading the calendar to 4.1 and my strategies for effectively supporting multiple versions of the Ext API simultaneously in the same release (fun!).

See also: Part 2 | Part 3

What We’re Looking For

• Experienced web developers with solid OO chops.
  We don’t have specific requirements for language experience, years of work or education – if you’re smart and have mastered at least one programming language, you should be able to pick up whatever is needed. Some things that we’ll probably work with from time to time as we go forward: JavaScript, HTML, CSS, C#, Java, PHP, Rails, Node, Git
• Some form of JavaScript framework experience.
  And by framework, we do not mean just jQuery. Have you implemented MVC or used some form of inheritance in a JS app (Ext JS, Dojo, etc.)? Let’s talk. Strong OO experience in a non-JavaScript framework could work too as long as you’re eager to learn.
• Mobile development (native and/or web).
  It’s a mobile world, and if you’re not on that bandwagon yet then you’re behind the curve. It’s not a deal-breaker, but if you haven’t done mobile yet be prepared to dive in.
• Self-starters who love agile development.
  If you need structure and hand-holding, this is likely not the position for you. This will be a highly dynamic startup environment, and you may be asked to wear many hats over the course of a typical week. The ideal candidate will thrive on that challenge.

And We’d Be Ecstatic If…

• …you’re already experienced with Ext JS.
  The Extensible framework is based on Ext JS and we use it a lot in other projects too. Prior experience with Ext JS is a huge bonus, though anyone with OO framework experience should be able to pick it up quickly.
• …you actively contribute to open source.
  At Extensible we love open source (our main product is dual-source) and have plans to contribute to the open source community even more in the future. Have you worked on anything open source? Include a link to your Github account and show us what you’ve done.
• …you live in Austin.
  Remote might work too, but ideally you’d be at the table with us most days white boarding and banging out code.

A Little More About Us

Extensible was founded by Brian Moeskau, original cofounder of Ext JS (now Sencha, a 100+ person, VC-funded company). Our first product has been shipping successfully for over a year now and we’re aggressively looking to expand our business into new areas. We’re located in Austin, Texas and looking to have an impact on the local technology scene. Through Extensible’s products and open source initiatives you could have the opportunity to write code used by hundreds of companies around the world.

If this post sounds interesting to you or you know someone who might be a fit, please let us know! We don’t have a formal application process — just send over your resume or LinkedIn page and let us know a little bit about yourself and we’ll go from there.

• Extensible 1.0.2 (for Ext 3.x): A bug-fix release for the most part with a few important fixes for IE and OSX, recommended for all 1.0.x users. For additional details see the 1.0.2 release notes.
• Extensible 1.5.1 (for Ext 4.x): A bug-fix release that also adds support for the upcoming Ext 4.1 release, which is a significant upgrade in the Ext 4.x line. Recommended for all 1.5.0 users, required if you plan on upgrading to Ext 4.1. For complete details see the 1.5.1 release notes.

Download 1.0.2 and/or 1.5.1

New Configuration Settings

One notable “feature” that was added recently in both 1.0.2 and 1.5.1 is a new file in the root of the project called Extensible-config.js. One common annoyance in the past has been how best to distribute the Extensible examples for ease of setup and use by end developers. Especially under Ext 4.0+, which introduced dynamic loading via Ext.Loader, this became quite a challenge since dynamic loading is ideal for Extensible development, but terrible performance-wise for public release. How best to maintain the needed JS and CSS includes for both Ext and Extensible, across all examples and for both development and release?

The answer now is Extensible-config.js, which writes the JS and CSS includes into the examples dynamically at runtime based on the configuration options specified in that file. Now with a simple config setting you can switch the deployment mode between “release” and “debug” (or “dynamic” under 1.5.1 to use Ext.Loader), or change the root paths for Ext and/or Extensible to easily facilitate testing against different versions. The examples should now work well out of the box (no more local editing of paths or .htaccess files required!) but take a look at the source comments in Extensible-config.js if you’d like to find out more.

Initially I just thought it was funny because it looked like a “Harry Potter at age 35″ set where he’s long graduated from Hogwarts and is now a disaffected office drone, plugging away at his TPS reports.  But on closer inspection, I noticed something quite interesting on Harry’s computer screen:

Looks uncannily similar to some other software I’ve seen before…

It makes me happy to see Extensible products being put to good use in the real world!

Have an example of Calendar Pro being used in your own software?  Please share!

Extensible 1.0.2 & 1.5.1

For the past few weeks I’ve been fixing bugs, including a few pretty important ones, and preparing for the next maintenance releases of both the Ext 3.x and Ext 4.x branches of the calendar. Most importantly, as of today Calendar Pro is fully Ext 4.1-compatible, at least as of the most current beta version (things could still change, but I’m hopeful that any remaining issues that might come up will be minor). Although Ext 4.1 is a minor point release, it’s actually a huge revamp of the rendering and layout systems under the hood, so some hiccups were to be expected. These have been addressed and the calendar is back in full working form.

I have a few additional issues to iron out and some build process improvements to make, but I expect to be able to put out the new releases within the next week or so.

Extensible 1.1 & 1.6 (a.k.a., Recurrence)

I’ve also been working on recurrence support, off and on, for a while now. Most recently I’ve been porting (well, rewriting) the existing recurrence editor widget to work under Ext 4, the only component from Extensible 1.0.x that had not yet been touched in the upgrade to Ext 4. That effort has been progressing nicely and I should have the new and improved widget done within the next few days.

I still have work to do on the event editing side to support recurrence fully, and I’ve been working on a separate blog post series that will soon lay out Extensible’s recurrence support in full detail. No ETA yet, but finishing recurrence and making it available is the highest priority feature right now.

Next…?

I have lots of feature ideas on the whiteboard right now, but nothing much set in stone yet for releases beyond 1.6. The current most popular request after recurrence is Outlook-style split day view support, which is planned.  A mobile / Sencha Touch version of the calendar has been a common request lately, what do you think? What other ideas do you have for next features?

Just a quick note that Extensible will be taking a few days off starting tomorrow, Thursday, December 22 through Monday, December 26 to spend some quality time with family and enjoy the holidays.  The forums of course are always open, but please be aware that there will likely be a delay in answering questions or responding to support inquiries over the next few days.

I hope everyone has a safe and relaxing holiday weekend, and I’ll see you next week!

Download Extensible 1.5

A few notable issues that were fixed in this release:

• A daylight savings bug in Extensible.Date.add() caused bad things to happen around the end of October.
• The new scrollbars in OSX Lion created a layout bug in day and week views since they rely on the scroll width as a layout offset for the header area. It’s now calculated correctly rather than a hard-coded pixel offset.
• The new Ext 4 CSS classname prefixes are now used in the Extensible CSS rules that rely on them (“.x-” instead of “.ext-”). The beta still used the old-style prefixes in some cases, which led to subtle CSS bugs (including faulty event colors and borders in IE).
• The DateRangeField now support the multi-line layout again.

There are many other fixes as well – for the complete list check out the release notes. If you are still using the beta, please upgrade as soon as possible!

Here are the upcoming next steps we have planned:

• Extensible 1.0.2
  This will be a maintenance release for the Ext 3 branch to push out the bug fixes that have been made since 1.0.1 (including the Lion scrollbar fix).
• Extensible 1.1 / 1.6
  This will be a new feature release for both branches focused primarily on the top two features currently in the request queue: recurrence support and split day view support (the ability to subdivide the day view into multiple columns based on some attribute like a user’s calendar).

Now that we’re caught back up with the latest Sencha release we can again start adding new features and continuing to make Calendar Pro the best JavaScript calendar available. We have no shortage of ideas for 1.7 and beyond, but we also love to hear from our community regarding what’s most important, so please tell us.

Have you been using Ext Calendar Pro successfully in your company?  Please let us know. We’d love to receive testimonials and screenshots from happy customers that we can post on our website.  You can also buy a license or support to show your support and help keep Extensible adding new features and products.

Extensible 1.5 beta

The Ext 4 compatible version of Extensible is 1.5.x, and this is now the master branch in Github.  I briefly considered releasing this version as 2.0, but decided not to primarily for two reasons:

• No new features were added, aside from Ext 4 support
• This release is a free upgrade for all existing Extensible 1.x licensees

Extensible 2.0 will be a major new feature release, and may also be a paid upgrade when it comes out (it’s not even started at this time). Because of that I felt it appropriate to keep the entire current Extensible line, both for Ext 3 and Ext 4, at the same major version number.

The first beta build of 1.5.0 is now available, or you can fork the master branch and build it yourself from source. There are a couple of known issues, so you might want to check the release notes as well. Please provide feedback and bug reports in the forums.

Extensible 1.0.1

For existing Ext 3.x users who plan to stick with 3.x for a while, the Extensible 1.x branch will also be actively maintained, and regular maintenance releases will still be made. The official 1.0.1 bug fix release is available now (see the release notes for what’s changed). It is a fully-compatible upgrade from 1.0.0 and is recommended for all Ext 3.x users.

Future Plans

Some new features will still be made in both branches (including recurrence support, which was already planned for 1.1 before Ext 4 even came out). Moving forward, most new features will start going only into the Extensible 1.5.x branch and/or 2.0 once it gets started. Extensible 1.x will be fully supported for at least as long as Ext 3.x is supported by Sencha (which will be a while yet), but just as with Ext JS itself, major new features will typically appear only in the newest versions.

Now that Ext 4 is out and the conference is over, I’m refocusing on Extensible and plan to get 1.1 out as soon as possible.  I’ve already started adding recurrence support and hope to have something committed for testing very soon.

I have also started updating the calendar for Ext 4 support, which will reside in a separate branch so that Ext 3 will still be fully supported as well.  This will not be part of the 1.1 release plan, but should also be released pretty soon thereafter.

Finally, I will have more exciting Extensible product news in the coming weeks, but I don’t want to spoil the surprise just yet…

Thank you to all who took advantage of the 1.0 pre-release sale and ordered licenses. Even though the sale is now over, it’s never too late to order a license and help support the project as we start working on new features.

Road Map

The next feature release will be 1.1, currently slated for early-to-mid-April. The primary focus will be on implementing recurrence and adding support for dividing the Day View into multiple sub-views, a la MS Outlook.  I’ll most likely sneak in a couple of additional minor features as well, like event tooltip support.

I’ll be looking at Ext 4 support very soon, and I plan to maintain separate branches for 3.x and 4.x support (for at least as long as Ext 3.x is officially supported by Sencha).  Ext 4.0 support will be provided as a free upgrade for any current Extensible 1.0 commercial license holders, regardless of how the Extensible version numbers end up working out (not sure about that yet).

I have a lot of other features already on the drawing board and will publish a longer-term road map soon.  I’m also using UserVoice to monitor community feedback on new feature requests and prioritizing based partially on that (as you can see by the 1.1 plans).  Do you have other features that you’d like to see in a future release?  Let me know!

The plan is for one last week of testing, and then 1.0 final should be ready next weekend.  That also means that this will be the final week of our super-duper pre-release sale on licenses, so if you’ve been on the fence, now would be a great time to head on over to the store page and get your discount while it lasts!

The next major release on the road map will be 1.1, and the focus will be on getting recurrence support fully implemented throughout the framework.  The other major feature that folks have been requesting lately is the ability to divide the Day view so that you can show multiple calendars for the same day a la MS Outlook, so I’ll definitely be looking at that as well.  If you have other ideas for features you want, be sure to suggest them.

Speaking of new features, you might have noticed the little “feedback” link hanging around the left edge of the screen if you’ve visited the site recently. I’m evaluating the UserVoice service to accept feature requests in a structured way that will hopefully provide some kind of realistic weighting behind each request. The service gives you a handful of votes that you can allocate toward the ideas you consider to be most important, and if enough people request features and vote it should give a real sense of the community’s priorities.  Please give it a try and make your voice heard!

Just a reminder that the Extensible pre-release sale is still in full force, but only for a limited time.  Once 1.0 final is ready the sale will be over, so if you are still considering purchasing a 1.0 commercial license, now would be the perfect opportunity to save up to 27% off the regular price.  If you are interested, head on over to the store.

In advance of the 1.0 Final release we’re having a pre-release sale on all commercial licenses. You can save up to 27% off the normal license price, depending on how many you need. This discounted price is only good until 1.0 Final is released (~early February).

You may also notice that the overall site has had a bit of a face-lift – I hope you like the improvements. You may need to refresh your browser if any pages are cached. Please let us know if you notice any snags with the site, or if you have any other issues or feedback.

Mostly bug fixes in this release, no major features added.  At this point 1.0 is basically feature-complete, and the plan is to put out one or two release candidates after today to fix any final bugs that come up in the next few weeks.

• Interactive calendar demos
• Online API docs

Both the demos and docs are still works in progress, but I wanted to get them out there now so that even more people can have a look and provide feedback.  As always if you find any issues or have suggestions please let us know.

One other tiny update is that the site now officially has a store page.  It’s pretty bare at the moment, but it will be launching in early January 2011 with pre-release discounts on all commercial license options.  Support subscriptions will also be available, so check back soon.

• A large amount of effort in this release was spent improving the handling of remote data loading, including handling remote errors properly. See the updated remote calendar sample which now allows you to toggle remote errors on and off for testing.
• Localization has been fully implemented and several locale files included.
• A few new config options have been added, including read-only calendar support and a flexible multi-day view option.
• Lots of bug fixes

Note that originally recurrence support was planned for 1.0. This has been deferred for now, but will be the main focus of the 1.1 release.

Please give the beta release a try and if you find any bugs or have feedback please visit the Extensible forums.

1.0 Release Plans

Currently I am planning one more beta release that will contain the final changes / feature additions for 1.0.  That release should occur within about 2 weeks.  After that will be one or two release candidates as needed, which will only contain bug fixes required to finalize the release, then the final 1.0 will follow.  I am currently targeting February 1st as the 1.0 release date.

I also plan to finalize and announce all the details around support and pricing after the first of the year, and will be having a pre-release sale on all commercial licensing plans in January leading up to the 1.0 final release.

Thanks to everyone who so far has contributed bug reports, feature requests, fixes and locale files.  I really appreciate everyone’s interest and contributions, and there will be lots of great stuff coming down the road.  1.0 is just the beginning!

Multi-Calendar Support

This ended up being a bit more complex than I thought it would be to implement, but I’m pretty pleased with the results so far.

The current release supports choosing calendar colors, hiding and showing each calendar and also introduces a separate CalendarRecord class with CalendarMappings (just like the corresponding event classes).  You cannot yet add or edit calendars, although that will be added in an upcoming release.  However, the new functionality already adds quite a bit to the calendar experience.

Remote Example

Every real calendar implementation is going to use remote data, so it’s important to demonstrate that Ext Calendar Pro supports loading remote data quite easily.  This release adds a new sample that shows just that.  In fact, no changes are required in the calendar code itself — you simply specify the appropriate remote proxy for your data store (and in this case, the REST API also since the new sample is RESTful).  The sample uses a basic MVC-style PHP implementation as the back end, which stores data in the session between page loads.  Additional platform implementations will be added in future releases, but this should get you started down the path of remote data usage.

Everything Else

Of course there are also a bunch of minor updates and bug fixes in this release as well.  Please check out the release notes for details.

The biggest goal for the next release will be implementing the recurrence widget into the calendar, and trying to reach 1.0 API stability if possible so that we can start beta testing.  If you have any feedback or find any bugs, please head over to the forums and let me know!

The big event on the calendar is SenchCon 2010 (Nov.14-17) in San Francisco.  On the second day of the conference I’ll be moderating a panel discussion of some of the best and brightest component developers in the Ext JS community.  From the Sencha conference site:

Session: Ext JS Component Makers
Day 2, Tuesday, November 16th – 12:45pm to 1:30pm
This is the opportunity to see what the best of the Ext JS community has developed in the format that the DEMO conference has pioneered. Each component developer will have 5 minutes to demo their component and talk about the challenges faced and solutions invented during the development process.

If you’ll be attending the conference please check out the panel and also stop by and introduce yourself — I can’t wait to meet other developers in person who I’ve only known through forum discussions!

Austin Meetup

The other upcoming event is for anyone in or near Austin, TX.  Next Wednesday, Sept. 29th at 7:30 pm I’ll be hosting the Austin Ext JS / Sencha Meetup.  We’ll be getting together at Tech Ranch Austin to discuss interesting Ext projects (I’ll be demo’ing Ext Calendar Pro), although the primary focus will be on getting to know each other better and having a couple of cold ones.  If you are in the area, please stop by.

If you haven’t yet, please download the code from Github and give it a spin!

There are a few new features in this release compared to the sample in Ext JS 3.3.  For example, there are additional views (multi-day, multi-week) — the samples now include a 2-week view by default.  The events also support right-click context menus as well.  There have been numerous additions and improvements to the component API’s, including a handful of new events for the calendar views.  Most importantly, a number of bugs have been fixed and a lot of internal improvements have been made as well to help transition the components from sample quality to production quality.  While a lot of these changes are not visible on the outside, they are very important for getting Extensible 1.0 off on the right foot.

So What’s the Plan?

The current plan is to have at least 3 more interim releases prior to the final 1.0 release.  Subject to change, this is the current high-level plan:

• Alpha 2: More new features and fixes, API’s may still change.  Heavy development still.
• Beta 1: More new features, although I’m planning this to be the feature freeze release.  API’s may change in this release, but hopefully not after.
• Beta 2: Or possibly RC, depending on how it’s looking.  API should be stable at this point and it should be primarily bug fixes.  May need an RC release after this.

I’m really hoping to get each release out within 1-2 weeks of the previous one, although with a few of the features still to be added it’s hard to say for sure.  If all goes well, this puts us in decent shape for a late October release, depending on what kind of issues might come up between now and then.

So you may be wondering what features are still to be added for 1.0.  Here’s the current list (give or take):

• Full multi-calendar support with calendar management
• Recurrence support in the calendar (there is a recurrence control sample in this alpha release, but it’s not integrated into the calendar yet)
• Enhanced event store functionality for working with remote data
• Customizable gadget sidebar as a component
• Read-only events and calendar views
• At least one server-side sample implementation

And a few other odds and ends, but those are most of the major items.  And before you ask, yes, there are a ton of additional features already on the list for post-1.0.  You have to draw the line somewhere to get a release out the door, so hopefully this will cover enough to get people up and running for now.  In a future update I’ll discuss more about feature plans beyond 1.0.

How Can I Help?

I’m glad you asked!  Please report any bugs or feature requests in the Github issues list for the project.  If you’re not on Github already (why not?) and don’t want to sign up just to post an issue, you can also send me an email.  If you are interested in contributing in any way, feel free to fork the code and send me any changes you come up with.

Time to start working on alpha 2!

http://github.com/bmoeskau/Extensible

I was hoping to have a beta release out by now, but that hasn’t quite happened yet.  The code should still be considered alpha quality, primarily because it’s been under heavy revision since the cut that went into Ext 3.3, and also because it is still not feature complete for what’s going to be in Extensible 1.0.  However, I figured that there’s no reason not to let people check it out and start providing feedback.

It’s looking like it’s going to be at least a few weeks yet before the first proper packaged release is available.  Once that’s done I’ll post again and discuss the status of specific features.  A lot of the work that’s been going into the code lately has been focused less on new features and more on fixing bugs and improving the functionality and extensibility of the components that are there.  It’s coming along nicely!

If you are interested in contributing to the project in any capacity please let me know.  I’m going to try out Github’s built-in issue tracking, so if you find bugs, please post them.  If you’re interested in adding docs or patching the code, feel free to fork the project and send me a note when you have something I should take a look at!

Enter MailChimp.  I’d heard lots about it over the past year or so and even checked it out a while back, but this time I decided to sign up and give it a go.  The great thing is that they offer a full-featured entry level account that is free to start until you get to a minimum subscriber base where it would then make sense to upgrade.  The toolset is comprehensive, which is good and bad.  Trying to accomplish certain tasks seemed a bit more difficult than it should have been, but in a single day I went from zero to a fully-functioning email list with all the custom-styled forms and email templates I needed up and running.  And all for free!  Gotta love the web — in the age of desktop software none of this would have been possible.

Hey, speaking of newsletters, why not subscribe now so you don’t miss out on any product announcements or other Extensible news?

Yes, I’ve been pretty well absent from the Ext JS community lately.  For a while, actually, thanks for asking.  If you noticed my absence, then you probably already know who I am and maybe even a bit about my background.  If you did not notice (shame on you!) let me give a few details, if you’re interested.

A Little Background

Waaay back in the fall of 2006 I met up with Jack Slocum over the internets.  At the time he was working on his YUI-Ext components (extensions to Yahoo’s at-the-time nascent JS framework) and I was doing some contract web app development and was looking around for a framework to use (again).  I ran across YUI-Ext and thought it was just awesome stuff, especially coming from some random, lone dude out in cyberspace.  I pulled down the code, sent a few patches back to Jack which he liked and we started talking.

Before you know it, by March of 2007, Ext JS (both the 1.0 framework and the company behind it) was officially born.  In those days it was literally just Jack and me — it was a crazy amount of work, but fun and a very interesting time.  As you probably know (since you’re reading this) Ext JS took off and continues to do quite well as one of the premiere web app development frameworks available.  All of that sounds great, right?  Then you’re probably asking…

“So Why Did You Leave?”

Well, in startup companies, as in life, things can get pretty interesting.  Things change (constantly), situations change, people change… none of which is good or bad necessarily, it just is what it is.  As the company grew, it simply got to a point where I didn’t fit quite as well into what was going on as I had in the beginning.  That, combined with the fact that my wife and I were going to have a baby in early 2009 (which did not gel very well with my 16-hour work days at the time) meant that something had to change.

I left Ext JS in October of 2008 on amicable terms.  At the time I was pretty burned out (and the baby was due shortly) so I literally switched off my brain for about 6 months and worked on the house, outfitted the nursery, read a bunch of baby books, watched movies… basically anything that did not involve writing code.

Fast Forward to July 2010

My daughter is now a happy (well, mostly) and healthy 17-month-old toddler.  Wow, let me let that sink in for a sec…

I finally switched my brain back on sometime during last year and have slowly been ramping a few projects up.  Even back when I left Ext JS officially, I always planned to return actively to the community at some point, when the time was right for me.

It just so happened that I had been working on some calendar components already when I heard that the Ext team was also thinking about doing something similar. I got back in touch with the current team (now rebranded as Sencha) and ended up working with them to contribute my components as a sample calendar application to the Ext JS 3.3 release (currently in beta as of this writing).

I’m still improving and adding features to those same components and will be releasing a more advanced version independently in the coming months (with Sencha’s full blessing).  Contributing something back to the framework has been a great way for me to jump back into the Ext JS game with both feet.  My plan for Extensible is to continue pushing out interesting and useful components for Ext, as well as other resources like tutorials and other tools, so keep an eye out here if that sounds interesting to you.

All of this is a really long-winded way for me to get to my real point, which is simply… It’s great to be back!  I can’t wait to start building some cool stuff (again).

–Brian

We look forward to providing many new and useful components to the Ext JS ecosystem, as well as other utilities, tutorials, custom themes and whatever else we think of that would be of interest to other Ext JS developers.  If you have any ideas for components that we should consider please let us know in the comments or send an email to feedback@ext.ensible.com.