End of the Line

This post has been a long time coming, and probably won’t come as a shock to anyone who has followed the Extensible release history. Effective immediately:

  • The current 1.6.1 version of Extensible (compatible with Ext 4.x) will be the last official release of Extensible.
  • No new commercial licenses or support subscriptions will be offered. Existing commercial licenses will continue to be valid in perpetuity. Any current commercial support subscriptions will continue to be honored until the support periods have expired.
  • The Extensible source code has always been available for free under the GPL license, and will continue to be available for free for the foreseeable future.
  • There is a pull request in progress to add Ext 5.x support, but it needs a bit more work still — if someone still needs Ext 5 support that would be the place to start. Ext 6 will not be supported.
  • If anyone is interested in becoming a committer or taking over ownership of the Extensible project on Github please let me know.
  • As of Ext 6.2 Sencha now offers a built-in calendar component. All existing users should migrate as soon as possible to Ext 6.2 and switch to the built-in calendar.

That’s basically all you need to know. If you’re interested in why the project has arrived at this point, read on…

The Why

The first commit to the Extensible Github repo was on August 12, 2010 — almost 6 years ago! Back then Ext 3 was still all the rage (the infamous version 4.0 was still 8 months away from nuking everyone’s projects). I was working full-time on my own web application, an online family calendar for which the Extensible calendar was going to be the centerpiece. When I launched Extensible as an open source library, both Ext and the calendar component were the primary focus of my daily development life.

However, things change. The story today is quite a bit different:

  • I’m no longer working on the calendar-based application I was building in 2010, and in fact I have no personal need for a custom calendar component anymore.
  • Beginning with Ext 4.0, each major release of Ext (and most minor releases!) came with massively disruptive, backwards-incompatible changes. These were bad enough for typical application developers, but for someone supporting a complex library of custom components, these releases were debilitating. And it has been increasingly disheartening to see just how many breaking changes in each release are completely unnecessary, made with no regard for the impact they have on end users. Sencha has learned nothing from the Ext 4 debacle.
  • In October 2014 Sencha made the mind-boggling decision to eliminate the single developer licensing option, making a 5-developer pack the entry point to get started with Ext ($4,475 minimum as of this writing). Surprising to no one in the world except maybe the Sencha C-suite, people were not happy about it. That was the death knell for Sencha’s ability to attract new developers outside of Fortune 500 cubical farms, and by extension, signaled the end of their (nominal) commitment to open source.
  • With the announcement of Ext 6.2 just a few weeks ago, Sencha unveiled their latest innovation — a calendar component that looks and functions exactly like the Extensible calendar! To be fair, there has been a calendar example for quite some time (that I originally contributed to Sencha) but it is now an officially-supported framework component. Sencha released this without even notifying me beforehand, much less reaching out to work with me in any way. Even if I was interested in continuing the development of the Extensible calendar, Sencha unilaterally and without warning destroyed its commercial viability. Interesting strategy for fostering your own ecosystem.

The bottom line is that I have not been actively using any Sencha technologies for years (in fact, since about 2013 I’ve only been using Ext insofar as it’s required to work on Extensible). The front end JavaScript world has shifted dramatically in the past 6 years with frameworks like Angular and Ember, and libraries like React and many others (all truly open source) innovating in important ways. By contrast, Ext has become a closed, dead-end, “enterprise” shell of what it once was. Sencha’s focus on revenue above all else has destroyed their developer community, and their eagerness to cannibalize their own ecosystem speaks volumes about their values as a company.

But with all that said, at the end of the day I simply haven’t been supporting Extensible for some time at the level my customers need and deserve, and so it’s time to bring it officially to an end. I sincerely hope that Sencha takes their version of the calendar seriously and uses their resources to continue supporting and improving it.

I want to close by thanking everyone who has ever bought a license, submitted a PR or supported the project through kind words or encouragement. Extensible began as a labor of love and I really have enjoyed working on it over the years and contributing to the open source community.

Posted in Extensible, News | Comments Off on End of the Line

Extensible 1.6 Release Candidate

The first (and hopefully only) RC for Extensible 1.6 is out! Download it now.

The main goal of this release was to finalize recurrence, but there were quite a number of bug fixes and other improvements throughout.  Make sure you check out the release notes for complete details.  Here are some of the major highlights…


