• SVG Viewer 2 – Github Source
• Code Lock 1.2 – Github Source

Both of these were plugins that looked mildly useful but would throw errors when used with the latest version of the IntelliJ Idea. The email address for the original author of the SVG Viewer’s was no longer valid so I just reversed the binaries and fixed it so you can now view SVGs within the IDE. (That plugin now works in pretty much all Intellij platformed products except AppCode which appears to not have the Batik library in the classpath by default; however, I was unable to figure out how to specify ‘everything except AppCode’ in the dependency section of the plugin.xml so I just left it as Intellij Idea only). As for Code Lock, the source was available and the author said he done with the plugin so I just patched it and posted it. The source for both plugins is available from my Github page. Hopefully others will get some use out of these.

One feature that I have missed is SyncEdit which works somewhat like the variable refactoring currently available in IntelliJ. However, where as the current refactoring functionality lets you operate on code variables that the editor recognizes, SyncEdit allows you to highlight a custom range within the editor and then change any word within that range while simultaneously updating any corresponding words that also exist within the selected region.

This feature was available as a plugin which was originally written by Nathan Brown but has not been updated in over six years and simply no longer works with the latest version of IntelliJ. I tried to contact him to get his original source code but I never heard back. Since there was no license on the code and it was published on the IntelliJ plugins site for free, I simply reversed the available plugin, got it working and re-posted it as an open source implementation in hopes that it can be used and improved. (UPDATE: Nathan contacted me and supplied me with his original source so I hope to update the 2.0 codebase soon with anything that I missed)

I have never written an IntelliJ plugin before and you need to understand some of the inner workings of their architecture to truly know what you are doing. However, I was able to get it up and running again and I even tweaked a few thing to get the plugin to select only words instead of subsets of words as the first version did since it seemed to cause more problems than it solved. I was able to find on a few other blogs with some tips on ways to implement SyncEdit and get whole word selection working better. The code certain needs some tweaks but it seems to work at least as well as the previous version and better yet, it is open for anyone else to help improve it.

See the image below for a better idea of how it works. You just highlight a range of code, then select a word and change it. Any other instances of that word will also be updated. It ends up being a more flexible method of find-and-replace. Yes, there are other ways to do this that already exist but I find this way to be very intuitive and easy to execute.

You can get the source code here from GitHub and the plugin file is here. The IntelliJ plugin page is here and is awaiting approval.

For those who are unfamiliar with Pipes, it is basically a way to create multiple PureMVC applications, each with its own core, so that they can be loaded and unloaded as modules within a main application or shell. It can get a little confusing and may appear to be overkill at first glance, but I think the end result proves to be worth the effort.

I posted the native version here. I also created a variation that uses the puremvc.define function to create a more clearly defined OO structure. I really like that approach better but the first version mimics the coding style found in the currently supported PureMVC Javascript implementation.

I also created a demo based on Tekool’s AS3 Pipes Demo:

• Demo [native version]
• Demo [puremvc.define version]

  *they are identical in appearance and behavior

If you are looking to learn more about Pipes, check out the following links which cover the conceptual use of Pipes, albeit in a Actionscript/Flex format.

• Tekool – Flex modules with PureMVC Pipes Simple Demo
• Joel Hooks – Piping the Machine
• Joshua Ostrom – Understanding PureMVC Pipes
• Jens Krause – A basic PureMVC MultiCore AS3 Example

(Update: I had to change the reference from Shell.js to Shelll.js because wordpress seems to think that any file named Shell.js is dangerous and blocks access to it which was breaking the demo. I updated both html pages with Shelll which points to Shelll.js to make it work)

Scalable systems however, require structure. Sure, you can build a scalable application using quick and dirty techniques, but you will be leaving out an overlooked and vital component: maintainability. If you are the only one who can figure out what the hell the code does, then what good is it? If no one can build upon the scaffolding you have provided, you can end up with a massive hotel with only one occupant.

