TypePad and SquareSpace

WordPress.com has started to tick me off this weekend. I’ve lost control over the widgets that appear in the left and right menus. I’m investigating alternative commercial blog hosting solutions. The top two contenders are TypePad and SquareSpace.

Both offer paid hosting with domain mapping for less than $15 per month. I’ve signed up for the two week free trials on both sites. I’ve exported my WP blog, spent a couple of hours with StAX to clean up the output, and have successfully imported everything into both TP and SS. In both cases, I need to perform some manual tuning to get things the way I like them.

Quick summary of my thoughts so far:

  • TypePad annoyed me a little by asking for my credit card number up front, whereas SquaredSpace doesn’t require it until I’ve made a commitment to join.
  • For my needs, TypePad is much less expensive ($8 versus $14).
  • TypePad is straightforward to use, but a bit painful. I need to mass-delete all 200+ of the custom “categories” it imported from WP and it requires a two-click process for each. Additionally, things are not quite laid out cleanly on the management side. Tabs within tabs kind of thing.
  • SquareSpace takes a radically different — and better — approach to content management. It threw me for a loop at first, but it’s great once I got a handle on its metaphors. Switching to SS from Blogger, WP, or TP is a bit like switching to a Mac from a PC. It’s a new, scary, and aggrevating environment until you understand it, then it’s obvious and elegant.
  • TypePad has an iPhone application already available. SquareSpace is still working on theirs.

XSL in Adobe AIR

Brian Riggs shows us how to perform client-side XSL/XSLT in an AIR application. Thanks to Brian for shining light on this, and thanks to Mike Chambers for sharing the link on Twitter today. Brian’s post is from May, so many of you may have already seen it.

The solution Brian outlines requires JavaScript because the only XSL toolkit AIR provides is inside of the WebKit HTML rendering engine. Consequently, AIR developers working with the Flash or Flex APIs will need to use an ActionScript-JavaScript bridge. Brian provides a nice code snippet showing how to create that bridge. Great, but still a kludge.

Unfortunately, XSL doesn’t seem to have made it into the Gumbo API for the next version of Flex and AIR. There is also no mention of XSL in Mike Chambers’ September post about AIR 1.5. I have not had an opportunity to pull down a recent nightly build of the Flex trunk to verify that the ActionScript API for AIR continues to lack XSL support, but all indications are that XSL is not present.

A little bit of Googling indicates that I am not alone in desiring XSL capabilities in AIR that do not require a bridge to JavaScript. I know that XSL is not like the hot stuff that Adobe like to tout in its products (OLAP only made it in because of its use in visualization), but it’s a real asset for enterprise developers.

I suspect that Adobe’s plan may be to leave out XSL—and a lot of other large-but-niche APIs—and let teams needing those capabilities include them with FlaCC, the upcoming C/C++ to Flash byte code compiler. (More info about FlaCC, including links to slides and a hi-res presentation video is available here). Specifically, for XSL, Xalan and Xerces could be imported. In truth, I find this to be an attractive solution, in part because I’m sure someone else will go through the hassle of compiling the popular C/C++ libraries to SWCs for me—I will only need drop those into my project.

However, if you are an AIR developer who cannot wait for FlaCC or want to see XSL make it into AIR’s officialy ActionScript API, consider submitting an enhancement request.

Flex 3 addChild() and initialize()

Okay, I’ve walked through all of the code in UIComponent and Container to work this out, so I’m going to share it: the sequence of operations when addChild(child) is invoked on a container and child extends UIComponent.

Since the primary use for this knowledge is managing the initialization portion of the component life cycle, I’ve highlighted the lines where your component may extend the behavior of UIComponent to perform its own operations.

The addChild() code bounces around through a lot of the Container class hierarchy, so I’ve included the class name with the method calls inside the parent’s instance so that you know where in the class hierarchy things get handled.

For simplicity, I skip showing the parameters to method calls and I don’t expand some operations (depicted by italicized text).

  1. Container.addChild()
    1. calls Container.addChildAt()
      1. removes child’s previous parent, if present
      2. calls Container.addingChild()
        1. calls UIComponent.addingChild()
          1. calls child.parentChanged()
          2. performs style setup on child
          3. calls child.stylesInitialized()
        2. invalidates size and display list of parent
      3. calls UIComponent.$addChildAt()
        1. calls Sprite.addChild()
      4. calls Container.childAdded()
        1. parent dispatches “childrenChanged”
        2. parent dispatches “childAdd”
        3. calls child.dispatchEvent()
          1. child dispatches “add”
        4. calls UIComponent.childAdded()
          1. calls child.initialize()
            1. dispatches “preinitialize”
            2. calls child.createChildren()
            3. calls child.childrenCreated()
              1. invalidates properties, size, and display list of child
            4. calls child.initializeAccessibility()
            5. calls child.initializationComplete()
              1. sets processedDescriptors = true
                1. dispatches “initialize”

There you have it: the order of operations when you invoke Container.addChild(). I hope this proves useful.