SproutCore 1.8.2 Released

written by SproutCore

Comments Off

[edit] Due to a mistake in the included files of the published 1.8.2 gem, the gem needed to be re-built.  Therefore the current working version of the gem for SproutCore 1.8.2 is sproutcore-1.8.2.1.  Sorry for any confusion.

We are pleased to announce the release of SproutCore 1.8.2. This release contains minor fixes to the 1.8 code-base and will likely be the last patch of 1.8 prior to the 1.9.0 release. To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

  • Fixed syntax error in Datastore unit test.
  • SC.SplitView can now mixin SC.SplitChild.
  • Thinned picker pane border divs so that they don’t overlap the content view.
  • Prevents target property conflict when configuring button targets with SC.AlertPane.
  • Changed the aria-orientation of horizontal SC.ScrollView to ‘horizontal’ from ‘vertical’.
  • Allows SC.CollectionFastPath to work with sparse content by always returning an item view even when content isn’t yet available.
  • Prevents SC.GridView from iterating over its content array in order to work with sparse content.
  • The ‘mobile-safari’ body class name is no longer being added in all browsers.
  • Enables pasting in SC.TextFieldView to notify that the value changed.
  • Prevents default touch behavior being intercepted on <textarea> and <select> elements.

Announcing SproutCore 1.8.1!

written by SproutCore

Comments Off

We’re pleased to announce the release of SproutCore 1.8.1.  To upgrade to the latest version, simply run:

gem update sproutcore

If you installed SproutCore using the installer, please note that due to the strain that maintaining the installers puts on the release process, we will not be updating the installer for each patch level release.   Therefore, to get the very latest stable version, it is recommended that you install the SproutCore gem.

Installing the gem is actually quite easy and there are detailed instructions for each platform at http://sproutcore.com/install/.  Simply find your platform and go to the Advanced Install tab, which helps you get Ruby properly installed.  If you’ve already got Ruby 1.9 installed, it is as simple as gem install sproutcore.

Continue reading →

Wesley Workman & Tim Evans are now SproutCore Reviewers

written by Tyler Keating

1 Comment

Please join us in congratulating Tim and Wesley on achieving SproutCore Reviewer status.  They are two of the most active contributors and have shown that they share our ideal of making SproutCore the most feature rich and highest quality application development framework.

More importantly, please join us in thanking Tim and Wesley and all the Committers and Reviewers for the work they’ve done to get us here.  We ask a lot of our burgeoning team and we are fortunate to have such people.

Announcing SproutCore 1.8!

written by Tyler Keating

6 Comments

I’m very pleased to announce the release of SproutCore version 1.8.0.  This release includes several new features, improvements and bug fixes and is a recommended upgrade for all SproutCore developers.

To install the latest version of SproutCore, visit http://sproutcore.com/install/ to get an updated installer for your system or if you are using the SproutCore gem, simply run:

gem update sproutcore

Continue reading →

Sprint Towards 1.8 Release

written by Tyler Keating

6 Comments

SproutCore is about to get a new release on February 29, 2012 and we want to kick it off with an important sprint over the last weekend of the month.  As an open-source project, the success of SproutCore depends on you and others like you, so please consider setting aside some time to get involved.  Thanks!

 

Aside:  We’ve decided that the next release of SproutCore will be titled 1.8.  It’s simply an indication that the code base has changed enough since the 1.7 beta, which should have been finalized some time ago but was missed during the rocky period when SproutCore 2.0 was determined no longer to present the future of SproutCore.

Welcome to Maurits Lamers and Mitch Oliver

written by Tyler Keating

2 Comments

Hot on the heels of last week’s introduction of five new team members, I’m pleased to announce that Maurits Lamers and Mitch Oliver have also signed on as SproutCore Committers. As with the people from my previous post, these names should be of no surprise to anyone who has been with SproutCore for some time.

For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get another Reviewer’s feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.

As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and sproutcore@googlegroups.com and show them your support.

