• Home
• Platform
• Download
• Documentation
• Community
• Wiki
• Blog

From OpenLaszlo

Contents 1 Overview 2 Demo 2.1 Demo Requirements 2.2 Milestones 2.2.1 Primitives 2.2.2 Scripting 2.2.3 Data Binding 2.2.4 Performance Measurement 2.2.5 Server Communication 2.2.6 Components 2.2.7 Weather implementation 2.2.8 Fine Tuning 2.2.9 Demoable Deployment 2.2.10 Compiler 3 Scoping 4 Productization 4.1 Compiler 4.2 Runtime Library 4.3 Optional Tasks 5 Feature Checklist

Overview

The purpose of the evaluation is to investigate the implementation of every Laszlo feature in an alternate runtime, in order to uncover any issues that would make the implementation of an alternate runtime implementation infeasible, and in order to scope the effort that it would take to do this.

The evaluation is broken into two phases. The first phase is an implementation of the Weather demo, in an alternate runtime. The goal of this phase is to investigate the implementation of Laszlo runtime features, within a context with (relatively) instant gratification and within a compelling end result.

The second phase is a more comprehensive prototype of features that the demo doesn't cover. The investigation of these features is necessary to achieve confidence that the project can succeed, and to scope the amount of effort.

This evaluation plan is independent of the particular runtime technology. Some notes about how to implement this for DHTML are collected at DHTML Laszlo.

Demo

The plan is to implement the Weather application. The Weather application will be fully functional and will look and behave the same as the Flash-runtime version on the Laszlo site.

This phase does not require changes to the Laszlo compiler, and it does not including compiling the existing weather source code to the targeted runtime. The implementation plan is to implement libraries and to write code in the language of the target platform, whose APIs and structure matches the Laszlo platform well enough that a compiler can in principle compile a Laszlo source program to the handwritten target code that is produced as a result of this effort.

Demo Requirements

The following features make for a compelling demo, and touch a reasonable sampling of the LPS platform features that make implementation in another runtime challenging.

• Animation
• Components
• Interactivity
• Layout
• Web services

These would be nice, but they're not necessary for an initial evaluation:

• Exercise every feature of the Laszlo platform
• Compile existing LZX source code to the target
• Use the existing LFC code
• Produce the target code automatically

The major untouched features are constraints and states.

Milestones

Primitives

Develop test cases that demonstrate each the LPS platform features, aside from script integration, data binding, and server integration, that are necessary for the demo.

View 

Implement a simple rectangle with a user-specified size and color.

Static image 

Implement views with each of the image types that is used in the Weather application.

Reusable resource 

Define a swf resource such that it can be used in multiple views or view instances

Static text field 

Static text field that can change its text in response to script.

Editable text field 

Implement a text field that responds to typing.

Click handling 

Implement a view that responds to a click event.

clickable="false" 

Implement a view that responds to a click event over its unclickable subviews.

mouse hover 

Implement a view that responds to mouseover and mouseout events.

nested views 

Implement a view that contains another (unclipped) view.

layout 

Lay out multiple views according to their sizes.

clipping 

Clip a view's children to the bounding box of the view.

fonts 

Display text using a TrueType font.

animation 

Animate an attribute value over a defined range, with ease-in and ease-out, in response to an event (as opposed to on load).

coordinate system 

Some graphics systems use the math quadrant. Laszlo uses the document quadrant. Fix the Laszlo layer to flip this. Test with nested views, text, and images.

Scripting

Develop test cases that demonstrate the manipulation of the node tree from script.

Script globals 

Figure out how to store global script objects and access them from event handlers.

Script manipulation of views 

Change the size and position properties of a view from script.

The View proto that was implemented as a framework for writing some of the test cases above does this.

script instantiation 

Instantiate a view from script. This is necessary in order to implement several of the features below.

class definition 

Define a class that can be instantiated multiple times. This is necessary for the fields of the forecast.

resource definition 

Name a resource that can be referred to by its string name. Weather doesn't have any resources that are used multiple times.

Data Binding

Develop test cases that demonstrate binding the content of a presentation node to the content of an XML data node.

bind view fields 

Bind the values of node fields to the attribute values and text content of an XML node.

recursive binding 

Bind the fields of a child relative to the data context of the parent. For the demo, we can write shape-specific code to parse one level of the dataset.

data replication 

Iterate through the XML contained in an XMLInline, and create a view for each matching element.

dataset definition 

Name a data set that can be referred to by its string name. For the demo, we can use a single global dataset

Performance Measurement

These need to happen within the eval timeframe in order to verify that the runtime is fast enough. These are not necessary for the demo proper.

ECMAScript timings 

Time loops, method call, object creation, array put, array get. Compare these to Flash 6 timings.

Evaluate graphics performance 

Implement a view that contains a large number of bitmap and vector assets, and drag it around in front of another such view. See how this compares with the Flash player performance. A subjective evaluation is fine.

