Brian Kotek: Inversion of Control

Pressing Pause while Compile, Dammit Ramps Up

Fri, 17 Aug 2012 09:34:00 -0700

I know that my blogging here has been sporadic. And I'm not alone: a number of my colleagues were in the same boat. So Joe Rinehart, Nic Tunney, Marc Esher, Scott Stroz, Todd Sharp and myself have decided to pool our resources. We've started a group blog called Compile, Dammit. This is an experiment, but so far it's going extremely well. Having multiple people working on the same blog means a lot more posts and a wider variety of perspectives. I think this is a very interesting idea that I haven't really seen tried before. The focus over on Compile, Dammit will be in two main areas: server development (Groovy, Grails, Spring, etc.) and client development (RIAs, ExtJS, JavaScript, CoffeeScript, jQuery, etc.). This isn't a hard-and-fast rule, and we'll likely see content on a whole range of topics. But most of the content will probably fall under those two umbrellas. So, I'll probably be pressing pause on this blog for a bit while I contribute to Compile, Dammit. If you're interested in topics like this, you should definitely add our new group blog to your reading list!

CoffeeScript Version of the ExtJS Car Store

Wed, 06 Jun 2012 10:00:00 -0700

As I mentioned in my previous post on using DeftJS, I've also adopted CoffeeScript. I've pushed a CoffeeScript version of the Car Store sample application to GitHub if you'd like to look through the source code. Since the application looks exactly the same, there's no point in uploading a second running version. The main difference is the fact that the code is written in CoffeeScript and then compiled to JavaScript. [More]

Getting Started with CoffeeScript

Tue, 29 May 2012 09:01:00 -0700

I've found CoffeeScript to be a great help when writing JavaScript. Since most of my future posts on Ext JS will probably be in CoffeeScript, I thought I'd explain the basics of how I use it. The easiest way to start is to download and install Node.js. Then, install CoffeeScript by opening a command line and running: npm install -g coffee-script That's all there is to the installation. To use CoffeeScript, you can perform a manual build at the command line to generate the equivalent JavaScript. I won't even bother showing this, because that sort of manual process is definitely something I don't want to do. Happily, CoffeeScript includes a simple build system using a file called Cakefile. Here is a starter version of this file:

coffee|
fs = require 'fs'

{print} = require 'util'
{spawn} = require 'child_process'

build = (callback) ->
  coffee = spawn 'coffee.cmd', ['-c', '-o', 'app', 'coffee']
  coffee.stderr.on 'data', (data) ->
    process.stderr.write data.toString()
  coffee.stdout.on 'data', (data) ->
    print data.toString()
  coffee.on 'exit', (code) ->
    callback?() if code is 0

task 'build', 'Build /app from /coffee', ->
  build()

Running cake build at the command line will recursively find any .coffee files in the folder /coffee and generate JavaScript in the folder /app. Obviously, you're free to change the folder names and paths as you need to. So that's better, but still not ideal. I don't want to have to manually run cake build over and over. We can take things further by adding a watch command to the Cakefile:

coffee|
fs = require 'fs'

{print} = require 'util'
{spawn} = require 'child_process'

build = (callback) ->
  coffee = spawn 'coffee.cmd', ['-c', '-o', 'app', 'coffee']
  coffee.stderr.on 'data', (data) ->
    process.stderr.write data.toString()
  coffee.stdout.on 'data', (data) ->
    print data.toString()
  coffee.on 'exit', (code) ->
    callback?() if code is 0

task 'build', 'Build /app from /coffee', ->
  build()
  
task 'watch', 'Watch /coffee for changes', ->
  console.log "Starting CoffeeScript compiler (watching for changes in /coffee folder)..."
  coffee = spawn 'coffee.cmd', ['-w', '-c', '-o', 'app', 'coffee']
  coffee.stderr.on 'data', (data) ->
    process.stderr.write data.toString()
  coffee.stdout.on 'data', (data) ->
    print data.toString()

Now, if we run cake watch, a directory watcher is created which will compile to JavaScript any time one of the .coffee files is changed! So you can just run this command, then mostly forget about it and get on with your work. CoffeeScript is a very simple, straightforward language. I was off and running with it in less than a day. The CoffeeScript site has good documentation, and you can find additional info in the free online version of the Little Book on CoffeeScript.

