Dispatch From The Edge: Blacklists and Whitelists

written by Greg Moeck

The “true edge” of SproutCore nowadays is primarily the 2.0 branch, where the new and fresh is continually appearing. However that doesn’t mean that the 1.x branch has been forsaken, or forgotten. The 1.7 beta release has some pretty cool features that allow you to improve the performance of your application. What I want to focus on today is how to use a blacklist or whitelist with the 1.x build tools.

One of the biggest knocks against SproutCore 1.x is that it is a “big, monolithic framework”. You end up pulling in more than you’re ever going to use or need. This is a problem, particularly in a JavaScript context, because it increases the size of the file that needs to be sent down from your server, and then parsed by the browser. Particularly in a mobile context, this can be a serious performance drain.

Enter the SproutCore whitelist/blacklist. If there is a section of SproutCore 1.x that you’re not using inside of your application, you can use either a whitelist or a blacklist to tell the build tools not to include that code in the final packaged version of your application’s JavaScript. So for example, if my application is not using collection view, I could create a file called Blacklist inside of the root of my file directory, and put the following into it to exclude collection view:


{
"/sproutcore/desktop": "views/collection.js"
}

“/sproutcore/desktop” is the “target” for the build tools, which you can think of as basically the framework to target. Then, “views/collection.js” which is the “rule” for the build tools. If the list is a whitelist, then the rule would mean to include the file in the final build, whereas if the list is a blacklist, then the rule would exclude that file. So in this case, “/sproutcore/desktop”: “views/collection.js” tells the build tools to exclude the file “views/collection.js” from the desktop framework.

So if you have a 1.x app and you’re looking to improve the initial load time of your app, I would create a blacklist for your application, and go file by file seeing what you can exclude from the framework. Happy optimizing.

Dispatch From The Edge: Handlebars Debugging Helpers

written by Greg Moeck

Greetings all! It’s been a bit since our last Dispatch, and the edge waits for nobody, so quite a lot has been going on. This week I’m going to focus on a couple of helpers that have been added to aid in the debugging of view rendering with Handlebars templates.

Generally, when people start trying to debug a problem in their JavaScript, they go about it in one of two ways. Either they try and use console.log to log a value to the console, or they insert a debugger statement that essentially functions as a breakpoint that stops execution of the application at that point.

Both of these techniques have always worked fine inside of SproutCore, except inside of a Handlebars template. Since Handlebars does not allow you to execute arbitrary JavaScript code within your template, you were left trying to log or debug the view property that you were trying to display.

Enter two new Handlebars helpers: log and debugger. Now you can log a property on the template or add a debugger statement to pause execution directly into the template itself. What would this look like? Consider the following code:

1
2
3
4
5
  <div class="some-item">
    {{log name}}
    {{debugger}}
    {{name}}
  </div>

This would log the name property to the console, and then stop the execution, setting the current “this” property to the template. This means that you can do a this.get(‘name’), or any other property, on the template and it will print the value to the console window.

If you interested in how to do this sort of thing for yourself, the source file is very simple and you can read it for yourself here.

Hope this helps you in debugging your busted templates. Until next time this is Greg signing off.

Dispatches From The Edge: Handlebars Without Spans

written by Greg Moeck


As more people have been using templates to map the state of their views into the DOM, a couple of questions have continually come up. In this week’s Dispatch, I want to focus on how SC.TextField solves one of the common questions and offer some advice on building similar custom views.

Let’s first specify the common question: How would one go about implementing something like a textarea tag? Just about everyone tries to do it like this:

<textarea>{{content}}</textarea>

You would like it to render something like this:

<textarea>Some Content</textarea>

But instead, SproutCore outputs something that looks like the following:

<textarea><span>Some Content</span></textarea>

Why would SproutCore wrap your content inside of the span tag? Because the Handlebars template isn’t only responsible for the initial rendering, it’s also keeping that rendered content in sync with the state of your view. Because of this, it needs to be able to target an element inside of the DOM to replace when the state of your view changes. So SproutCore inserts that span tag into the rendered DOM so that it can later change the DOM when content changes.
Continue reading

Dispatch From The Edge: New Controls Built on Templates

written by Greg Moeck

The construction of the view layer has been greatly simplified by the new way of delegating the view’s rendering to templates. With templates, most things have gotten easier to do– particularly view rendering. However, there are a couple of benefits that the older ways of building views provide that became a bit more difficult within templates– namely, building controls. In this post, I’ll take you through the ways in which Templates have affected how we construct controls, and how to build yours as efficiently as possible.

Before templates, we had several drop-in objects that handled common controls. If I wanted to add a button to a view, all I had to do was something like this:

