Navigation

RSS 2.0 New Entries Syndication Feed Atom 0.3 New Entries Syndication Feed

Show blog menu v

 

General

Use it

Documentation

Support

Sibling projects

RIFE powered

Valid XHTML 1.0 Transitional

Valid CSS!

Blogs : Latest entries

 Next page >
Laszlo 3.0b2 released, a step in the right direction
A new version of Laszlo has just been released.

It contains a number of important feature additions that make the platform a lot more viable (compared against 2.2.1):
  • Serverless Deployment
    You can now choose to deploy Laszlo applications without a proxy server. Before, all data request went through a J2EE servlet application that proxied this with the actual destination. By removing the proxy, Laszlo applications become standalone Flash applications and they can thus be deployed in environments where resources are scarce or where no servlet container is available. There's a limitation on the available futures, but for most applications this should not be a problem (no persistent connections, SOAP or XML-RPC).

  • Dynamic libraries
    Parts of your application can now be included dynamically at runtime. This can be important if you have a huge application and only want to let the users download the features they actually use. You also have the option of letting them download a small initial part first and delay the download of the libraries until idle time in the application, making everything available much quicker and not forcing a large initial download. I can see this also being important if you plan on actually generating parts of the application at runtime instead of just providing data. Since the LZX compiler takes a while to compile the source to Flash, just loading your generated part dynamically should make it possible to investigate this model further.

  • Drawing API
    LZX now includes a subset of the WHAT-WG graphics API, this allows you to perform drawing operations at runtime. I can see this particularly being important for generating graphs and charts according to real-time data. Instead of having to dynamically generate static images on the server, you should now be able to keep all this functionality right into Laszlo.

  • Unicode support
    It's now finally possible to develop internationalized applications with Laszlo! This is both available for the text that you write in the application itself, as for the text that is entered in text widgets. The communication with a server is now also performed in UTF-8.

The detailed release notes are here and here.

I tried it out with an application that I developed for version 2.2.1, and I found a number of problems:
  • The generated Flash will be targeted at Flash Player 6 and I noticed that my previous animations (which were exported for version 5) make every browser crash when included in the Laszlo application. The workaround seems to be to re-export them, targeted at Flash version 6.

  • There is still no support for a multi-line text edit field that shows a scrollbar when the text exceeds the visible area!

  • There's a bug when sending internationalized data as a HTTP POST request through the proxy server, the text seems to be re-encoded by the proxy as ISO-8859-1. This doesn't happen when the application runs in un-proxied mode.

  • The font metrics seem to be wrong. When using accented characters, the cursor gets positioned wrongly in a text field and the rendering makes characters re-position randomly. Also, the dimensions for ASCII text seem to be wrongly calculated since text wraps even though there's enough available space and when displaying a single line, the parts of the characters underneath the baseline are trimmed.

I have to say that I'm impressed by the dedication of the Laszlo people. After my previous posts, I got contacted directly by Adam Wolff, the director or Laszlo Systems. He's really devoted to try finding out how to reduce the gripes people have with Laszlo and to lower the adoption barrier. Also, I managed to get hold of a 3.0b2 version early by peeking around where I was not supposed to look and I mailed him about the problems I encountered. He immediately forwarded my mail to three developers, asking to investigate! It's good to see that they are so actively and dynamically supporting users.
posted by Geert Bevin in Laszlo on Mar 16, 2005 8:45 AM : 0 comments [permalink]
 
Don't lose data when your session times out

I'm posting this as a reply to the following blog post and more particularly the following line.

"Your server-side session has expired, and your work is gone."

The RIFE framework has solved this many years ago. We have something similar as actions, but we call them elements. Elements are components that talk together through a site structure. That site structure is not limited to be two-dimensional, you can layer many site structures on top of each-other with child triggers that make the engine jump to the underlying layer.

If a request arrives that is intended for a lower layer, and the conditions for the upper layer's child triggers aren't present, the initial request state is serialized and preserved. You can perform a flow of any kind of complexity in the upper layer, the serialized state will be automatically passed around. As soon as the trigger to go to the underlying layer occurs, the original request state is de-serialized and the element for who the original request was intended receives the data you sent initially.

We call this behavioural inheritance and implemented authentication with it. So when your user session times out, you don't go beyond the authentication site structure where you can identify yourself. As soon as you have successfully identified, a child event is triggered and you go to the lower layer that receives the data you posted when the session timed out.

If you want to try this out do the following:

  • go to the demo installation of our Bamboo forum, which has been written in RIFE
  • identify as the admin or as the moderator (you can also register if you prefer)
  • go to a topic
  • start a reply
  • clear your cookies
  • fill in the form fields
  • send the data
  • fill in your credentials in the authentication form
  • the post should have gone through as if nothing happened

This is one of many areas where a powerful framework can help you. Many frameworks merely structure well know approaches and practices in a personal fashion. They don't offer many new solutions to complex problems. Be sure to evaluate which framework you choose for a project thoroughly, there might be lesser known alternatives that maybe offer ready-made solutions to many of the problems that you will be facing.

posted by Geert Bevin in RIFE on Mar 15, 2005 12:06 PM : 0 comments [permalink]
 
The monolithic Laszlo application
Following up on my previous post about Laszlo, I wanted to mention something else that annoys me a lot during development.

In Laszlo you typically develop one monolithic application that is loaded once and communicates with a server in the background. This is very similar to a regular desktop application. However, for development this is a major annoyance since for each change you have to manually go through the whole application and find the functionality that you just changed. This can suck up a lot of time if you like working in an iterative fashion and like to test every small change before moving on.