Exploring ExtJS with DeftJS

Tue, 08 May 2012 08:21:00 -0700

It's been quiet here on Ye Olde Blogg lately. I've spent the last few months trying out various HTML component libraries and JavaScript frameworks, and have finally selected what I think is the most promising combination: ExtJS with DeftJS. Anyone reading this is probably familiar with ExtJS, so I won't bore you with details on it. Suffice to say that its UI library rivals what is available in Flex, and indeed is better in many ways. (Data grids and trees, anyone?) The main thing that initially bothered me about ExtJS was its MVC implementation. In my opinion it has a several flaws, one being the service locator approach. Another is that controllers use selectors that are relative to the application container to reference views, which isn't very flexible. So I was pleased to see John Yanarella's contribution to the Sencha blog unveiling DeftJS. This is an extension to ExtJS which adds an inversion of control container and an improved controller tier through the use of ViewControllers. I decided to try creating a DeftJS version of the car store example application that Sencha outlines in the documentation. What follows is a quick overview of the results. Configuring the IoC portion of DeftJS is straightforward. Here, I'm specifying the two classes I want to add to the IoC container:

js|
Ext.onReady( function () {
    Deft.Injector.configure({
        carChartJson: 'carStore.store.CarChartJson',
        carDataJson: 'carStore.store.CarDataJson'
    });
});

Next, I inject these into my view, and provide the ViewController class that I want to manage the view. This allows DeftJS to create the associated ViewController at the same time the view is created, and to destroy it when the view is destroyed.