Recurrence support has been significantly improved in this release, with the demo PHP code being completely rewritten and converted to use a MySQL database rather than session storage.  As a result, the recurrence demo works better, I was able to resolve a bunch of bugs related to hacky session code, and best of all the example code might actually be useful to look at!  Make sure you look at the examples/server/README.md for details on getting the new code and database set up.

There is also a new recurrence Rule class that supports parsing RRULE strings and generating human-readable descriptions from them. Thanks to Gabe Sidler for significant contributions with that.

Sencha Cmd

Lately more and more people have been asking that Extensible be made compatible with Sencha Cmd v3 to support builds with automatic dependency management and code optimization. While the ultimate fixes required can’t be made until Extensible 2.0 (it will require making a few API changes), I’ve added some workarounds that should work for now and get people moving forward with Extensible and Cmd (without impacting the existing build scripts). If you want to learn more, have a look at this forum post for more info.


Another nice improvement in this RC is the long-overdue conversion of the Extensible documentation center from ext-doc (aka Ext 3 style) to the fancy new JSDuck format, just like the Ext 4 docs.  They still need some work before the final release, but it’s already a big improvement over the previous version.

Toward 1.6 Final

The main outstanding task for finishing 1.6, aside from any bugs that might arise from this RC, is recurrence documentation. I’m currently working on finishing up the API docs for all of the new recurrence classes, and I’ll be adding a detailed guide specific to setting up and working with recurrence.

If you can download the RC today, test it out, and report any bugs you might find, that would really help!

Posted in Calendar Pro, Extensible, Releases | 2 Comments

Squash Variable Leaks with Siesta

JavaScript makes it incredibly easy to create global variables accidentally, which is inefficient and can also lead to very hard-to-debug bugs later. Simply omit the var keyword before a variable assignment, and you’ve inadvertently leaked a variable by defining it in the window scope.

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:

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.

Global var failure

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:

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:

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.

Posted in Calendar Pro, Extensible | Tagged , | 1 Comment

Extensible 1.6.0 Beta

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.

Enabling Recurrence

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

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!

Posted in Calendar Pro, Extensible, News, Releases | 1 Comment

The Blog Lives

Hopefully this post marks the end of the broken RSS feed we’ve had for a while now. It’s been quite an adventure getting it restored. The entire process left me feeling something like this:

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!

Posted in News | 1 Comment

Recurrence Teaser

A quick look at the current progress (click for full size):

Recurrence Preview

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

Posted in Calendar Pro, Extensible | Tagged | 1 Comment

Preparing for Ext 4.1 (Part 3)

As of this writing, Ext 4.1 Release Candidate 1 was just published a couple of days ago, so I thought it would be a good time to wrap up this series. In part 1 I outlined resources for learning about Ext 4.1, and in part 2 I dove into some of the common issues I dealt with myself while upgrading Extensible to support 4.1. In this final post I’m going to illustrate a couple of examples where I’ve had to implement API patches while still supporting multiple versions of Ext simultaneously (this will be especially useful for anyone writing components used by other developers).

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:

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):

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):

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

Posted in Ext JS, Extensible | Tagged | 3 Comments

Preparing for Ext 4.1 (Part 2)

In part 1 of this series I listed all of the major blog, video and forum resources related to the Ext JS 4.0 to 4.1 upgrade. In this post I’d like to dive into some of the specific changes I had to make while upgrading Extensible to 4.1, most of which are not explicitly listed anywhere as official breaking changes.  Some of my issues were due to overriding private code, but some were subtle changes in behavior or other things that cannot be considered “API changes” but affect the end result nonetheless.

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.

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:

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 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):

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:

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:

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

Posted in Ext JS | Tagged , | 2 Comments

Preparing for Ext 4.1 (Part 1)

Ext JS 4.0 has been out for almost a year now, if you can believe that (the 4.0.0 final release was April 26, 2011). There have been 7 minor releases since then, but most people have been waiting a while now for Ext 4.1, which will address a lot of the fundamental performance issues introduced in Ext 4 (primarily in older IE browsers), in addition to a few nifty new features as well. As of this writing, Ext is at 4.1 beta 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.


  • 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.


  • 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

Posted in Ext JS | Tagged , | 3 Comments

We’re Hiring

Extensible is growing, and we’re looking for developers interested in getting in on the ground floor of something cool. We’ll have lots of opportunities for product development, project work, training, you name it. Since we are still early on in building the company, you’ll be able to step in and make a huge impact on our direction, culture and success.

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.

Posted in Extensible, Jobs, News | Comments Off on We’re Hiring