There are a ton Javascript frameworks out there, but in the Flex world, my framework of choice was PureMVC. As far back as 2008-2009 PureMVC fans wanted to create an implementation using Javascript. Almost immediately they ran into the quandary of how to use it with their own libraries such as ExtJS, Prototype, Mootools, etc. Individual developer started porting it to their framework of choice, but this meant having multiple codebases to maintain instead of one. The decision was ultimately made to settle on a single native version that could used by everyone. At the time, I was working with what would eventually become Dojo 1.7, complete with AMD which was the “next big thing” to hit the Javascript world. I created my own port of PureMVC to work with Dojo 1.6 using AMD and I recently posted it here for anyone who needs it. In fact, I went one step further and created a Dojo version of the PureMVC Pipes utility as well. It is great to be able to load the PureMVC code on an as-needed basis with AMD.

However, Cliff is correct that in the long run, someone will have to keep that codebase in sync with any future PureMVC changes that come down the pipeline. So the best move is probably to utilize the native implementation of PureMVC and integrate it with the framework of your choosing. The issue then becomes: “How do I integrate it with ?”. Some developers have shown us the way for libraries like Prototype, ExtJS and others. However, there is not as much information on how to use PureMVC-JS native with Dojo, so I decided to post some examples on how to do it based on Cliff’s suggestions.

The first demo shows you how to create your implementation classes for Mediators, Proxies and Commands using PureMVCs “define style”, which means you use the puremvc.define function to create the OO structures that allows your MyMediator class to extend from Mediator in the PureMVC library. Only the main application and the view components are writing with Dojo. The argument for this way of integrating Dojo with PureMVC is that none of the PureMVC classes are reliant upon your framework and if you choose to switch from Dojo to something else, your PureMVC classes will required very few modifications. This makes sense, but I’m not sold on this entirely. First off, if you chance from Dojo to another framework, even if your PureMVC classes still work, the other 80% of your code will have to be changed. On top of that, while I like the clear and easy to use puremvc.define functionality, I would rather have all of my Dojo code look like Dojo code rather than have lots of code using puremvc.define while the rest uses Dojo’s define() function and style. Also, if you use the puremvc.define function, you have to make sure you load those classes up front and order them correctly. You get none of the beauty that AMD provides when it comes to loading what you need when you need it.

Run Demo 1

The second demo shows the same application but this time, the Mediators, Proxies and Commands are all built with Dojo and inherit from the classes defined in the PureMVC library. So I only have to load the puremvc.js file at the start of the application and my Mediators, Proxies, and Commands will all load when they are needed. Dojo will also include them in compressed layer file which is created by my build process prior to deployment so I get a clean seperation between the code I wrote and the code supplied by the PureMVC library.

Run Demo 2

The second method just feels better to me, but you decide for yourself: Here is a code-comparison of a controller class for each demo:

PureMVC define style:

puremvc.define({
        name: 'todomvc.controller.command.PrepModelCommand',
        parent: puremvc.SimpleCommand
    },

    // INSTANCE MEMBERS
    {
        /**
         * Register Proxies with the Model
         * @override
         */
        execute: function(notification) {
            this.facade.registerProxy(new todomvc.model.proxy.TodoProxy());
        }
    }
);

Dojo Style:

define(
    [
        "dojo/_base/declare",
        "todomvcdojo/model/proxy/TodoProxy"
    ],
    function(declare, TodoProxy) {

        var PrepModelCommand = declare("todomvc.controller.command.PrepModelCommand", puremvc.SimpleCommand, {
            /**
             * Register Proxies with the Model
             * @override
             */
            execute: function(notification) {
                this.facade.registerProxy(new TodoProxy());
            }
        });

        return PrepModelCommand;
    }
);

Both work fine but for now I’m sticking with the second approach.

I cannot say I was surprised by these announcements. Technology waves happen all the time and I have jumped to different platforms many times over the past two decades. In my PwC and IBM Consulting days, I worked in Lotus Notes and Domino until it became easier to build database driven web applications with Java Server Pages sprinkled with Javascript (soon to be Ajax) code. Then in 2003, I decided to jump again, this time to whatever could save me from the hacky nature of Javascript and pain of multi-browser support.