Welcome to SproutCore’s newest Committers and Reviewer

written by Tyler Keating

Comments Off

As noted in the previous post, we are in the beginning of a major new thrust in SproutCore development and community involvement. As part of this work, we’ve created a guideline to becoming a contributor and list of contributors.

Today, I’m pleased to announce that several people have already graciously accepted the offer to take on roles and contribute even more towards shaping the future of SproutCore as the best application development framework, period.

Please join me in welcoming:

Jason Dooley,
Jeff Pittman,
Tim Evans, and
Wesley Workman

as the first SproutCore Committers and

Geoffrey Donaldson

as a new SproutCore Reviewer.

Undoubtedly, you will have come across these individuals on IRC and the mailing lists and will recognize them for their commitment to SproutCore and to the community. We are very excited and lucky to have them onboard.

In the future I expect to write many more posts like this, so to those that wish to be included, keep contributing, keep learning and we hope to hear from you soon.

Changes to SproutCore

written by Charles Jolley

19 Comments

Today I am writing to announce three important changes to the SproutCore project to better accomodate the community who are using it.

Change 1: SproutCore 2.0 Is Now Amber

SproutCore 2.0 started out as a rebuild of SproutCore around a more modular and modern design. Since then, the project has evolved in a different direction that means it will never be a complete replacement for SproutCore 1.x.

Therefore, we have decided to rename SproutCore 2.0 and manage it as a separate project. The new project will take on the original code name – Amber. It will be run by Yehuda Katz, Tom Dale, and Peter Wagenet.

The Amber guys are working on a new website and complete update for the new project. When they are ready we will post a link to the blog here so you can find out more about it. In the meantime, work on this project is continuing in the sproutcore20 repository on Github.

Change 2: New Contributor Process

With the Amber change, SproutCore will now once again be the sole domain of those wanting to create fast, native style applications on the web based on the SproutCore 1.x code base.

There is a very active community of developers who have invested heavily in this area. But, due to the structure of our governance system (via a Core Team), we haven’t done a very good job at making it easy for members of the community to get actively involved.

As of today we are adopting a new contributor process that will change all of this. The new process is based on the Reviewer/Committer model used by WebKit and several other big projects. It is fully documented on the SproutCore wiki, but here are the highlights:

  • All SproutCore projects will have reviewers and committers. Reviewers have the authority to approve changes to the code, committers can commit code when it is approved by a reviewer.
  • Anyone can become a committer once they have had a few patches accepted and a reviewer is willing to sponsor them. Anyone can become a reviewer once they have experience as a committer and the majority of other reviewers votes to approve them.
  • There is no longer a “Core Team”. Instead, we expect reviewers and committers to agree as a group on directional changes to the project. All discussions will be held on the sproutcore-dev mailing list or in IRC. We will avoid private mailing lists.

The goal is to make it possible for anyone who is willing to put in the time and effort to contribute to SproutCore to become a leader in the community. You don’t need a secret handshake to get in – just contribute.

To get this process started, we have identified a group of people – both former Core Team members and others – who qualify as either Committers or Reviewers and reached out to them. You can see the list of those who have already accepted on the wiki. If you aren’t on the list and you want to be, please email Tyler Keating and he will help you out.

Change 3: New Leadership

Finally, I want to talk a bit about my own role in SproutCore. Over the last year, my job has evolved to include a lot less coding and more other activities. While I am still very passionate about seeing SproutCore grow, I am not able to provide the kind of detailed attention that the project needs on a day-to-day level.

Part of the solution to this is to move towards the community driven contributor process above so that no one person can be a bottleneck anymore. We also need someone who has shown dedication to the community to help lead the process.

Tyler Keating is an independent developer who has been contributing to SproutCore for the last four years. He has shown dedication to the project and a desire to get others involved that is just what SproutCore needs.

Therefore, Tyler has agreed to become the new administrator for SproutCore. He is the main guy you should now contact with questions about managing the project day to day. I am going to remain as an honorary project owner so I can chime in on directional things.  In general though, I hope SproutCore can become more community directed than it has been in the past.  Tyler is here to help facilitate that.

