SproutCore still alive and kicking

written by SproutCore

It has been quite a while since the last blog post. The reason for it is that there have been quite a few changes taking place since the last post.

The first news is that Tyler Keating has stepped down as project lead and has appointed Maurits Lamers to take over. From this spot we want to thank Tyler for the enormous amount of work he has done for the project and we wish him good luck.

Secondly we have been busy building new build tools using NodeJS instead of Ruby. The new build tools are simply called BT and are written in SproutCore. You can find more info on BT in the repository: https://github.com/sproutcore/build-tools. As the BT has had quite some time to mature, we are now dropping official support for the old Ruby based Abbot. The new BT offers quite a few advantages over Abbot:

  • Development server is much faster: The BT keeps and transforms all files in memory, speeding up a reload from 10s down to around 2s.
  • Many different build types: In abbot, it always was difficult to build SproutCore apps for different environments, such as Cordova. BT adds support for different types of bundling to match your specific wishes.
  • ES5 strict compatible: Abbot only supported SproutCore builds in ES5 non-strict mode. BT allows your SproutCore app to be fully ES5 strict compatible, and also offers support for ES6 through Traceur.
  • Written in SproutCore: BT is written in SproutCore, so as a developer familiar to SproutCore, it is much easier to contribute.

Thirdly the community has lost a few active core team members who were hired away. We want to thank them for their contributions. Sadly, the downside is that it has left a few projects such as documentation updates that were underway without active support. As such we are very much welcoming contributers of any kind!

Thank you for your patience and continuing support!

SproutCore 1.11.0 Release

written by SproutCore

The SproutCore team is very pleased to announce the final release of SproutCore version 1.11.0. This version continues in the tradition of SproutCore releases to become the fastest, most feature-rich and most stable version of SproutCore to-date and includes several new additions and improvements to make development with SproutCore even easier and to make SproutCore apps even more impressive.

For those wishing to install SproutCore for the first time, please visit http://sproutcore.com/install/ for instructions. If you are upgrading from a previous version of SproutCore, simply run the following:

$ gem update sproutcore

If you have any trouble installing or upgrading to 1.11, be sure to visit the mailing list sproutcore@googlegroups.com or the IRC channel #sproutcore for support. As always, the team and community are here to help!

Highlights of Version 1.11.0

The majority of the work done in 1.11.0 was to improve the existing API and to fix bugs. The list of changes is too long to include, but the following are the highlights.

Major New Features

Polymorphic Records (SC.Record.prototype.isPolymorphic)

The experimental polymorphic record support has been rewritten. It is now bug free, significantly faster and included in the datastore framework by default. This allows you to support truly polymorphic record types in the store. For more information on using polymorphism, there is a detailed description and useful examples in the SC.Record documentation here: http://docs.sproutcore.com/#doc=SC.Record&src=false.

SC.Binding Transforms

There are a few new binding transforms that can be used to reduce the amount of code you as a developer need to write. These are string, integer, equalTo and mix. The transforms string and integer are very simple and simply transform the value into a String or an Integer (according to radix argument). This is useful in particular for custom views that don’t want have to coerce every possible defined property value into a String or an Integer when necessary. See here: http://docs.sproutcore.com/#doc=SC.Binding&method=string&src=false and here: http://docs.sproutcore.com/#doc=SC.Binding&method=integer&src=false.

The equalTo transform is also very simple and simply returns true or false depending on whether the bound value is equal to the argument value. See here: http://docs.sproutcore.com/#doc=SC.Binding&method=equalTo&src=false.

Finally, the mix transform is a more powerful transform that may take some research to use properly. The benefit of mix is that it allows you to mix together multiple bound values into a single transform function. This is similar to the way that the and and or transforms work (in fact these were refactored to use mix), but mix allows you to specify a custom transform function. See here: http://docs.sproutcore.com/#doc=SC.Binding&method=mix&src=false.

Cross-origin resource sharing (CORS) with credentials