So I started looking at alternatives. Flash was an obvious choice but was still mainly for artistic designers looking to create static content. Open Laszlo initially won me over with it’s ease of use and low cost. At least until Macromedia jumped into the fray with Royale (which would ultimately become Adobe Flex a couple of years later) shortly afterward. It would take another year before Adobe would figure out that no one wanted to pay $15,000 per CPU for a server to generate SWF files, especially since that step is unnecessary to begin with. By the time Flex 2.0 came out, Adobe had wised up on how to monetize Flex and things really took off. Flex and the Flash Player had finally accomplished what Java Applets and the JVM set out to do but never achieved: provide a portable and consistent web-based platform for complex applications. I jumped on the Flex bandwagon and never looked back…until a little over a year ago.

That’s when it was becoming apparent that Steve Jobs was slowly being proven correct about the shortcomings of the mobile Flash experience. At the time, I did not feel they were wrong but they did not offer any real alternatives. They claimed HTML5 was the future but since no browsers fully implemented that specification (and still don’t), it seemed like a non-starter. The goal was still to write cool-looking, complex applications in a real programming language using a powerful IDE for a consistent runtime environment, and the Flex+Flash combination still seemed like the only offering that provided anything close to that.

However, the more I looked again at HTML and Javascript, I realized that the tooling had dramatically improved, especially with the emergence of two things: javascript libraries and browsers with debugging facilities. I knew those technologies had appeared years before, but it was their maturity that now caught my attention. Unlike some developers, I fully embrace the latest technology available to programmers. I’m a firm believer in IDE’s over a vi editor, debuggers over trace statements, and profiling tools over timestamps placed at the start and end of methods. It now seemed possible to create dynamic web apps that ran well in more than one browser, and the whole thing could be developed quickly without going blind from staring at alert dialogs with vague ‘blah is undefined’ javascript error messages. Don’t get me wrong, Javascript is still every bit as hacky as before, but jQuery, Dojo and ExtJS help shield you from much of that pain.

The real challenge will be to figure out how to create the same results in HTML5/Javascript that I was doing in Flex. Take drawing for example: the capabilities of SVG and the HTML5 Canvas fall short of what the Flash player can do when combined with Actionscript and Flex, but tools like EaselJS, Raphael, and JQuery SVG are avenues to get you part of the way there. Even Keith Peters is working on a book to help Flex developers make the transition that strongly mirrors his Actionscript version.

I honestly can say I’m surprised at how brief the Flex wave has been. I figured it would last 10 years, but it seems to be more like 6 if you figure that Flex 2.0 was released in 2006 and I expect a fairly strong decline by the end of 2012.

And no, Flex will not go away but it is reasonable to expect that the demand for it will. I will continue to use it where applicable, but over the past year or so, I’ve moved heavily into HTML5 and Javascript as well as Objective-C and the iOS platform. Seeing that the performance of HTML5 web applications running in mobile Safari is still a little slow for my tastes, native iOS applications have become very attractive. All of this partly explains the severe reduction in my blog posts over the past year or so, combined with the fact that I’m a father now and family time is very appealing these days.

So in summary, I’m still doing my best to create neat stuff, but these days it is with a different set of tools. Geoff Sterns sums up my thoughts exactly at the end of this post.

View Source

Any one have a better explanation?

One of the first things I hit was the term ‘elements’. What is an element? Is it the same thing as a child? Initially I concluded that elements where just another way of saying children (wrong). I figured that all elements where child components and vice versa. Then I noticed that some of the methods that I was expecting to find inside the new containers (as well as some of the existing ones) were missing. Where is getElements()? How do I find out how many elements I have? Can I just use getChildren() and treat the result like an IVisualElement (which itself was a mystery to me at the time).