Open source is only as strong as the community around it. I have been proud to get to work with some of the best technical talent on the planet through SproutCore. Thank you everyone for your contributions over the last several years.

SproutCore exists to serve your needs. Get involved and make it your own!

PS. I am posting a similar version of this post to the SproutCore mailing list where we can discuss this in the open.  Please feel free to join in there.

 

Why Handlebars?

written by Tom Dale

8 Comments

UPDATE:

The following post refers to SproutCore 2.0, which has split off as a separate project. However, the information within this post is entirely applicable with respect to using SC.TemplateView and Handlebars in SproutCore 1.8. If you wish to use SC.TemplateView in SproutCore, you only need be aware that the many views and controls in the Desktop framework may contain templates, but should not themselves be contained within templates.

When people check out SproutCore 2.0 for the first time, one question that they frequently ask is: Do I have to use Handlebars?

Handlebars, if you’re not familiar with it, is a semantic templating language written entirely in JavaScript. It’s an expressive language with a tag syntax reminiscent of HTML, except expressions (oftentimes referred to as “mustaches”) are wrapped in double-curly braces. A simple template might look like this:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>

Handlebars, unlike other templating solutions like Eco, doesn’t tempt you to embed domain logic in your HTML. Anything other than simple conditionals and loops must be contained in your application’s JavaScript, which enforces the separation of concerns and leads to better testability. The language is also extensible with custom helpers, which allows you to effectively write a template DSL for your particular application.

So, while the answer to the question is use whatever templating system you’d like, we think Handlebars is a great option. Perhaps most importantly, we’ve spent a lot of time deeply integrating SproutCore and Handlebars, such that you get a lot for free just by using bindings, computed properties, and the SproutCore object system. In fact, while we like the features and simple-yet-expressive syntax of Handlebars, the real reason we chose it when creating SproutCore 2.0 was because of its speed and architecture, allowing us the kind of integration that would be very difficult with other templating libraries.
Continue reading →

SproutCore 2 and AJAX

written by Peter Wagenet

17 Comments

UPDATE:

The following post refers to SproutCore 2.0, which has split off as a separate project. Therefore, the information in this post is no longer applicable to SproutCore, other than that SproutCore remains dependent on jQuery, but instead has an AJAX framework that wraps the jQuery AJAX functions for use in SproutCore. For more information on connecting to a server in SproutCore, refer to SC.Request. This post may still apply for some time to Ember.js

A question we hear often about SproutCore 2 is “how do I connect to a server?” The answer to this question is actually easier than you might expect. Since SC2 is dependent on jQuery, we already have access to all the standard jQuery methods, including the AJAX ones. In this post, I’ll explain to you how to use AJAX in SC2 to communicate with your server.

In this example, I’ll assume a standard REST backend. To make things easier on you, I’ve made up a basic one in Rails. You can grab it with:

git clone git://github.com/sproutcore/todos-server.git --recursive

If you just want to grab the completed SC code you can run:

git clone git://github.com/sproutcore/todos.git -b server

Anyway, lets dive into the code. All of our work is based upon the original SC2 To-Dos app, and I’ll walk through how we get from there to our completed AJAXified app.

Fetching from the Server

The first step is to fetch a list of our to-dos from the server. Here’s the code to do that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Todos = SC.Application.create({
  ready: function(){
    this._super();
    this.fetchTodos();
  },
 
  fetchTodos: function(){
    $.ajax('/todos.json', {
      success: function(data){
        Todos.todosController.beginPropertyChanges();
        data.forEach(function(item){
          item = item.todo;
          var todo = Todos.Todo.create({
            id: item.id,
            title: item.title,
            isDone: item.done
          });
          Todos.todosController.pushObject(todo);
        });
        Todos.todosController.endPropertyChanges();
      }
    });
  }
});

Continue reading →