To allow SC.Request to work properly with cross-site Access-Control requests, we’ve added a new property to SC.Request, allowCredentials. This will allow cookies and authorization headers to be sent by configuring the withCredentials property of the XHR request. As part of this change, SC.Request includes a new property, isSameDomain, which correctly identifies if a request is cross-origin or not and only attempts to set the withCredentials property when not targeting the same domain. A brief description of this property is available here: http://docs.sproutcore.com/#doc=SC.Request&method=allowCredentials&src=false.


To simplify using WebSockets and to ensure that WebSocket messaging triggers a run of the SproutCore run loop, we’ve added a new class SC.WebSocket. Using SC.WebSocket makes communicating with WebSockets trivial to add to any SproutCore app. For details and examples, please see the documentation here: http://docs.sproutcore.com/#doc=SC.WebSocket&src=false.


The nested store is an extremely powerful feature of SproutCore that allows for complex data management within the client. For 1.11, nested stores have been expanded slightly to support even more advanced uses. The first addition is a new property conflictedStoreKeys that contains a list of all store keys that are in conflict with the main store. The purpose of this is for applications that automatically update shared live data that multiple users may edit. In such a scenario, one user might be editing a record that another user already completed and saved. Using conflictedStoreKeys the application can check for the presence of any conflicts from new data coming in before attempting to commit the changes from the nested store. Here: http://docs.sproutcore.com/#doc=SC.NestedStore&method=conflictedStoreKeys&src=false.

The other addition is the new SC.Store.prototype.chainAutonomousStore() method, which returns a nested store that is allowed to interact directly with a remote data store. Typically, nested stores are prohibited from committing changes directly to a remote data store, instead having to commit them to the main store which would then forward the changes on to the remote data store (via a data source which handles the actual communication and integration between client and server). However, by using an autonomous nested store, you can choose to commit changes within the autonomous nested store and only push successful changes to the main store. This can simplify the process when commits to the remote are expected to fail occasionally and we wish to avoid pushing any possibly invalid data into the main store. Here: http://docs.sproutcore.com/#doc=SC.Store&method=chainAutonomousStore&src=false.

Scale and Transform Origin

Scale is now a first-class layout property, correctly impacting frame and clippingFrame. If a view is scaled, the width & height of the frame will be correct as the view appears. For example, a view with layout equal to { width: 100, height: 100, scale: 2 } will report a frame of { x: 0, y: 0, width: 200, height: 200, scale: 2 }. The clippingFrame also takes a scaling origin into account as well and as part of this change, there are two new layout properties: transformOriginX and transformOriginY, which define the percentage (between 0.0 and 1.0) on the respective axis about which the scale transform is applied. These properties affect all transform styles and so can be used to also change the origin of a rotate style. You can learn about using layouts here: http://docs.sproutcore.com/#doc=SC.View&method=layout&src=false.

Legacy Framework

SproutCore will work with browsers as old as IE7 (don’t laugh, we all have customers that can not/will not move to newer browsers for some time), however in order to prepare for the day when the lowest common denominator can be raised, there is a new sub-framework within SproutCore, :'sproutcore/legacy', which is meant to contain all code providing support for legacy browsers. Currently, this includes the existing polyfill for window.requestAnimationFrame and a new polyfill for Object.keys, but will continue to grow to include any specific workarounds for these older browsers. Because it’s important for SproutCore apps to “just work” as much as possible, the legacy framework is included by default by requiring :sproutcore in a project’s or an app’s Buildfile.

To build an app that will only work with the newest browsers (probably not a great idea —), you may change your Buildfile requirements to include only the specific SproutCore sub-frameworks you need. For example,

config :my_app, :required => [:"sproutcore/desktop", :"sproutcore/datastore"]

Major Changes & Improvements

SC.Gesturable & SC.Gesture (SC.TapGesture, SC.PinchGesture, SC.SwipeGesture) Refactor

After some investigation, it was found that there were a number of issues with the built-in gesture support. For example, two touch taps would throw an exception, pinches would fail to register and in particular, supporting multiple gestures concurrently failed in a number of scenarios. In order to fix these problems, the gesture code has been rewritten from the top-down.