js|
Ext.define( 'carStore.view.CarListings', {
    extend: 'Ext.panel.Panel',
    mixins: [ 'Deft.mixin.Controllable', 'Deft.mixin.Injectable' ],
    inject: [ 'carChartJson', 'carDataJson' ],
    controller: 'carStore.controller.MyViewController',
...

Finally, my simple ViewController looks like this:

js|
Ext.define( 'carStore.controller.MyViewController', {
    extend: 'Deft.mvc.ViewController',
    mixins: [ 'Deft.mixin.Injectable' ],
    inject: [ 'carChartJson', 'carDataJson' ],

    control: {
        carGrid: {
            selectionchange: 'onCarGridSelectionChange'
        },
        carDetail: true,
        carChartPanel: true
    },

    config: {
        carChartJson: null,
        carDataJson: null
    },

    onCarGridSelectionChange: function( selectionModel, selections ) {
        var carDataModel = selections[0];
        this.getCarDetail().update( carDataModel.getData() );
        this.getCarChartJson().loadData( carDataModel.getData().quality );
    }

});

I'm specifying the ID values (carGrid, carDetail, and carChartPanel) of the view elements I want to obtain references to. If necessary, a component query selector can also be used here. Note that unlike a standard ExtJS controller, these are relative to the view being managed rather than relative to the root application container. However, just like an ExtJS controller I can attach event listeners to the view instances. In this case, I'm handling the grid's selectionchange event to update the detail and chart views for their selected car. Essentially, this is an implementation of the Passive View design pattern. That about covers the more interesting bits of this application. Since it's based on a very simple example, the rest of the code is pretty standard ExtJS. I've uploaded a running version of the app, and have pushed the source to GitHub for anyone who wants a deeper look. DeftJS seems like a great extension to ExtJS. Not only that, but looking at the source also re-kindled my interest in Jasmine and CoffeeScript. The Jasmine specs for DeftJS are quite illuminating from a learning perspective, and the whole DeftJS framework is actually authored in CoffeeScript before being compiled out to JavaScript. I'll take a deeper look at both of these in upcoming blog entries.

Thoughts on Flex and HTML5

Tue, 22 Nov 2011 08:39:00 -0700

It has now been a little over a week since Adobe revealed its plans for the mobile Flash player and the Flex SDK. Now that the dust has started to settle and some additional information has been made available, I wanted to give my candid impression of what these announcements mean. I'll begin by stating the obvious: Adobe did a very poor job of coordinating and delivering these announcements. Anything I say at this point will simply be beating a dead horse. This was a PR disaster and one can only hope they learn something (ideally, many somethings) from sifting through the wreckage. I won't dwell any further on this since we have no control over what happened and I'm interested in looking at what these announcements mean going forward. I suspect that the news that Adobe was stopping work on the mobile Flash player didn't actually surprise very many people. Further, I doubt many people actually care much. Yes, it's nice to be able to view Flash content on my Android tablet. And yes, its easy to forget that the existing 11.1 player will continue to work for a long time and allow people to keep viewing the vast majority of Flash content. But no one was building browser-based mobile Flash sites. Why? Because you still had to create a non-Flash version of it if you wanted to target all mobile devices. Once the sting of all the "Steve Jobs Won" gloating wears off, I believe most people will see the wisdom of this decision. Some people appear to have a problem with this choice, but no one I know really cared at all about this part of Adobe's recent announcements. So now we move on to the other big news: Adobe announcing that the Flex SDK would become an Apache project and would go forward under non-Adobe governance. This took a lot of people by surprise, to put it mildly. First off, let me say that I don't have an issue with the idea of Flex going fully open-source. Yes, Flex was already "open-source", but we all know it really wasn't. You could view the code, but Adobe still exerted complete control over what changes were made. Anyone who ever tried to submit a patch or improvement can attest to this. Those restrictions are now gone. I firmly believe that if this announcement had been made at MAX, rather than in the middle of this PR breakdown, the cheering from the audience would have brought the roof down. I know a number of the people on the Spoon project, many of whom will probably be part of the group which will govern the ongoing work on the Flex SDK. They're all very bright people and I have little doubt that the SDK will actually see some nice benefits from this move. So from a purely technical standpoint, I think this can and probably will be a good thing. However, regardless of what you think about the SDK move, another portion of Adobe's announcement overshadowed even this news. In a post that will probably live in infamy, some of the Flex management stated "In the long-term, we believe HTML5 will be the best technology for enterprise application development." How Adobe failed to predict the resulting uproar I have no idea. But apparently they didn't. As a result, we saw an explosion of questions and concerns that essentially boiled down to: Is Adobe saying Flex is dead? I'll admit I wondered this myself. Given this statement, what was I supposed to tell the clients to whom I've evangalized Flex? Is my investment in Flex now ashes? I was angry and confused. Then I tried to detach myself from my emotional reaction and consider the situation objectively. I want to share a few of my thoughts and conclusions about this. First, one has to consider the harsh reality that Adobe never really figured out how to make any money on Flex. Their only real revenue came from Flash Builder, and it seems highly unlikely to me that sales of FB offset the money they've spent on Flex. And even that revenue is further reduced by the presence of competing tools like FlashDevelop and IntelliJ IDEA. Considered in this light, Adobe's decision to reduce the amount of resources it dedicates to Flex does make some sense, even if we don't necessarily like it. Offloading part of that cost onto the community is one way they can try to make those numbers even out. Next, I'm not sure about everyone else, but I for one always believed that eventually we'd be able to build Flex-like apps in HTML. Some of this can be done already, but it is disjointed, using a mishmash of libraries, and painful. Building RIAs in JavaScript is agonizing compared to Flex and AS3. But that's slowly changing as the tools get better and the libraries become more refined and standardized. My guess is that in two or three years we'll start seeing real parity with Flex on both features and tooling. I knew this before Adobe's announcement, so does it really change much? Or did the announcement, as poorly as it was delivered, serve as a stark reminder that Flex is in some ways a bridge between now and this eventual HTML-based future? I think this may be where some of the pain is coming from. No one wants to be told that the platform they're heavily invested in is probably going to be supplanted in the coming years. But can anyone really look at the current situation and draw another conclusion? Adobe seems to have two options here: keep pouring resources into Flex and delay the switchover a bit, or start changing direction and begin the task of improving HTML tooling from a RIA perspective. It's clear which way they've chosen to go. So where does that leave us? Like many folks, I poked around the web last week just to get an idea of the current state of HTML RIA development. It wasn't pretty. I found dozens of libraries, frameworks, UI components, tools, and workarounds to mimic proper OO features in JavaScript. To put it bluntly, it's total chaos. We're a long way from being able to drop Flex and start building enterprise RIAs in HTML. Which is fine with me. The projects I'm currently involved in are multi-year efforts built with Flex, and these aren't going away. I'll be building and maintaining apps with Flex for quite a while. On the other hand, the writing seems to be on the wall. This isn't going to last forever. Developers who have been around the block a few times know it is always a bad idea to put all of your eggs in one basket. So I'll be keeping my eye on the HTML RIA space, trying things out as that platform coalesces. GWT looks interesting, especially paired with Groovy and SmartGWT. So does brunch.io. Trying out new technologies is one of the things I love about programming, and that's certainly not about to stop. Will this change on the horizon amount to a career and knowledge "reset"? Is everything we've worked so hard to learn going to be thrown out the window? From my point of view, absolutely not. Looking around at the HTML/JS world, I see a lot of people trying to solve problems that we've already gone through. Solid OO design? Rich client models? Real-time messaging? Persistent client state? Separation of UI from client-side logic? Large-scale event-driven applications? Architecting and managing huge RIA codebases? Sound familiar? They should, because they're probably problems you've already dealt with a number of times. The programming language might change, and the UI component APIs may shift, but these fundamental problems aren't going anywhere. And I think experienced Flex developers are going to be very well suited to helping businesses and clients solve those problems, both now and in the future. Even if the platform eventually shifts to HTML5. As they say, the only constant is change. And honestly, life would be pretty boring any other way.

BlazeDS and LCDS RPC Call Ordering

Wed, 14 Sep 2011 09:11:00 -0700

I'm working on a project that is performing "real-time saving" of data in a Flex UI. In other words, if they do something in the UI, that change is saved to the database automatically, rather than waiting until the user presses a save button. One concern we had was what happens if multiple requests are sent to the server, and for whatever reason some take longer to complete than others? i.e. you send RequestA then RequestB, and RequestA takes 10 seconds but RequestB takes 1 second. Which would mean the database would end up being wrong, with the data from RequestA being the last version saved. How can we make sure that the final state persisted in the database is actually the current state, and not the last request that happened to complete? A number of options were thrown on the table, including implementing a client and/or server-side queue, or building logic to verify that the current state in the client matches the persisted state. While mulling this over, one of my colleagues noticed an interesting line in the LCDS documentation:

Channels also impose an order to the flow of messages sent to the server and the order of corresponding responses. Order is important to ensure that interactions between the client and server occur in a consistent, predictable fashion.

It's rather vague, but we read that to say "even though you think your calls to the channel are asynchronous, they actually aren't." Which, even though it is not what I thought was going on at all, would mean that the problem I mentioned earlier actually isn't a problem at all. Tom Jordahl was kind enough to respond to an email and discuss this. I then ran a number of tests locally to confirm the behavior. It turns out that calls to Messaging Channels are totally asynchronous, but calls by the same client to the same RPC Channel are synchronous. Which means if you send RequestA then RequestB, they will be processed in that order and the results will come back in that order. Regardless of how long either of them take to complete. You can still run asynchronous RPC calls from the same client, but they would have to call different Channels. So the option is there if you need it. I wanted to blog this because I've been using remoting for a long time and never knew this. In fact, I always assumed the opposite was true. So, this is a big deal for two reasons: if you need to ensure the order of your RPC calls, you can. And conversely, if you think your RPC calls to the same Channel are running asynchronously, they actually are not! And this applies whether you're using a Java back end with BlazeDS/LCDS, or using ColdFusion with its BlazeDS integration.

Swiz 2.0 Beta, Now with AOP!

Tue, 06 Sep 2011 13:11:00 -0700

In case you missed it, the Swiz team has made Swiz 2.0 Beta available. It includes the much-anticipated Aspect-Oriented Programming (AOP) features that have been in the works for a long time. AOP is incredibly powerful, and having done a lot of work with Spring, ColdSpring, and Spring.NET, it is hard to overstate the potential impact of AOP for Flash. I also want to give a shout out to Maxim Porges, who spearheaded the effort to bring true bytecode generation to Flash with his Loom project. Without his effort this just wouldn't be happening. For now, you can find full details on the new AOP features in the Swiz blog! As things get more stable, you can expect the Swiz documentation to incorporate this as well.

Spark Skins, Components, and Presentation Models

Thu, 14 Jul 2011 12:37:00 -0700

In the Flex 3.x world, I adopted the Presentation Model pattern and applied it just about everywhere. Separating the non-view logic made perfect sense, far better than the code-behind approach, and cleaned up the view components wonderfully. Then Spark came along in Flex 4, and things have changed. The framework now has built-in support for separating the "view" (skin) from the "controller" (host component). As I've been using skinning more and more, I've come to wonder if or how the presentation model approach applies in the Spark skin world. To try and answer that question, I created a fairly simple but non-trivial test application that creates the same views and behavior in three ways. I've heard each of these three ways mentioned at various times by various people, so I used them as the most commonly proposed options:

Supply a presentation model to both the skin and the host component, and let it act as a bridge between the two. In other words, the skin knows nothing about the host component, and the host component knows nothing about the skin. Create the PM as a self-contained set of methods and properties that can be applied to any relevant skin or host component. In essence, if the skin is the "view" and the component is the "controller", the PM is the "model" in this mini-MVC configuration.
Supply a presentation model to only the host component, and have the host component push state into the skin. In this case, the skin knows nothing about the host component, but the host component it tightly coupled to the skin.
Drop the presentation model approach completely. All behavior and properties are held in the host component, and the skin binds to host properties and invokes methods on the host. In this setup, the host knows nothing about the skin, but the skin is tightly coupled to the host.

After building all of these, there are pros and cons to each approach. And some definitely seem to have more pros or more cons than others. The one thing I tend to focus on is what kind of change and what kind of reuse each approach allows for. If you view the running test application, you'll see I've noted some thoughts on each in the sidebar. View source is also enabled, so if you want to look through the code or download it, feel free. I'm very interested to hear other people's thoughts on this as well. So if you have an opinion on this, or any issues with how I've built any of these versions, by all means please comment below!

Swiz Console 1.2, and an introduction to AOP in ActionScript

Wed, 06 Jul 2011 10:35:00 -0700

First just a quick note that I have updated the Swiz Console to version 1.2, which maintains parity with Swiz version 1.2. This update adds a tab to show views that have been processed with ViewAdded and ViewRemoved. As always, you can grab the swc or the source at my GitHub repository. In other news, Chris Scott put up a blog entry on the Swiz site with an overview of aspect-oriented programming in AS3. One might speculate that this is a lead-in to some very cool stuff coming in the Swiz framework, if one were so inclined...;-)

Swiz 1.2 Is Out!

Tue, 14 Jun 2011 14:11:00 -0700

Just a very quick entry to say that the Swiz Team has pushed version 1.2.0 out the door! This has a few small tweaks and bug fixes, but also adds the ViewAdded and ViewRemoved metadata tags to support the use of the View Mediator pattern. We also did a bit of consolidation related to conditional compilation. We still have two versions, but one is now just for the Flex 4.x SDK (including the 4.5 Mobile SDK), and the other just for the Flex 3.x SDK. Get it while it's hot!

Swiz Screencast, with Swiz Console and Sourcemate 3.0 Integration

Mon, 13 Jun 2011 08:27:00 -0700

I put together a 30 minute screencast on creating a simple Flex application using the Swiz framework. This also shows off some of the great Swiz integration that comes with Sourcemate 3.0, as well as using the Swiz Console for debugging and runtime introspection. If folks find this helpful, I'll try to do some more. So please let me know what you think! Thanks.

Fix for Using Subclipse Keyboard Shortcuts

Wed, 08 Jun 2011 12:38:00 -0700

Just a note for anyone who uses Subclipse within Eclipse to work with a Subversion repository. In the past, you could easily assign keyboard shortcuts within Eclipse for SVN update, commit, etc. In the newer builds of Eclipse I couldn't get this to work. After searching Google, I found the answer in this Subclipse ticket. In order to get the shortcuts to work, you must go to Window > Customize Perspective, then under the Command Groups Availability tab, check the SVN option. It may require a restart of Eclipse, but the Subclipse keyboard shortcuts will now work.

My cf.Objective() Dependency Injection Presentation

Thu, 19 May 2011 12:47:00 -0700

Just a quick note that I've uploaded the Dependency Injection presentation which I gave at cf.Objective(). Feel free to let me know what you think! Thanks.

Trog Bar Outlook Add-On

Tue, 10 May 2011 07:49:00 -0700

I recently installed a pretty cool add on for Microsoft Outlook called Trog Bar. Not only does it offer some nice features that Outlook alone doesn't have, but it wraps a nice task management system as well. To the left you can see what Trog Bar looks like. It docks to the edge of the screen, and can be set to autohide if desired. Across the top are quick links to mail, calendar, task list, contacts, compose, and send/receive. The calendar is great for the simple reason that you can specify more than one calendar to show events for. The fact that the Outlook To-Do bar would only show events from one calendar always drove me crazy. I have a personal account and a work account that uses Exchange, and Outlook will only show one. People have been asking for this simple feature for years. It's great to see someone add this. The main area is your task list. You can quickly search, view all tasks, view complete tasks, incomplete tasks, etc. If you use Outlook's categories option, you can also assign categories to tasks and view the list by category. Last but not least is a view called Task Sense. Trog Bar has some nice algorithms that populate this list automatically to show the most likely tasks to do at the current time. More on this in a moment. (And no, the tasks shown here aren't my tasks, I grabbed this screen shot off of the product page. Feed mammoth??) The notepad lets you quickly type in new tasks and store them as "unprocessed". It's very easy to fire off tasks into this application (as it should be). When you have more time, you can click on the Unprocessed Tasks link to show the tasks that still need "processing". If that sounds annoying or time consuming, don't worry, it isn't. Processing new tasks is really easy. You just click the task to open the task editor (see below). For a task to be processed, you have to enter in a due date and ideally one or more Categories (think Tags) and Projects (a parent task containing multiple child tasks). This takes about 10 seconds, and then you save it. That's it. The way Trog Bar works is largely based on the Due Date you specify. It is smart enough to treat the Due Date as both a target date as well as an indicator of the urgency of the task. So you are free to treat it as a sort of strength indicator if you choose.
The Task Sense list seems largely based on this "urgency value". In other words, if you set the Due Date for two weeks later, it isn't that "worried" about you actually doing it on that date (though you can, of course). Instead, this is an indicator that the task is probably of medium-ish priority, and it places it in the Task Sense list accordingly. Three weeks out, lower priority. One week out, higher priority. You get the idea. It is also has some extra configuration options which, if you choose to set them up, make this list more accurate. For example, you can define a category as an "80/20" category, meaning 80% result for 20% effort. In other words, biggest return on investment. Task Sense will rank these higher in your list. You can also set up an additional calendar containing high-level time blocks, like 8-5 M-F is Work, 6-12 is Home, etc. If tasks with a corresponding Work tag are created, Task Sense will weight them higher between 8 and 5, and Home tasks between 6 and 12. The point being that it builds up the Task Sense list in a fairly intelligent way. Anyway, I've been using it for a few weeks now and I really like it. First, it is a handy, souped-up version of the Outlook To-Do bar. Second, it is a rapid task entry and organization tool. And third, it does a pretty good job of predicting and showing you relevant tasks at the right time. The full version costs $35, and there is a free 30 day trial version available. To be clear, I'm not getting a free copy or anything, and am not affiliated in any way with the folks who make it. I just found it useful enough that it seemed worth a blog entry. ;-)

Swiz 1.1.0 Released

Thu, 05 May 2011 08:12:00 -0700

This is a few days late but maybe that is a good thing since several folks blogged and tweeted about it on Monday in case anyone missed it. The Swiz team has released version 1.1.0 of the framework. This is mainly a bug fix release, but we've also added a version of the swc that works with the Flex 4.5 Mobile SDK. The release notes have full details. So give Swiz a try with your new mobile apps and ask any questions or provide some feedback on the mailing list!