This is inherent to the whole architectural design and other solutions do not have this.

For example:
  • Plain HTML applications
    Just reload the page and you're fine.

  • Ajax applications
    You typically split them up in bookmarkable pages and the time spent going to the changed location after a reload, is much shorter.

  • Swing applications
    This is probably the nicest of them all, you can hot-swap the classes and test out your change immediately.

  • Java applets
    If you run them in the applet viewer, you can use hot-swap as well.

I know you can pass query parameters to the Laszlo application and according to that perform certain logic. However, if you want to rely on this to make development more comfortable, you'll have to actually change your application to detect the query parameters and manually develop a way jump to distinct locations. This is still of very limited use though, since you haven't preserved anything of your previous application state. So in most cases you'll just have to build up the state manually anyway.

I'll continue to report on my experience with Laszlo as I progress.

(General note, I'm talking about Laszlo in specific since that's what I'm trying out at the moment, many of the problems are probably going to be experienced with Flex also. However, I'm not evaluating Flex.)
posted by Geert Bevin in Laszlo on Mar 11, 2005 8:43 AM : 4 comments [permalink]
 
Wasting a lot of time with Laszlo

A month and a half ago I started doing a small project in my off hours which just had enough functionalities to cover a bit of ground in Laszlo. I had been longing for a good excuse to try out this RIA (Rich Internet Application) technology for quite a while, so I took the chance when it presented itself. This was supposed to take only a couple of days of development and I even though I had never used Laszlo before, I was quite confident that after my experience with GUI technologies like DHTML, Swing, QT and Gtk I would be able to get started with Laszlo very quickly. This was also partly based on the collection of documentation that is to be found on the Laszlo website and on the amazing demo applications that you can try out there.

The thing that bothered me most initially, was the lack of tool support. Even though there's an Eclipse plugin that allows for quick testing, writing the application lacks all of the wonderful IDE features that I have grown used to when doing Java development. Anyway, I knew I just had to get over that and put it behind me.

After that, I began to be (and still am) horribly annoyed by the time it takes to recompile LZX pages (Laszlo's language). I mean I have a dual 2,5 GHz PowerMac G5 with 2GB of RAM and I have to frequently wait for more than 30 seconds to be able to check if what I wrote, works as intended. Now this is already bad, but it gets worse since most of the times it never works as you intended the first time off. The combination of bugs, vaguely documented features, abstract examples and crippled features (like the stripped down version of Javascript and very basic XPath support) forces you often to try out everything three or four times before you get the behaviour you want.

But wait, the ordeal is not over yet, I can accept that software has bugs, but this is the end-of-line release (2.2.1) of a production version of a product that sold for $20.000 in licensing before. You expect it to be rock-solid.

However I bumped into bugs and missing features like these:

  • there's no multi-line text editing component that displays a scrollbar
    I had to implement this myself by collecting bits and pieces from the forum and the Laszlo sources.

  • HTTP POST requests are crippled
    Sometimes, and for no apparent reason, the last character of your values are stripped off, you thus have to send most things as GET requests.

  • databound items can't be reset after editing
    You bind a field to text of an XML document, it's quite often that you want to allow people to cancel their edit and show the original values again. There's no support for this, you have to figure out and code a system for it yourself.

  • drag & drop is not natively supported
    You have to start tracking mouse events yourself and compare the location with objects on the canvas, nothing like drop targets or drag sources are to be found.

  • performance drops quickly
    Don't expect to be able to just code a little app and not worry about performance when using Laszlo, you'll have to start managing early, late and deferred instantiation and work with things like item pooling and replication. If you want fast startup time, you'll have to use their Krank optimizer which increases the size of your deployed application considerably and requires you to change your code to work correctly after the optimization process.

These are just the ones I remember most vividly, I encountered many others.

Sadly, even if all these issues are solved there's still one major problem that will not go away because it's part of the whole architectural design. You build a fully functional client-side tier that interacts with a server-side tier for persistent data storage, centralized logic, etc etc. Normally, you would let the client-side act as a controller and a view: the controller sends a certain message to the server, which interpretes it, returns the result and the client-side renders a view of the new state. While this model is technically sound, it's totally not user-friendly. The slight delays (200ms-900ms) that are experienced by network latency and all the processing, makes the application feel slow and very displeasant to use.

The only way to make it usable, is to write the same logic in the client-side tier as in the server-side tier. So, you update your view early according to the operation that needs to be performed, send the message to the server, perform the operation for real in the correct tier, send back the result, and instead of rendering the result you check if it is what you expect.

This forces you to write code twice, performing the same operation in two different tiers, in two different technologies, each with their problems, gotchas, etc etc ... needless to say that your productivity drops dramatically. I don't even dare to think about having to maintain changes to the application either, gradually updating things on both fronts ... eeek!

It's a shame, I really had huge expectations about Laszlo and even tried to sell it to a customer. I'm glad that project was cancelled or I would be in deep trouble.

posted by Geert Bevin in Laszlo on Mar 8, 2005 6:10 PM : 43 comments [permalink]
 
Work on Elephant is going well

JR Boyens is advancing well with Elephant, our blog application written in RIFE.

In fact, I dropped my blog at http://uwyn.com/blog and setup the latest Elephant snapshot on http://rifers.org/blogs. Several other RIFE developers and users have registered too and will start blogging on there also.

I hope this is the start of a thriving blogging community :-).

posted by Geert Bevin in RIFE on Mar 8, 2005 10:05 AM : 1 comment [permalink]
 

 Next page >
 
 
 
Google
rifers.org web