Evaluate startup time 

Test the application startup time with a near-empty script, and with a script that contains a huge amount of ECMAScript (on the order of the LFC and/or a Laszlo application).

Server Communication

Develop test cases that demonstrate communication with the server.

Dynamic image 

Request an image with a computer URL from the server, and display it.

Request URL from server 

Send a request for a dynamically constructed URL to the server, and use a cgi script to verify that it got there. The dynamic image request above gives me enough confidence that this works. The extra testing infrastructure isn't necessary.

Request XML from server 

Request an XML dataset from a CGI script on the server. Extract an attribute value into a text field, in order to verify that the response was returned and that we can access its content from script.

Media request 

Components

Develop standalone implementations of the components and effects that are used in the Weather application.

text edit 

Simulate an editable text field using key events.

Implement zip code entry field 

Convert the images, write a container for the image, label, and text entry, and set it to animate away when the button is pressed.

Transcode server-side weather assets 

I don't know what format the weather server uses for the dynamic data. If any of these are GIFs, it will be necessary to convert them to PNGs on the server, and to manipulate the URIs in the data response.

Implement view transition 

Transition from the entry screen to the results screen.

Tab slider 

Implement enough of the tab slider to use in the weather application. I don't know what is involved here — maybe it's just a matter of hooking up the animation and clipping features which are implemented in the Primitives milestone, in which case the low estimate is correct.

Weather implementation

Implement the views of the Weather application, and integrate them into a single application. At the completion of this milestone, an application with the approximately correct appearance and behavior exists. It may be "off" in minor ways regarding pixel placement and some of the non-essential features and buttons.

Current conditions" view 

Implement this for a fixed set of data.

"Radar map" view 

Implement this for a fixed set of data.

Single Forecast item 

Implement this for a fixed set of data.

"Forecast" view 

Implement this for a fixed set of data.

Bind views to XML 

For each of the above, except for the rows of the "Forecast" view.

Bind forecast items to XML 

This involves hooking code from the data replication test case up to the "single forecast item" implemented above.

Integrate views into tab slider 

Integrate the components above into a single view controlled by a tab slider. This may involve some refactoring of the test case implementations and possibly some compiler work in order to make the result readable and testable.

End-to-end integration 

Integrate the components so that entering a zip code sends a server request, and transitions to a tabbable results view. This should be straightforward, but I'm leaving time for integration bugs.

Fine Tuning

Tune up the application to match the appearance of the LZX version.

Align with window 

Fix the application so it lines up with the edges of the window. Might come for free once I've fixed the coordinate system transform, above.

Add top line 

Add the graphics for the top line. Clicking on zipcode goes back to start

Enter key 

Make the Enter key the same as the Okay button.

Pixel-align views and text 

Restrict the clickable area 

Easter egg 

Add something to show that this isn't just a Flash application.

Demoable Deployment

Set the application up so that it can be demoed by anyone with a web connection.

Embed within an HTML page 

Write the HTML that embeds the application, deploy it from a server, fix any relative URLs, and fix whatever issues come up from this.

Compiler

Create the output files from XML source, so that the source can be edited during a demo.

Scoping

The purpose of the test cases is to investigate the basic issues necessary for an implementation of the Laszlo platform.

Review LZX reference pages 

Systematically review the LZX reference pages, and verify that each tag, class, event, method, and attribute is represented by one of the tasks below.

opacity ; Make sure semi-opaque views work as implemented and are draggable.

prototype wrapping text :

prototype states :

read the image size 

snippets 

loading status 

Splash 

dynamic requests for vector art 

Productization

This is past the evaluation, but it seems like a good place to put this. This is what it would take to take the above work and turn it into a product-quality platform implementation.

Compiler

These are the tasks that have a significant compiler component. Most of these include LFC work too.

Compile classes 

Compile instances 

Font definitions 

Resource definitions 

Resource attributes 

Constraints 

Dynamic libraries 

Runtime Library

LFC 

multi-state buttons 

Coordinate transforms 

implement x, y, xoffset, yoffset, rotation, xscale, yscale, scale; getMouse and relative positions

Fonts 

Text alignment 

Movie play control 

Audio 

Browser integration 

Resizing views 

Stretching and resizing images 

XPath 

Port the XPath interpreter

Events 

Animation 

States 

pixel-align 

SOAP 

XMLRPC 

JavaDirect 

Button masks 

Image load error and timeout handling 

Dataset load error and timeout handling 

Optional Tasks

Debugger 

System drag and drop 

Feature Checklist

• image display
• audio playback
• video playback
• text layout
• input text
• color transforms
• animation
• data binding
• data requests
• media requests
• event handling
• mouse tracking
• input focus
• cursor management
• font management
• browser integration
• constraints
• extensible tags
• dynamic layouts
• attachable states
• clipping