So I started to really read the API docs, Flex source and blog postings about these topics. I also tried to decipher the slides shows that some bloggers posted about the great new features of Flex 4, but it turns out the slides do not make much sense if you do not have the audio of the presentation to go along with them.

Finally, I started to put together some very basic demos that would help me explore the new world of elements and help me figure out what I was really doing when it came to using the new Spark containers.

I’ll start by stating the questions I had at the time. Question number one was “How do I get the all the elements of a spark container?” I was expecting a getElements() method similar to the familiar getChildren() method from Flex 3. Instead, what you have are two properties: numElements and numChildren. To obtain all of the elements of a container, you can use a for-loop with the numElements count and call the getElementAt() method for each one. Pretty obvious after you realize there is no getElements convenience method. Question number two was: “what is the difference between an element and a child?”. Let’s look at the difference between elements and children….

An element is basically anything that implements the IVisualElement interface. A child is anything that extends from DisplayObject. When trying to determine if a component is an element or a child or both, remember that a UIComponent is a descendant of DisplayObject, so all UIComponents are DisplayObjects and therefore can be children. Also know that UIComponent implements IVisualElement so all UIComponents are considered ‘elements’. However, this does not mean that all DisplayObjects are elements. A DisplayObject that is parented by a container (ie, contained within that container) is a child of that container. But it is only an element of that container if it also implements IVisualElement. So when is a DisplayObject a child of a container and when is a DisplayObject an element of that container? Some examples showing different types of containers will answer this question.

In the first example, we look at the result when the container in question is an older Halo container (in this case, a Halo Panel). Because Panel is a descendant of DisplayObjectContainer, it has the addChild() method. In addition, because it descends from Container (which implements IVisualElementContainer), it also has the addElement() method. We will see that the Container’s implementation of the IVisualElementContainer interface is just a facade to the display list API but it is implemented here so that it will have the same methods that we find in the newer Spark containers that also implement IVisualElementContainer.

So we can add both children and elements to this container. However, we cannot add just any type of element to it. There is a difference between VisualElements and GraphicElements. VisualElements implement the IVisualElement interface, but GraphicElements implement an extension of IVisualElement called IGraphicElement which has some extra features that the container needs to know about. Therefore, some elements (such as the GraphicElement) cannot be added directly to the Halo Panel. The compiler will complain that it needs to be wrapped in a Group container first. More on why in a second….

The Panel in the following example contains several UIComponents including another Halo Panel, a Spark Panel, some Halo Buttons, some Spark Buttons and a SkinnableContainer with child components of its own. (Note that the components inside the SkinnableContainer will NOT be children of the Panel. They are children of the SkinnableContainer.) All of these components are DisplayObjects so they are all ‘children’. Clicking the ‘Show Children” button reveals as much. In addition, all of these components are UIComponents (which implements IVisualElement) so they are all ‘elements’ as well.

View Source

Now take a look at the next example. This time the container in question is a Spark Group. Like the Halo Panel in the previous example, Group is a descendant of DisplayObjectContainer so it has the addChild() method and because it implements IVisualElementContainer, we can add IVisualElements (‘elements’) to it as well using addElement(). The Group container can also handle GraphicElements such as a Rect (a Rectangle GraphicElement) which the Halo Panel could not. This is because, unlike the Halo Panel, the Group object knows how to display GraphicElements in an optimized manner. What does that mean? Read on…

GraphicElements require a little more involvement from their parent containers than do regular VisualElements. The key here is the IGraphicElement interface that GraphicElements implement. As I mentioned before, it is an extension of the IVisualElement interface (which is why GraphicElements can be added to the Group through the Group’s addElement() method). But GraphicElements are not DisplayObjects so they cannot be seen unless they get ‘drawn’ onto another DisplayObject by their parent. So if you add a Rectangle to a Group, the Group will also need to have a DisplayObject to draw the Rectangle on so it will show up in that Group. Just to optimize things a bit, the Group can actually reuse the same DisplayObject to draw multiple GraphicElements when possible. The container can use any DisplayObject that implements ISharedDisplayObject to draw the GraphicElement. In the first example, the Halo Panel could not do this so it could not draw GraphicElements in this optimized manner. Thus, the compiler gave an error saying you have to wrap it in a container that can deal with this. The Group container can do this so GraphicElements can be added to a Group.

