11.08.07

The DHTML runtime now supports rotation in Webkit

Posted on November 8th, 2007 in Development by Max

Thanks to Jim Grandy and http://www.cuppadev.co.uk/2007/10/31/rotating-openlaszlo-with-webkit/ for pointing out that webkit, aka Safari now supports rotation via CSS:
http://webkit.org/blog/130/css-transforms/

If you pull down a copy of trunk after build r7107, you can use setRotation() in DHTML as well as Flash. You must be running a recent webkit build.

Now, if only Firefox and IE would add support, we’d have one less Flash-only feature :)

10.17.07

Improved Bug Reporting

Posted on October 17th, 2007 in Development by benshine

If you are running on top of OpenLaszlo RingDing (aka 4.1.x, aka trunk), there is a new feature in the Debugger to help with bug reports. If you encounter a bug that prints a message in the debugger and you believe it is an OpenLaszlo bug, take the following steps to generate a bug report:

1. Enable Backtrace in the developer console
2. Provoke the error
3. Click on the debugger message to `inspect` it
4. Invoke `Debug.bugReport()` in the debugger
5. Copy and Paste the output into your bug report

The bug report gives details of the exact build of OpenLaszlo that you are reporting on, the detailed error message, backtrace, and the details of all objects involved.

09.25.07

Sun’s WADL, Google REST Describe and OpenLaszlo

Posted on September 25th, 2007 in General, Development, Community by Raju Bitter

A few months ago I read Marc Hadley’s article on the Web Application Description Language (WADL). I like the concept of describing REST web services in that way and envisioned a generator taking a the WADL and generating LZX classes connecting to the services described in the WADL document. It would even be possible to generate the corresponding server side for Java, Grails, Rails, Symfony, Cake and other frameworks.

I never found the time to get back to that idea, and this week I saw that there has been a lot of interesting development around WADL. WADL is now hosted at wadl.dev.java.net/ as part of the Glassfish project.. Thomas Steiner has been working since February on Automatic Multi Language Program Library Generation for REST APIs.

Since February 2007 I have started working on my Final Year Project whose (working) title is “Automatic Multi Language Program Library Generation for REST APIs”. This project was suggested by Patrick Chanezon, Checkout API Evangelist with Google Inc. The project’s main goal is to create a compiler which allows for automatic client code generation in various programming languages. This should be based on a meta description of a RESTful web service. After a first “market” survey of the available description languages, and having been in touch with Marc (thanks again), my choice for the meta description language will probably be Marc Hadley’s approach named WADL.

The project code page at code.google.com has some more information on the goals:

This project’s goal is to implement a compiler for meta descriptions of REST APIs. Currently the meta description language is Marc Hadley’s WADL (https://wadl.dev.java.net/). The compiler should be capable to automatically create client libraries in various programming languages based on the API meta description. It should be embedded into a Rich Web Application implemented with the Google Web Toolkit.

The first beta release was out in April, the current version number is 0.7.2. Here’s a screenshot of the REST Describe web interface:

Google Rest Describe interface

You can test run REST describe online, the project’s source code can be found at code.google.com/p/rest-api-code-gen/, there’s a YouTube video showing how the tool works and a page with a good documentation of the approach and functionality.

REST Describe and OpenLaszlo
As you probably can imagine I’d love to see an LZX generator for REST Desribe. As soon as Thomas is back from his parental leave - his daughter Lena was just born on Sept 22, all the best for you, your wife and your daughter - I’ll contact him to find out if he’s interested in working with us on LZX support for REST desribe. An to all our readers: if you’d like to work with us on such an LZX generator, please contact me. You’ll find the contact information in my blog at www.openlaszlonaut.de.

08.31.07

Reporting a bug — with guest blogger Maynard Demmon!

Posted on August 31st, 2007 in General, Development by benshine

Getting a bug fixed on an open source project can be a frustrating experience. Learning enough about the codebase to fix the bug yourself may not be something you have the time or expertise to do. To increase the odds that your bug will be addressed you want to make it as attractive to the developers as you can.

One of the best ways I’ve found to make a bug report attractive is to provide a clear and concise test case. In a GUI application this might be a sequence of steps to reproduce the bug. With a development platform like Laszlo a test case is the simplest piece of code that consistently demonstrates the bug.

The key words here are simple and consistent. The test case needs to be as simple as possible so the developer can quickly focus in on the problem and consistent so that the developer can be sure that their changes actually fix the bug. When providing a test case for in a Laszlo bug report you
should keep the following things in mind:

  • The test case should be a complete application. Included everything between the opening and closing <canvas> elements. A developer shouldn’t need to write additional code to get the test case to run.
  • Collapse the test case into the minimum number of files needed to reproduce the bug, ideally 1 file. This includes dependencies on assets such as fonts, resources, external datasets, etc. A developer doesn’t want to have to pull down and manage a bunch of different files from the bug tracking system.
  • Make sure any commentary provided in the test case is inside an XML comment tag. A developer shouldn’t have to snip out the relevant parts of the test case from a sea of commentary about the bug.
  • Simplify the test case as much as possible. Remove everything that is not needed so that the developer can focus in on what is not working.
  • If you can construct code that is very similar to your test case that does work correctly provide that in the test case as well. For example maybe a bug only shows up if you use a $once constraint but not with a $ constraint.
  • Provide precise details of the environment within which the bug occurs. This should contain the following:
    • The operating system.
    • The web browser name and version number.
    • For SWF the version of the flash player.
    • The version of the LPS used to compile the test case.
    • Any parameters used during compilation such as lzr=swf8, debug=true, etc.
    • The version of the java runtime the LPS was using.

Maynard Demmon is a Laszlo Systems developer. Maynard has filed some great bugs with the right amount of detail and easy test cases, making them a breeze to fix. See, for instance, LPP-4370, drawview doesn’t respect visibility

07.17.07

Community Reported Bugs!

Posted on July 17th, 2007 in General, Development, Community by benshine

The community developer base is getting busy! We’re seeing lots of bugs reported by the community — really good bugs, filed in the bug database with executable test cases, version information, browser information, and clear descriptions. Amazing and wonderful! Big kudos to Geoff Crawford, André Bargull, Robert Yeager, Srini Raja, and the rest of the bug contributors. Filing good bugs is the easiest way for you to contribute to the Open Laszlo development effort. We do actually fix community reported bugs, and we do take contributed bug fixes. Our upcoming release, 4.0.3, is almost entirely bug fixes, many of them reported by external developers. Keep those bug reports coming; you’re helping to improve the software.

07.10.07

OL4 documentation: current status

Posted on July 10th, 2007 in General, Documentation, Development, Community by jgrandy

Since John and I keep getting inquiries about changes made in the OL4 documentation, and many of you are likely to be using OL4 sooner or later, I thought I’d send out one message in the hopes of providing a single point of discussion.

We had four primary goals with the OL4 documentation:

  1. Support the ability to mark content that is runtime-specific. As you know, OL4 supports multiple runtimes (Flash and DHTML, more to come), and while the core OpenLaszlo APIs are the same across all runtimes, there are differences where we can support extra features or where we haven’t yet gotten to strict parity. The documentation must reflect this.
  2. Improve maintainability of the doc tools and the documentation. The OL3 toolchain was extremely proprietary, difficult to understand, and thus had suffered from poor maintenance. In addition, it was possible for the reference material to drift relative to what was implemented in the code, and there were other areas (such as the schema) where we were essentially inviting inconsistency. We decided that it was a very high priority to rebuild the doc tools around standard technologies wherever possible, in order to simplify maintenance, ensure accuracy and consistency, and to better invite participation from the community.
  3. Make it easier to accomplish several important goals: invite community participation in writing and maintaining the documentation, reuse the tools for other projects, localize the documentation, and maintain the live embedded examples.
  4. Produce a unified index across all the documentation.

With these goals in mind, we rebuilt the entire documentation tool chain around two technologies. The first is a homegrown tool called “js2doc” which uses the JavaScript parser in our compiler to extract precise information about the APIs actually found in the source, merges that information with annotations and comments, and generates documentation in an XML format. This tool, which I built, is based on the standard javadoc tool and uses (as much as practical) the same conventions used by javadoc.

The second technology is an open source standard called Docbook. This is currently the most widely adopted documentation standard on the market and is extensively integrated with documentation publishing systems of various kinds. (The OL3 documentation used Docbook, but only as an internal tool.)

Docbook uses a pipelined workflow. Essentially, content is produced in Docbook format, and then transformed by XSLT into any of a number of destination formats. The workflow is optimized for static generation of a traditional book (either a single PDF file or a conventional, static html document web), but before adopting Docbook we made sure that there were solutions available for more dynamic publishing styles. John and I wanted to make sure that multi-pane navigation from OL3 was possible, as well as full-text search and other nifty web publishing techniques found in the online documentation for other languages (e.g. Perl).

Docbook has a clean localization story, and is well itself well documented (there’s even an O’Reilly book for it!).

The reason I am writing this email is that John and I have found ourselves repeatedly explaining our decision to take an architecture-focused approach to this redesign rather than immediately providing all of the user-visible features from OL3. Our conclusion, based on years of interaction with the community, is that it is relatively easy to attract external contributors to the documentation — to write cookbooks, to localize, to edit, to improve the tools — *as long as* the barriers to entry are relatively low. By acting to simplify and normalize the doc toolchain, we open the door to much greater participation from the community. And by making it possible to reuse the tools for other projects, we further increase the potential for real support commitments. The tradeoff is that a few user-centered features are not implemented in the first version of the OL4 documentation, but we absolutely plan to provide those features in the future.

As you approach the OL4 documentation, you are likely to have the following questions, and we’d like to take the time to provide you with answers. Our purpose is to inform, and to open the door to broader input about priorities, not to shut down debate or questions.

Q. What happened to the left-side nav bar?
A. The simplest Docbook publishing mode is to generate a book-style html web, with a table of contents. Our plan from the beginning was to rely on existing doc publishing tools such as Apache Cocoon to provide more sophisticated navigation tools such as multi-frame navigation.
Q. What about search?
A. Search is not currently available within the new documentation. However, we have added a search box to http://www.openlaszlo.org/documentation that provides targeted search of documentation for a range of different OL versions, including OL4. Our current plan is that in-page search will arrive with adoption of a live publishing solution such as Apache Cocoon.
Q. Where is the class/tag index?
A. Due to a bug in the XSL tools for Docbook, automated construction of secondary indices increases the time for generation of the primary index from 8 minutes to 80 minutes. Until a fix is found for this bug, or a maintainable alternative is built — and a hand written class index is not maintainable — we have left this feature out of the documentation. But it is a goal to provide this index.
Q. Why not implement user comments like in the Perl documentation?
A. We like the idea of comments, but are also wary of the problem of staleness. (Stale info in comments is no more helpul than stale or incorrect info in documentation). You also get the problem that you have two virtual forums instead of one, which leads to confusion. We’re considering some kind of commenting mechanism whereby relevant forum topics would be listed within each documentation page. Philosophically, we think the right approach is to keep the docs current, rather than to have them stale and corrected in the comments. We’re looking to set up a process whereby the community can help us fix the documents themselves, not merely comment on them. We welcome input.
Q. Can I use the new toolchain for my own project?
A. Absolutely! The new toolchain is much more reusable than the old one.
Q. How can I get involved?
A. Email John Sundman (jsundman openlaszlo dot org) or myself (jgrandy at openlaszlo dot org) and we’ll get you involved.

07.01.07

A better rich text editor for Open Laszlo 4

Posted on July 1st, 2007 in General, Development by benshine

That headline got you interested, right? “Finally, they’ve implemented a better rich text editor!” Sorry, but no… we want you to implement a better rich text editor.

Open Laszlo 3.4 has a rich text editor, but it’s not very good. It’s inherently limited by Flash Player 7’s support for rich text, which seems to have been designed to display rich text, not to support interactive text format editing. With the DHTML runtime for Open Laszlo 4, we’re free of the constraints of the Flash player(s), and into a whole new frying pan: the constraints of the browsers. There are lots of other projects which work in that particular frying pan; in particular, other development efforts have already written javascript-based rich text editors. (TinyMCE from moxiecode comes to mind.) Some of these are free, open, and cross-browser-capable. Combine one of those with the Open Laszlo <html> tag, and we could finally have a good rich text editor in Open Laszlo.

This is a good place for a community contributor; could you integrate an existing DHTML rich text editor into the Open Laszlo 4 platform?

To do this, you’d have to learn some cool new tricks, which haven’t been documented much yet: the <switch> tag, the #pragma compiler hint mechanism, the runtime-specific compile-time constants, and probably some stuff we haven’t figured out how to do yet, like including a third-party library. You’d help us design and develop the platform support that developers will need to integrate a third-party javascript library, and you’d implement the first dhtml-specific extension. And you could choose which third-party editor to integrate.

Anybody interested? Write to me: ben at laszlosystems dot com.

05.29.07

OpenLaszlo 4 Programming Tutorial

Posted on May 29th, 2007 in General, Documentation, Development by jgrandy

OpenLaszlo architect and ultimate insider Adam Wolff has recorded a screencast version of his wonderful OpenLaszlo programming tutorial, available below. Besides being a tour de force of ‘vim’ text-editing acrobatics, this tutorial demonstrates construction of a simple client-server application in OpenLaszlo 4, and highlights several of the most exciting features of the OL4 release. The video is about 40 minutes long, and best viewed at full resolution. Enjoy!


Click To Play

05.10.07

Sun launches Project Orbit

Posted on May 10th, 2007 in General, Sightings, Announcements, Development by Max

The folks at Sun have been doing a tremendous job getting projects open sourced and released to the community. I’m pleased to announce that Project Orbit has been released by Sun, and is available here:
https://orbit.dev.java.net/

svn repository is here: https://orbit.dev.java.net/source/browse/orbit/

Project Orbit is another runtime for Laszlo that takes the DHTML runtime output and allows it to run in Java ME by emulating the browser DOM. From the main page: ‘Project Orbit is the Sun Java ME viewer of Laszlo content. It is a Java ME CDC/Personal Basis application that uses the Rhino engine to run LZX programming language Web 2.0 (AJAX style) applications.’

If you’d like to learn more, I’ll be speaking with Hinkmond Wong at JavaOne in San Francisco today at 4:10pm - sorry about the short notice!

There is a lot of low-hanging fruit here - integration with the OpenLaszlo developer’s console (a Java radio button), and tighter integration with the OpenLaszlo compiler come to mind. This is a community effort - Sun and OpenLaszlo are relying on folks to pitch in and help move the project forward. If you’re looking to contribute to a very cool, forward looking project, here’s your chance!

04.02.07

Guidance on OL4 adoption

Posted on April 2nd, 2007 in General, Development, Community by jgrandy

There have been several questions lately about whether to adopt OL4 for various projects, so we wrote up these informal guidelines.

There are currently three “official” releases of OpenLaszlo: 3.3.3, 3.4.0, and 4.0.0. The 3.3.3 release was the last 3.x release to receive a full qualification pass. 3.4.0 went out to support Webtop 1.0 and was only qualified for use with that Laszlo Systems product. 4.0.0 is the multi-runtime release developed under the code name “Legals.”

Our current recommendation is that in the short term, 3.3.3 is your best bet for deployment of production-quality OpenLaszlo applications. 3.3.3 was fully qualified at the time of release, it is stable, it’s characteristics are best known of any current release.

3.4.0 contains just one new production-ready feature — streaming Audio/Video, also available in 4.0 — so it would be a good choice only if you had a short-term need for that particular feature.

We only recommend 4.0 today if you are beginning a longer product cycle, because OL4 is no different from any other x.0.0 release — it contains big, exciting new features, but most likely has rough edges. Those rough edges will be polished off soon enough, at which point you absolutely will want to be on OL4.

(By the way, if you are actively working in 4.0, you might consider developing against the latest build from our 4.0.x development branch, http://svn.openlaszlo.org/openlaszlo/branches/4.0. It is from this branch that we will be releasing 4.0.1 and its successors. Currently, branches/4.0 contains perhaps a dozen fixes to problems that were reported against 4.0.0.)

As for the practical porting questions, OL4 on Flash is not bug-for-bug compatible with 3.x, so you will find some porting issues which will require code changes. Many of these are mentioned in the OL4 release notes (http://download.openlaszlo.org/4.0.0/release-notes.html), and others have been discussed in the mailing lists (http://www.openlaszlo.org/lists) and forum (http://forum.openlaszlo.org).

OL4 in DHTML is a somewhat different beast, since the dialects of JavaScript used in the various browsers are generally stricter than ActionScript. For example, null accesses are not rewarded with a token ‘null’ reply as in ActionScript, but rather cause the browser to abort the running script. However, OL4’s debugging support is noticeably better than 3.x’s, and tools like Firebug for FireFox are fantastic for debugging OL code and likely to get even better in the future.

Functionally, just about everything that was available in 3.3.3 is available in both DHTML and Flash in 4.0.0. This includes XML-RPC and drawview. A number of incubator components are not yet available (like the rich text editor, which we do intend to port). And we weren’t able to squeeze SOAP access in DHTML into our final release, but it will be coming soon. Again, more details are available in the release notes.

« Previous entries ·