It is now possible to mixin SC.Gesturable to a view and use events to react to multiple gestures concurrently. Examples of the advanced type of behavior that the gesture code allows include,

  • Responding to single finger, two finger or any other number of touch taps, pinches (> 2 touches) or swipes individually or as a group. For example, your code may want to perform different actions when a single finger taps vs. when there is a two finger tap.
  • A touch session, the time between when the first touch begins and the last touch ends, may contain more than one gesture. For example, it’s possible for the user to perform a pinch, then use a third finger to tap, then swipe the remaining fingers. At the least, the ability to perform gestures in a single touch session multiple times, makes the gesture recognition more robust against stray accidental touches.
  • Swipe gestures can now be configured to match against any combination of arbitrary angles, not just combinations of left, right, up & down.
  • Swipe gestures no longer trigger by simply moving far enough in one direction. They must also move quickly and end quickly (configurable).

How does this affect your code?

For the most part, this should have no effect on existing implementors of SC.Gesturable. The three built-in gestures: SC.TapGesture, SC.PinchGesture, and SC.SwipeGesture are still defined and they work much better than before. However if you have defined a custom SC.Gesture subclass, it will unfortunately not work correctly with this update. Because we felt the previous version of SC.Gesture‘s API was too complex and incompatible with the behavior we needed to achieve, we decided it was better to rewrite it in a simpler form. We’re very sorry for this backwards incompatibility, and would be happy to help with a migration (see mailing list and IRC info above).

SC.PickerPane Pop “Out of the Anchor”

This view has been given special behavior when used with SC.View’s transitionIn plugin support. If the plugin defines layoutProperties of either scale or rotate, then the picker will adjust its transform origin X & Y position to appear to scale or rotate out of the anchor. The result is a very nice effect that picker panes appear to pop right out of their anchors, rather than just appearing offset.
To see it in effect, simply set the transitionIn property of the pane to one of SC.View.SCALE_IN or SC.View.POP_IN.

SC.ScrollView Refactor

The most ambitious undertaking in 1.11, was a total refactor of SC.ScrollView. There were a few features that we wanted to fix and improve in scroll views, such as scaling, alignment and touch handling and after a few attempts, we rebuilt it entirely from scratch method-by-method. This allowed us to question each design decision that went into the original SC.ScrollView and search for improvements and the result is that SC.ScrollView works better and is faster then ever before. We were able to reduce the amount of code, remove some internal observers and still do a better job of supporting touch, scale and alignment.

For example, scaling the content of a scroll view will now maintain its visual center rather than hugging the side, which dramatically improves the zooming experience. Touch gesture animations, such as the bounce back and deceleration, are now animated using requestAnimationFrame for smoother performance.

Here is a list of important changes,

  • SC.ScrollView.prototype.scale now works as advertised!
  • If horizontalOverlay or verticalOverlay is true, the scroll view will use SC.OverlayScrollerView by default. It’s no longer necessary to also set horizontalScrollerView: SC.OverlayScrollerView in order to get overlaid scrollers.
  • Overlaid scroller bars now fade out when not in use.
  • Use horizontalAlign and verticalAlign properties to align fixed-width or -height content.
  • SC.ScrollView alignment handling has been improved for container (i.e. the scroll view) or content size changes to support the following scenarios:
  1. The scroll view is left (or top) aligned, scrolled to the maximum right (or bottom) edge and container or content changes size: the content should stick to the right (or bottom) side.
  2. The scroll view is left (or top) aligned, scrolled to the minimum left (or top) edge and container or content changes size: the content should stick to the left (or top) side.
  3. The scroll view is right (or bottom) aligned, scrolled to the maximum right (or bottom) edge and container or content changes size: the content should stick to the right (or bottom) side.
  4. The scroll view is right (or bottom) aligned, scrolled to the minimum left (or top) edge and container or content changes size: the content should stick to the left (or top) side.
  5. The scroll view is center (or middle) aligned, scrolled to the center (or middle) and container or content changes size: the content should stick to the center (or middle).