One other thing to note: while some GraphicElements will allow the Group parenting them to create a DisplayObject for that GraphicElement to be drawn in, others will create their own DisplayObjects to be drawn in, and this interface (IGraphicElement) allows the parent Group to manage that DisplayObject even though the parent Group did not create it.(ie to add the DisplayObject as a child so the IGraphicElement can be drawn into it).

So what does this mean? It means that in our next example, the number of children is not the same as the number of elements. This example uses the same set of components from the first example, but it adds 4 rectangles which are GraphicElements. The children are all IVisualElements. However, they are not all children. The rectangles are GraphicElements which do not descend from DisplayObject. BUT, the Group knows that it needs to add DisplayObjects so that the GraphicElements can be drawn inside the container. The rectangles are different sizes and rotations so the Group decided to add two new DisplayObjects to draw the four rectangles on. Pretty cool, huh?

View Source

Now look at example 3. Instead of a Group, we are using a SkinnableContainer. The SkinnableContainer has the same set of components as the previous example. But, the SkinnableContainer uses a Skin for its visual representation and that Skin is the first and only child of the SkinnableContainer. The SkinnableContainer’s default Skin class is comprised of a Rectangle (for the border) and a Group called the ContentGroup which all skins for containers need so Flex know where to add children to the container.

So this example illustrates the fact that, while the SkinnableContainer has 10 elements, it only has one child: the Skin of the SkinnableContainer. In turn, that skin has only one child: the ContentGroup Group component. You may be asking “why are there not 2 children of the Skin: one being the ContentGroup and the other being the DisplayObject for the Rectangle (serving as the border) to be drawn in? The answer is because the Skin class descends from the Group class and Groups will add DisplayObjects when necessary to draw any GraphicElements they contain. In this case, no new DisplayObjects were required. The Skin class just drew the Rect GraphicElement directly onto itself. It can do this because the Skin’s ancestor, the Group class, also implements ISharedDisplayObject which means that it can serve as a shared DisplayObject used to draw GraphicElements when necessary. So the Skin manages the DisplayObjects used to render the GraphicElement, and the in this case, the DisplayObject it is using to draw on is itself! If you added other Rectangles to a custom skin and assigned that to the SkinnableContainer, the Skin might decide it needed more DisplayObjects to draw those other Rectangles and you would therefore see more children in the Skin’s child list.

One other thing to note is that the number of elements stays the same when you look at the element list for the SkinnableContainer, its Skin, and the Skin’s ContentGroup. If you look at the source for SkinnableContainer, you will see that it determines the numElements value by getting the corresponding numElements value from the currentContentGroup so basically it is just re-routing you to its content group when you query for elements. Likewise, the Skin of the SkinnableContainer does something similar. It extends from Group, which gets the numElements property from its internal mxmlContent property which is an array of visual content children for this Group. Both of these are analogous to the RawChildren property of the Panel container which you used to get ALL the children of the Panel rather than just the children that you added to the Panel which came from the getChildren() method.

View Source

After reading all of this, it may not seem any clearer than when you started. You basically have to familiarize yourself with the inheritance hierarchy and relationship between 7 different classes/interfaces:

1. DisplayObject
2. UIComponent
3. Container,
4. IVisualElement,
5. IGraphicElement,
6. IVisualElementContainer
7. ISharedDisplayObject

Once you know who these fit together, you’ll soon understand the difference between elements and children. I’m sure I’ve messed up some of the facts and gotten a few things wrong so feel free to put corrections in the comments section if you think I’m way off base on any of this.

UPDATE: Check out these links for more information on this and related topics:

• Article on the Gumbo DOM Tree API (this is full of great detail on this topic)
• Nice example on the the difference between the owner and parent of a component. Very nice.