And Now An Example That Works

Alright then, updating to Actionscript 3 the example linked in the previous post which was Actionscript 2, we get something that works, like this...

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp(event)">
    <mx:Script>
    <![CDATA[
             import flash.events.Event;
             import flash.events.MouseEvent;
             import mx.containers.Panel;
             import mx.controls.Alert;
             import mx.controls.Button;
             import mx.controls.Label;
             import mx.controls.TextInput;

             public var submit_button:Button = null;
             public var first_text:TextInput = null;

             public function initApp(event:Event):void {
                 var panel:Panel = new Panel();
                 panel.title = "Hello World";
                 addChild(panel);

                 var label:Label = new Label();
                 label.text = "First Name";
                 panel.addChild(label);

                 first_text = new TextInput();
                 first_text.text = "Patrick";
                 panel.addChild(first_text);

                 submit_button = new Button();
                 submit_button.label = "Submit";
                 panel.addChild(submit_button);

                 submit_button.addEventListener(MouseEvent.MOUSE_UP, onMouseUp);
             }

             public function onMouseUp(event:MouseEvent):void {
                 Alert.show("Hello " + first_text.text + "!", "Message");
             }
       ]]>
    </mx:Script>
</mx:Application> 

If you have the free Flex 2 SDK you can compile and run it like this...

$ mxmlc something_else.mxml
Loading configuration file /home/patrick/flex2/frameworks/flex-config.xml
/home/patrick/dev/patrick.logan/flashstuff/formstuff/something_else.swf (143036 bytes)
$ flashplayer something_else.swf 

Another Flex Tip

I got another promising tip from Garrett Hart here inside Liberty Mutual...

He sent along this Adobe documentation on "Dynamically Creating User Interface Components". Here we go...

Em, hold off on this one. The code as it is in the article seems to be for ActionScript 2 rather than ActionScript 3. There were substantial changes in the display object class hierarchy.

Back to the drawing board, but the Vista Smalltalk swf example is still a good indicator.

Update

The url Garrett refers to in the comments is this one. Blogger kind of mangled it.

Vista Smalltalk for Flash

A hat tip to Patrick Mueller in the comments of my most recent post on starting up with Flex.

I'd not been paying much attention to Vista Smalltalk. Very nice. And Peter Fisk seems to be using the controls from mx.controls that I had problems with. Now to dig into his code to figure out what if any magic lies behind his Lisp or if I was simply missing something.

Either way, good news. The blogs come through.

My RIA Is Dynamic -pause- Naught

Update: It's been a while but there are some corrections to this post.

• The Flex API *does* support drawing on pixmaps so a MacPaint-like capability using this would be efficient.
• All the controls can be created using the Flex 2 API fr ActionScript 3. There is just a minimal mxml wrapper required around the AS code. I can dig it out here if anyone wants to see it, but I'm too lazy at the moment.

End

I've been playing with Flex2 (I'd go all out with Apollo except it does not run on Linux yet and I don't have steady access to Windows XP or Mac OSX). I have some questions that I've posted to some lists, but maybe this blog can attract some feedback as well.

No Pixmaps?

First some general impressions: Flex could be so good, but I am not sure if it is. The basic display architecture is reasonably what I'd expect. I am kind of surprised there isn't a pixmap level drawing capability. (Or is there and I missed it?)

I created a simple paint program that frequently cycles through colors, transparency, and line width. After a minute of "painting" the retained structured graphics system bogs down and mouse events are handled fewer and farther between.

No Intelligent Redisplay?

Which leads to my next question: even if all graphics have to be retained as heavyweight objects, does the repaint really have to slow down mouse handling so dramatically, so soon? If my program is adding a new line just a few pixels long, shouldn't the damage and repaint occur in a small rectangle around that line? I cannot tell what's going on in the slowdown to be sure.

Since I have not found in the API any smart damage capability (e.g. "invalidate just this region for repainting") and only a display-wide "invalidate" then I might assume the entire display list is being repainted unnecessarily. Since the API does have a reasonable hit detection capability then I would expect that to be used to determine what to repaint, if the system had some understanding of where the damage is.

Controls Must Be Precompiled?

I would really like to generate some UI controls (e.g. labels and input controls) based on some data received from somewhere in the course of the application. I wrote a little app to try this out. Then I ran into an error at runtime when trying to add a label to a vbox... "TypeError: Error #1006: getInstance is not a function."

Apparently all the controls in mx.controls can *only* be created through XML and the Flex mxmlc compiler. Actually this is not strictly true since the -keep switch will keep around the generated ActionScript files. Em, not the most beautiful or concise code considering the app consists of a window, a vbox to stack controls, and one static text control.

All kinds of craps are generated that have *nothing* to do with the app. This can also be seen in the runtime behavior of the XML version of this simple thing. While the few small Flex apps I have written to date come up and are ready very quickly, the XML generated app comes up slowly. Looking at the code it is apparently due to all kinds of initialization of things the app will never use.

Ugh - factories initializing craps - a very heavyweight stretch of code. Generated from XML input run through a compiler. (Apparently in spite of ActionScript having reasonable support for XML *in* the language, mxml code can only be generated from a compiler written in Java that runs at build-time. (Or on a "server" if you want to call out to one that can run the compiler for you!)

The result is "rich" but not very "interactive" -- especially given the heritage of ActionScript as a dynamic language. ActionScript, Flex, and such appear to be based in the developers Java heritage. The result is a Java-ization of what used to be a dynamic browser environment into a fairly static Java webstart/applet-like environment.

So given that mxml generates AS code and I can duplicate that, then to some degree this code could be hand-written and be data-driven at runtime (i.e. be done via a "gui interpreter" of data just like a browser interprets HTML). I am going to look into this some more. The code is readable if not concise. It only needs to be done once.

I'd love to find out Flex provides an easy-to-program, dynamic GUI/graphics capability. Almost the opposite appears to be case so far. Several companies are apparently building apps like word processors for Apollo. They have to be doing some fairly low-level and efficient stuff with the text layout and redisplay. I wonder what level of the API they are using and how much code they've had to write themselves.

I could be missing wide swaths of the API that just isn't covered in the typical documentation aimed at building static GUIs in an IDE via XML.

Gambit / Termite / Erlang

Dominique Boucher compares Erlang with Gambit Scheme, and in particular Termite, which is an Erlang-like system the runs on Gambit. His conclusion...

I would choose Erlang over Gambit-C+Termite for the development of a new scalable and robust distributed application. That being said, Gambit-C is a nice piece of software (in fact my preferred Scheme system), it has a great debugger, and the Scheme Now! project will certainly lead to a number of good portable libraries for Scheme. But from the perspective of an industrial developer, Erlang wins easily.

I would have to go along with this conclusion for almost any system that might have to be "production-ready" in the next couple two, three years. On the other hand I think Gambit Scheme is the better investment for the long haul. Erlang is a great language, and OTP is a solid framework for distributed systems. But Scheme is the better "foundation" language and Gambit has all the qualities of Erlang to become a solid foundation for all kinds of distributed systems, even an Erlang system, as exhibited by ETOS (Erlang-to-Scheme).

And In The Darkness Bind Them

secretgeek is a bit more tongue in cheek about this than the Church would recommend...

Lisp is so simple that you can implement it in any language in just a few pages of code. This might never happen though, because once you've learnt lisp you'd never want to write anything in any language other than lisp, so you wouldn't bother implementing lisp in any language other than lisp.

Lisp can be fully implemented in lisp in just a handful of lines. I just implemented lisp in lisp, fully, while i was hopping onto a bus and paying for my bus ticket all at the same time...

Only lispers have a true definition of fun.