Finally, a critical difference in the new SC.ScrollView is that it uses SC.View layout changes to position its content rather than adding margins that pushed the content beyond what its layout was set to. The reason for this change was to allow for GPU accelerated content positioning without duplicating code (the SC.View layout code already supports it). This means that it is possible to fix the layout of your content (layout with top, left, width & height) and set wantsAcceleratedLayer to true to get your content scrolled via GPU accelerated positioning. This can improve each scroll event render by as much as 50%.

SC.MenuScrollView Refactor

As with the SC.ScrollView refactor, SC.MenuScrollView has been improved greatly in its implementation and performance.

Responsive Design and Design Modes

Design modes are the answer to the problem of how to create a SproutCore web app that can handle vastly different screen size “designs”, beyond just stretching and squishing, as simply as possible and without hurting performance. While CSS media queries may be used for static websites, they don’t provide much value to a client side app like those made with SproutCore, primarily because using CSS to change the layout and the visibility of views would break the state of the application that exists in code.

Instead, we use the modeAdjust property and add simple overrides to the layout or any other properties of views that will apply for the specific design “mode”. For instance, a view can be visible by default and only hidden in the small, ‘s’ mode with a simple hash,

largeOnlyView: SC.View.extend({
  isVisible: true, // visible by default
  modeAdjust: { 's': { isVisible: false } } // hidden on small screens

For a demonstration of this, please visit the Showcase here: http://showcase.sproutcore.com/#demos/Responsive%20Design and for more details on using design modes, see here: http://docs.sproutcore.com/#doc=SC.Application&src=false.

General Changes & Fixes

There are are literally hundreds of other changes and fixes, which would take many more pages to write about. To see the entire list, please view the Change Log (Note that there were three release candidates with their respective changes listed below them). Here is a small sample of the many changes,

  • Improved: When the online/offline value of window changes, SC.device runs the run loop.
  • Improved: Subclasses can now override bindings without issue.
  • Added: DateTime localizations are now available in French.
  • Improved: Updated to jQuery 1.11.1. Notably, there was a serious memory leak in jQuery 1.8 where the tokenCache grew continuously.
  • Improved: SC.State performance by removing expensive observers.
  • Improved: Performance of core SC methods: SC.mixin, SC.supplement as well as SC.Function.enhance. Benchmark: SC.mixin & SC.supplement ~ 58% faster
  • Improved: Removed several instances of arguments instantiation, which is terribly slow.
  • Added: Added toolTip property to SC.MenuItemView, and the corresponding itemToolTipKey to SC.MenuView.
  • Added: Added horizontal layout for SC.ListView using layoutDirection property.
  • Improved: SC.UndoManager has been refactored to allow easier undo action grouping.
  • Added: SC.DateTime.prototype.toFormattedString now takes ‘%o’ formatter to specify the date’s ordinal.

And the list goes on…

SproutCore 1.11.0 Release Candidate 3

written by SproutCore

The final release candidate for version 1.11.0 is now available.

This release candidate fixes a few of the remaining bugs and addresses the regressions that had crept in since RC1. It also introduces several improvements and nice new features, such as the ability for SC.PickerPanes to pop “out” of their anchors when using a scale transitionIn plugin (i.e. SC.View.SCALE_IN) for a really nice effect or the ability to easily check for conflicts between a nested store and its parent using the new conflictedStoreKeys property. For a list of all the changes, please view the detailed change log which can be seen here: SproutCore CHANGELOG.

To install SproutCore 1.11.0.rc3 for testing, please upgrade your previous version of SproutCore by running the following:

gem update sproutcore --prerelease

We will be using your feedback over the next couple weeks to finalize 1.11.0, so please be sure to try it out and let us know what issues remain: Github Issues. To discuss the next version or to discuss SproutCore in general, as always please use #sproutcore on IRC or email to sproutcore@googlegroups.com.

SproutCore 1.11.0 Release Candidate 2

written by SproutCore

The next release candidate for version 1.11.0 is now available.

This release candidate addresses a few bugs, makes some important under-the-hood improvements (e.g. SC.View layout update performance, reducing SC.Event memory churn, avoiding leaking arguments) and updates the API of SC.ActionSupport. The detailed change log can be viewed here: https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md

To install SproutCore 1.11.0.rc2 for testing, please upgrade your previous version of SproutCore by running the following:

gem update sproutcore --prerelease

We will be using your feedback over the next few weeks to finalize 1.11.0, so please be sure to try it out and let us know what issues remain: Github Issues. To discuss the next version or to discuss SproutCore in general, as always please use #sproutcore on IRC or email to sproutcore@googlegroups.com.

Developer Journal: Memory Optimization

written by Tyler Keating

The next release candidate for 1.11.0 will be out very shortly, but I thought it best to post a brief update on the past week’s work as this week saw a concentrated effort on core optimization.

First we took another look at the use of arguments lists throughout the framework and found several more occurrences of it being accessed in an inefficient manner. Depending on the browser, accessing arguments in such a way that causes it to be allocated can be up to 80% slower and so it’s really good to have these all fixed.

The other piece of optimization work undertaken has been much more difficult. We’ve been looking into high frequency event handling, such as during touch dragging or mouse moving, with an eye towards managing memory better. Since SproutCore already does as much as possible to avoid touching the DOM, the largest issue that affects the “fluidity” of the user interface is JavaScript garbage collection. If the heap is filling up rapidly with unreferenced objects, the JavaScript engine will be forced to collect them more frequently and the act of collecting them will take longer. Since we have no control over when garbage collection occurs, for example we can’t prevent it from happening in the middle of a transition, the best we can do is to reduce its impact. So essentially, our goal is to not allocate any additional memory during high frequency events and our primary means to that goal is through shared Object re-use.

As I mentioned, this has been very difficult, but we’ve been steadily identifying and replacing Objects (hashes) and Arrays with single shared versions wherever possible. This includes some key high touch areas in SC.View’s layout code and SC.Event’s architecture. In fact, a major refactor of SC.Event was completed in order to re-use a single shared normalized event instance per event type. This means that whereas previously each event (e.g. touchmove) would allocate a new normalized SC.Event each time, it now re-uses just the one. The affect of all of this work is a slightly flatter memory profile with fewer and smaller saw-tooth garbage collection drops in it. It’s not perfect yet and it’s likely impossible to not allocate a bit of memory on each event, but some exciting progress is being made.

Lastly, a bit more internal debugging code was moved into debug-mode only. This means that the code will not be included in production builds, thus reducing the overall size of the production JavaScript by a tiny bit. A minor optimization, but one none-the-less.

SproutCore 1.11.0 Release Candidate 1

written by SproutCore

We are pleased to announce the pre-release of SproutCore 1.11.0. Where version 1.10 drastically reduced the memory use of SproutCore, 1.11 goes even further to ferret out bottlenecks and improve the overall performance for SproutCore apps.

This new version also introduces many API improvements and additions to further ease the development of modern large scale web applications. When 1.11.0 final is released in the coming weeks, we will post an in-depth look at the major changes, but until then, the full list can be viewed here: https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md

To install SproutCore 1.11.0.rc1 for testing, please upgrade your previous version of SproutCore by running the following:

gem update sproutcore –prerelease

We will be using your feedback over the next few weeks to finalize 1.11.0, so please be sure to try it out and let us know what you think: Github Issues, #sproutcore on IRC or email to sproutcore@googlegroups.com.

Developer Journal

written by Tyler Keating

Since there has been so much activity in SproutCore lately in the run up to 1.11.0, I thought it would be best to start a more regular update on the changes occurring in master. While we occasionally highlight a specific new feature in depth through a “Dispatches from the Edge” post, there are actually hundreds of small, yet interesting, changes occurring weekly that aren’t large enough to warrant their own post. It’s my hope to capture these changes in a weekly to bi-weekly developer update. So let’s begin with the last couple of weeks (Note: no changes are final).

Touchy Mice

If you own an Apple Magic Mouse, you may have found some web apps difficult to use. A notable public example of this problem was in the Google Maps app. When you released your finger after dragging the map around, the extra mouse wheel events that were sent as your finger was lifted caused the map to zoom in and out rapidly. Now I believe Google has fixed that problem with their app and we have as well for SproutCore’s SC.SliderView and SC.ScrollView, both of which use mouse wheel events. To prevent the extra mouse wheel events that can occur on click or release from triggering the control, we ignore any mouse wheel events that fire while the mouse is pressed up until 250ms after the mouse up event. Depending on how adept your users are with their mice clicks, the result may be a huge improvement or barely perceptible, but even as small a change as it is to prevent scrolling jiggle on mouse click, it’s just one more brick in the incredible user experience wall that we’re trying to build with SproutCore.


We’ve been working diligently on SC.ScrollView performance (more on that later), but in the process we’ve implemented some other performance improvements.

We fixed a problem with excessive layout updates for certain types of views. If a view used viewDidResize to check for size changes and then make further adjustments to its position, the adjustments to its position would have appeared as further changes to its size. In particular, SC.PickerPane suffered from this, since it re-positions itself whenever its size changes.

Speaking of SC.PickerPane, this one got a performance scrub down. You may not have been aware, but SC.PickerPane now has some special code enabling it to appear within scrollable content and move correctly when the content scrolls. It’s a really nice advanced feature, but there were a couple of issues hampering the performance of it. The first was that the scroll view observers were too greedy observing offsets of the scroll view for changes and repositioning on each change. What this meant was that an SC.PickerPane could reposition itself up to 6 times in a single run loop as the content of the scroll view changed. Instead, the proper pattern for observing multiple properties (or noisy properties) is to filter the input through an invokeX (i.e. so even though 6 calls to the observer function may occur, we only call positionPane once). Additionally, we no longer observe the offsets if the scroll view can’t even scroll and finally, there is a bug fix in there too. When the picker’s anchor gets moved on its own, we ensure that the anchor is in its new position before we re-position.

One of the most important classes within SproutCore has been sped up a bit too. SC.State had two observes helper functions used to be notified when its enteredSubstates and currentSubstates arrays changed. Since these arrays are modified by the owner statechart, the observers needed to be chained enumerable observers. However, this resulted in slower object initialization for each state object and excess observer firing as the entered and current substates change. Instead, we simply notify the target state directly each time that the owning statechart makes a change to its enteredSubstates and currentSubstates. This one has has a couple benchmarks to site:


  • initStatechart in unit tests: ~21ms to ~13ms (~38% faster)
  • initStatechart in large application: ~81ms to ~51ms (~37% faster)

While a reduction of 30ms in a, generally once run, method isn’t much to write home about, we are relentless in shaving every possible millisecond that we can. More notably, we’ve recently made some serious performance improvements to the core SC methods: SC.mixin, SC.supplement as well as to SC.Function.enhance. SC.mixin and SC.supplement iterated the arguments object to insert a boolean flag to pass to a private function that then iterated the arguments again in order to remove the flag argument, which is totally unnecessary. Instead, SC.mixin and SC.supplement iterate the arguments once and pass the new Array to the private function, removing the need for a second iteration.

More importantly though, is that these three areas no longer access the arguments object to copy it, which required the browser to instantiate it and is costly. Instead, we now do a fast copy (similar to this: http://jsperf.com/closure-with-arguments) without instantiating the arguments object. By doing a fast copy of arguments these functions are now optimizable by V8.

Benchmark: SC.mixin & SC.supplement ~ 58% faster

Also,SC.RenderContext‘s setStyle method was updated so that it could be optimized for V8 as well.

SC.ScrollView and SC.MenuScrollView Refactor

This one will actually get its own blog post. For now, I just wanted to mention that these views have seen massive refactoring. The purpose of the changes has been to simplify the logic, which had gotten fairly unruly, but more importantly to grind and grind on the little details so that scrolling and scaling should feel as good and as natural as possible. We’ll post an in-depth on SC.ScrollView in the next couple weeks.

SC.MenuPane Tidy

We fixed SC.MenuPane automatic resizing to fit within the window. The positioning code used in SC.PickerPane failed to apply adjustments to the width or height of the pane, which had been calculated in order to fit long menus within the window. This included improving the menu positioning code to respect the value of windowPadding and fixing a problem where the items array was not observed for content changes if it was set on create.

We removed an unnecessary layout change in createChildViews, which also meant that creating a menu pane as a singleton (i.e. with no run loop) would throw invokeOnce warnings.

WARNING We removed the SC.MenuPane.VERTICAL_OFFSET property. SC.PickerPane already has a provision for offsetting panes from the window’s edges, windowPadding, and that is the property that is being used now.

General fixes and changes

Finally, there are always a large number of little changes. Here are some from the last few weeks.

  • Removed an extra call to SC.RootResponder‘s computeWindowSize each time that a pane is appended. This is unnecessary, since the root responder recomputes its window size property whenever the window actually resizes.
  • Improved the default styling of overlay scroller views. Making them look more like natural overlay scrollers in OS X and making them more visible against dark backgrounds.
  • Improved the view management of SC.ContainerView a bit. If contentView is set as an uninstantiated view class, it will instantiated correctly (you should set nowShowing though normally).
  • Fixed SC.ObserverSet to pass the given context to the observer method. SC.ObserverSet.prototype.add() accepts a third argument, context, but it did not actually pass it along to the observer method.
  • Improved SC.MenuItemView handling of submenus. Previously if the item’s submenu was visible and the mouse exited back onto the menu item view, it tried to re-append the same submenu. Instead, it now checks to see if its submenu is already attached before attempting to enter it again.
  • Fixed a bug in SC.ContainerView‘s override of set so that it may be chainable.
  • Did you know you can cancel animations created with animate in place? This includes transform transitions whose in place value is represented as a 4×4 matrix that must be decomposed to find the current value for translate, scale and rotate in the three planes. We’re still working on rotation around the X and Y axis, but all other transforms can be cancelled. A demo on this will come later.

I apologize that this post is quite long, if it actually included all the work in the scroll and scroller views it would be three times longer, but as you can see, there is a lot going on. I hope to keep these posts much shorter from now on by keeping them more regular.

Dispatches From the Edge: Polymorphic Records

written by Tyler Keating

We have good news for anyone using the experimental polymorphism framework from within SproutCore. You’ll be glad to know that it has now made its way into the official datastore framework as part of SC.Record. If you have been using this framework, you’ll be even more glad to learn that polymorphic records are now significantly faster and more memory efficient. As well, this change includes a critical bug fix that resulted in polymorphic records getting mismatched when their id was changed.

For those interested in what this change means, here’s how it works. First, if you’re not familiar with polymorphism, it’s similar to inheritance, but differs in that polymorphic subclasses share a common “identity”. Here’s what that means with respect to the data model. In typical inheritance, the subclasses inherit the traits (attributes) of their superclass, but they can’t stand-in for that superclass (i.e. their identity or type is unique). In polymorphic inheritance, the subclass still inherits the traits of the superclass, but is now also considered to be the “same” type as the superclass. This means that when you query for records of a polymorphic super type, you’ll also receive records of all the polymorphic sub types.

This is especially useful functionality, because data is often stored in exactly this type of generic manner. It’s typical in SQL databases to have a large table where certain attributes apply to one specific subtype of the data, other attributes apply to another subtype and some attributes apply to all. With polymorphism, we can model this situation precisely.

So how do we use it in SproutCore? It’s simply a matter of adding the isPolymorphic property to a record class and extending it. Let’s look at an example from the SC.Record documentation that will hopefully clear up any remaining confusion on how polymorphism works.

// This is the "root" polymorphic class. All subclasses of MyApp.Person 
// will be able to stand-in as a MyApp.Person.
 MyApp.Person = SC.Record.extend({
   isPolymorphic: true
// As a polymorphic subclass, MyApp.Female is "equal" to a MyApp.Person.
 MyApp.Female = MyApp.Person.extend({
   isFemale: true
// As a polymorphic subclass, MyApp.Male is "equal" to a MyApp.Person 
// also. Not it is not "equal" to a MyApp.Female.
 MyApp.Male = MyApp.Person.extend({
   isMale: true
// Load two unique records into the store.
 MyApp.store.createRecord(MyApp.Female, { guid: '1' });
 MyApp.store.createRecord(MyApp.Male, { guid: '2' });
// Now we can see that these records are in fact "equal" to each other. 
// Which means that if we search for "people", we get "males" & 
// "females".
 var female = MyApp.store.find(MyApp.Person, '1'); // Returns record.
 var male = MyApp.store.find(MyApp.Person, '2'); // Returns record.
// These records are MyApp.Person as well as their unique subclass.
 SC.kindOf(female, MyApp.Female); // true
 SC.kindOf(male, MyApp.Male); // true


Dispatches from the Edge: ListView Goes Sideways

written by Dave Porter

SC.ListView has a new trick in the upcoming v1.11 (available now on latest master): a new layoutDirection property which can turn it from vertical to horizontal with one line of code. It’s a long-requested feature, and now it’s as easy as layoutDirection: SC.LAYOUT_HORIZONTAL.

In support of this brave new world, a number of list view properties have new names, replacing all now-outdated mentions of “height” with “size”: rowHeight is now rowSize, et cetera. The new API is backwards-compatible with the old one, with the usual crew of helpful developer warnings to ease your project over without breaking it.

Happy horizontaling!

Automating SproutCore Unit Testing with PhantomJS

written by Greg Fairbanks

One of the new features in SproutCore v1.10.0 was a PhantomJS unit test runner. It allowed us to automate SproutCore’s own framework unit tests, giving us awesome continuous integration support right in GitHub via the great Travis-CI service.

If you use CoreTest, SproutCore’s built-in (QUnit-like) unit test framework, then you can also use this to run your own tests from the command line – meaning you can automate it, and hook it up to your own CI scaffolding. It’s impossible to overstate the impact that continuous, automatic unit testing has on the quality and stability of your codebase.


You will need to have PhantomJS installed before using the test runner. Full instructions for this can be found here.

If you are using SproutCore 1.10.1 or later, you can use the new sc-phantom command. This will handle invoking the test runner, passing through any arguments to PhantomJS.

If you are using 1.10.0 or are not using the gem, you will need to track down SproutCore’s installed location in order to run its test runner script. If you’ve got a copy checked out into your project’s frameworks directory, great! Just use that. If you’re using the gem, you’ll have to track it down yourself. It’s usually somewhere like ~/.rvm/gems/ruby-1.9.3-p374/gems/sproutcore-1.10.0 – if you’re unable to track it down, run gem env and look under the GEM PATHS heading for a hint.

Running the tests

First, start sc-server as you normally would. Once that is running, we can start the test runner. (If you are running SproutCore v1.10.0, replace sc-phantom with phantomjs $SC_PATH/lib/frameworks/sproutcore/phantomjs/test_runner.js in the following examples. See $SC_PATH note above for details.)


By default, this will run all the unit tests that abbot knows about, including the tests in SproutCore itself. This is probably not what you want, so you can use the --include-targets flag to tell the test runner what tests you want to run.

For example, if your app is called todos, running

sc-phantom --include-targets=/todos

will run only the unit tests in your app. If you also have a framework you want to test, you can make the argument to –include-targets a comma-delimited list of targets:

sc-phantom --include-targets=/todos,/my_framework

There are a few other options available for excluding certains tests and only running certain types of tests (app, framework, etc). For the full list, run:

sc-phantom --help