SC.View.extend({   
  button: SC.ButtonView.extend({     
   target: object,     
   action: 'something'   
  }) 
})

What was nice about this approach was that you didn’t have to worry about describing exactly how the button renders, or how it responds to things like mousedown or mouseup. This was convenient because generally all buttons have the same structure and code, and it let us work at a higher level of abstraction. If we were to do this inside of a new template structure, we would have to do something like the following:

views:
 
BaseView = SC.TemplateView.extend({   
        templateName: 'some_template' 
})
 
CheckAllView = SC.TemplateView.extend({   
    target: object,   
    action: 'something,   
    ...   
    mouseUp: function() {     
      ...
      this.get('target')[action]()
      ...
    }
    ...
 })
 
template:
<div class="something">
    ...   
    {{#view CheckAllView }}      
 
    {{/view}}   
    ...</div>

Continue reading

Dispatch From The Edge: Contributing To Sproutcore

written by Greg Moeck

The recent release of 1.5 has brought many new people to SproutCore, and as our community grows, more and more people are asking how they can help. This week, instead of focusing on whats new, I’m going to focus on how you can contribute to the bleeding edge of SproutCore. I’ll start with my top three suggestions.

1. Contribute to the SproutCore Guides

Back in the beginning of January, we recognized that the biggest challenge to new users trying to learn SproutCore was the limited quality and quantity of documentation. To solve this problem the SproutCore Guides project was born. To date, 15 guides have been completed and made available to the community, drastically improving the help that is available for people. But there’s still more work that can be done.

How can you start helping?

To be able to contribute to the project, the first thing you need to do is build the guides on your own system. In order to do that, do the following:

  1. Download and install the guides package
  2. Clone the guides source from git://github.com/sproutcore/sproutguides.git (git clone git://github.com/sproutcore/sproutguides.git within the directory you want to work).
  3. cd into the cloned directory (sproutguides), and run “guides build” to generate an the output directory, where you can build the files locally.

Once you’ve set up the directory, you can modify any of the files within the source directory.

Next, run “guides generate” to see them reflected in the output. The following video illustrates a typical workflow:

If you’re interested in writing a new guide for a section of SproutCore that hasn’t yet been covered, contact Yehuda at wycats@sproutcore.com with your idea.

2. Contribute to the Source Itself

There are two ways that you can contribute to improving the code of SproutCore itself.  Continue reading

Dispatches from the Edge: Template Views Part 2

written by Greg Moeck


In the last Dispatch we looked at how SproutCore incorporates the standard handlebars.js expressions and and helpers, and how bindings are automatically set for those expressions. This week, we’re going to take a look at some of the other ways that SproutCore extends handlebars.js to make interaction with the DOM even easier.

Class Bindings

A template needs to do more than tell the browser what content to display it also needs to tell the browser how to display that content. For example, in a to-dos application, we want our template to define what the to-do is, and if it has been completed, but we might also want to specify other aspects of the display. Maybe we want the text to grey out, or have a line through it once the to-do has been completed. How would we do this?

Well, with HTML we can modify the display using CSS. SproutCore has some helpers to make this easy. For example, If I wanted to have a class be added to an element only when a property is true I can use the classBinding helper. Let’s look at a concrete example.
Continue reading

Dispatches from the Edge: Part 1, Template Views

written by Greg Moeck

More and more developers are adopting SproutCore every day, and the need for great documentation and tutorials just keeps growing. The Core Team is also making rapid progress on the new parts of SproutCore—the so-called sexy Edge. We’ve got the fantastic new SproutCore Guides to tackle the mainstream parts of SproutCore, and now, I’m aiming to tackle the new and exciting Edge parts. 

Every other week I’ll be posting what I’ll call Dispatches from the Edge. Each Dispatch will highlight a feature from the most recent release of SproutCore, explain how to use it, and wax on about why it’s so darn cool. Dispatches will also be where the team posts announcements about upcoming SproutCore-related events. Online, offline, we’ve pretty much got it covered :)

I’d like for this to be as helpful and interesting as possible, so if there’s something you want to know about, do let me know. Comment, tweet, email—I’ll be listening!


There’s been a lot going on in the world of template views lately, making it an optimal first topic for the Dispatch. One new feature stands out as being particularly exciting… so I’ll start there :)

When you create a template for a view, that template is really specifying what the display should look like all the time. Since that’s the case, when one of the properties of the view changes, it would be nice if the view would automatically redraw that section of its display to accomodate the changes in the data. The new template view does just that.

Let’s look at an example:

Dispatches from the Edge Part 1a from SproutCore on Vimeo.


Continue reading