Lambda the Ultimate

is a non-technical site, so don't be too harsh.

Thought this was going to the front page. Sorry. But maybe it's better hidden away...

I think you can look at a presentation about LZX from a Real media video stream there.

Thought you meant László Lovász for a moment. I mean he's good, but shit your pants? ;-)

For better or worse, I'm going to be seeing quite a lot of Laszlo over the next few months. In a spirit of damage limitation, I'd like to construct an alternative syntax for its UI description language that can be munged into XML at the last minute. (I have no more considered rationale for wanting to do this than a general conviction that XML Languages are teh suck. But I'm encouraged by the rumour that some MS people write their schemas in Relax NG's compact syntax, and then have them automatically converted into XSD).

It should be possible to describe a tree of nested visual elements succinctly without having to represent that tree with a set of nested tags (or S-expressions, or what have you). I really want to get away from the idea that the language's concrete syntax should directly mirror the structure of the "object model"; particularly because in any reasonably complex UI there are relationships between visual elements that are not parent-child relationships, and the more such relationships there are the more of a pain it is to have to go on pretending that everything's a tree. So my first requirement is that it should be possible to describe nested structures succinctly, but not mandatory to use a nested syntax to do so.

My second requirement is that the scripting for behaviours and animations should be extradited from the structural markup - in the XML language, you have embedded javascript all over the place, and I can see that becoming a serious headache to maintain. Some more systematic and sensible way of connecting the declarative and imperative parts of the language would be helpful - ASP.Net's "code-behind" comes to mind.

Does anyone have any pointers to examples of other attempts to do similar things?

But we had the same sort of issues as you point out in Laszlo, where the structure of the source code shadows the structure of the output (HTML in that case) and thus the programmer finds himself at odds between maintaining the structure of the output presentation and internal communication and procedural function of their program.

I agree with you that as an application gets to 'real-world' complexity, the original parent-child structure that may have seemed simple to begin with often becomes dwarfed by complex procedural interrelationships which are difficult to express in tree form. I have seen this happen before, and I have also wondered if there is a clean way to deal with it.

It's my impression that building the initial visual hierarchy of an application is only a small part of the life cycle of a program, and most of the work goes into maintenance and procedural coding to get the behaviors correct. So therefore I was actually not unhappy with the conventional procedural style like Java Swing where you declare your windows and other visual objects just like any other object, and add behaviors to them procedurally. It is verbose, yes, but you are not enslaved to the parent-child hierarchy, you can put your code whereever you want in your source files.

We have a couple of language artifacts and features that make things a little easier in terms of allowing different parts of the view hierarchy to reference each other: + You can name child views relative to their parents, and you can reference them with paths that are relative to the "classroot" of the class you are defining. So if you have a hierarchy like this, and one view wants to refer to a sibling, you can do it in a clean way:

<class name="myclass">
   <menu name="mymenu">
      <menuitem name="foo" ...>
      <menuitem name="bar" ...>
   </menu>
   <somewidget>
       <somechildwidget>
         <method name="blah">
            if (classroot.mymenu.foo.selected) ...;

Another feature is that many widgets communicate via events and constraints, so you can easily make non-local connections that way

I'll post more about that in another comment when I have time...

So you can reference sibling elements using a relative path. It helps clean things up a little..

Anybody knows the implementation language of Laszlo? I tried openlaszlo.org, but it seems to be down...

It seems people are interested in this thread, so I decided to promote it to the home page.

WithStyle is also worth a look. It's 100% SmallTalk and doesn't use flash.

I think the abstract here gives a better overview than the official site does.

"Laszlo applications are developed via a familiar object-oriented XML markup approach that reinforces todays development best practices"

Hilarious... the sad part is that are plenty of people that are so confused that will actually think that phrase makes sense.

Sure mixing code and ui design is definitly a wrong practice. Macromedia was doing that with ActionScript1, which you could be embedded into any entity (movieclip). Just trying to figure out the evaluation order was causing headaches... They're now moving away from it with ActionScript2 (à la Java : one file one class), but their compiler is still very very slow. In my company we're heavily using flash, and I ended up writing my own OO language with type inference and that can directly target SWF bytecode.

There is another Flash compiler that is being developped, that is quite interesting. It uses C# as the input syntax/language (you can use VS and intellisense for the coding).

http://blog.debreuil.com/archive/2004/08/18/376.aspx

I would expect language mavens to be most interested in the Laszlo's data binding, in the declarative syntax for specifying user interface states, and in the constraint mechanism.

Data binding is similar to (and inspired by) XSLT, except that it's a two-way binding and dynamically updates the UI when the data changes. You can click through the examples in the Data section of the explorer to see how it works.

The state tag allows you to specify mulitstate components, such as a window that sometimes contains a button and sometimes (perhaps orthogonally to this) contains some notification text. It moves a subset of UI programming that would otherwise be procedural into a declarative domain where it's easier to specify and to tool.

Constraints generalize the HTML syntax of <table width="50%">, so that you can embed an arbitrary JavaScript expression as the value of an attribute. The compiler generates code that registers the expression as an observer of its terms, in order to update the attribute value when the value of the expression changes. Beyond the obvious applications (in layout, and routing domain object values to the user interface), there's some surprising synergy between constraints and states. For example, the second-to-last example in the explorer contains a divider bar that drags horizontally when you click on it. This is implemented as a constraint within a state:
<state name="dragging">
<attribute name="x" value="${parent.getMouse('x')}"/>
</state>

This constrains the x value of the enclosing element (the divider bar) to the x value of the mouse position when the state is applied. The divider contains event handlers that apply the constraint when the mouse button is pressed and remove it when the mouse is released.

A real-world example would pin the values, and might have other features too. (In fact there is a more feature-rich dragging library in the framework, so you don't have to figure out to write this kind of thing just to write an app that implements dragging.) The point is that a simple user interface action such as this is simple to express, so you can experiment with UI behaviors without as much plumbing as some other languages require.

There are a lot of other features, such as the user interface component set, and the client and server integration, that the platform documentation covers because they're necessary for writing real-world applications, but I think that the features above, along with user-defined tags, are the main abstraction tools in the platform.