News: A Laszlo Persistent Connection Tutorial
The Laszlo Presentation System (LPS) was open-sourced early this month. I've been playing with it for a while, and put together a simple tutorial showing how to use the Persistent Connection to implement a server push application.
- Posted by: Jack Hung
- Posted on: October 24 2004 11:37 EDT
After playing with LPS for a while, I kind of enjoy working with it. It is easy to decouple the Web UI form the back-end logic.
In the tutorial, I have been able to build and test the UI without writing an back-end code. Then I a few modification to an existing J2EE application (powered by OFBiz) to push data to the UI application.
I just wanted to share my experience, and congratulations to the guys as Laszlo.
You may find the tutorial here.
- performance by Rob DeMilio on October 26 2004 11:41 EDT
- How many people use Lazlo? by Kris Ko on October 26 2004 17:19 EDT
- Re: How many people use Lazlo? by Thad Smith on October 26 2004 18:20 EDT
- MVC concept with Laszlo by Jack Hung on October 26 2004 23:30 EDT
- MVC concept with Laszlo by Kris Ko on October 27 2004 01:24 EDT
- Laszlo and web MVC frameworks by john hume on December 07 2004 02:55 EST
- How many people use Lazlo? by Jack Hung on October 27 2004 23:46 EDT
- All I see here is hybrid applet technology by Kevin Citron on October 27 2004 10:58 EDT
- Back-end servlet code for peristent connection example? by Thomas Markel on January 25 2005 09:55 EST
Do you have any idea about the performance of persistant connections in Laszlo? Their documentation states that persistant connections are not production ready yet.
I posted a message to their developer forums asking why they made that comment in their documentation but never got any definite feedback.
p.s. Thanks for the tutorial, I have handed it off to the developer that will be writing that piece for my application. Can't wait for your next tutorial that you mentioned.
I recently happened to come across Lazlo and I think it is a great framework from a Java Developer's perspective. Kudos to the Lazlo team for developing this product and opening it to the Java community. Unfortunately I found no documentation as to how Lazlo would fit with frameworks like Struts. Does it fit with an exiting Struts framework and if so can someone post pointers or provide some information.
I asked the same question when I first started looking at Laszlo (which was only a few weeks ago). The short answer is that you really can't think of a Laszlo application (or any RUI apps) in terms of traditional webapps.
Frameworks like Struts handle the flow of an application on the server, while technologies like Laszlo push that logic to the client. Instead of the constant click-refresh of a html webapp, data is only sent to the server when needed. The client decides how to paint itself at each instance instead of the server making that decision.
One advantage that html webapps gives is that each page is a seperate entity, so you compartmentalize your views. An rui app might be seen as more complex than a single web page but you get more compelling applications and less data being sent back and forth b/w the client and the server). A better way to think about Laszlo is that it's a GUI framework like Swing except for the web.
BTW...You're original question was how many people use Lazslo. I can't exactly answer that, but everything points to technologies like Laszlo ruling the web in the next few years. Bruce Eckel and many others have been talking about it over the last few months.
I'm still feeling my way around with LPS (Laszlo Presentation System), but I'll try to offer my opinion.
First you might want to take a look at the Laszlo architecture document - http://www.laszlosystems.com/lps-2.2/docs/guide/architecture.html#d0e381
In LPS, the lzx file is represented as an application. It handle the presentation of models, UI logic and user interaction all on the client. So the MVC in LPS look like this:
Model --> dataset
View --> Laszlo components
Controller --> Laszlo Event System
Server Application --> don't quite fit herem, may be in a seperate picture
Here are the points you should kept in mind:
* Data are bound to components via datasets
* The UI logic is cut down to a minimum
* User interactions are handle by declarative handlers
* Your server application handles the business logic
If you have an existing Struts application and want to have a LPS interface, your Struts code aren't of any use :(
What you gain with LPS is that your server-side code will be simplier (not sure how much yet), without having to concern with keeking session information, mapping model to view and page flow control. And it sounds like is will fit well with SOA.
I'm sort of lucky in that my existing application is based on OFBiz and utilized their Service Engine. It is a sort of Service Oriented Programming (SOP? seems like nobody used that term anymore). I tried building a few client UIs and it takes very little effort on part of the server application.
I think the LPS has opened up an alternative approach to RIA, but than some issues left to be addressed (providing an end-to-end development framework). And I think by open its source will is the right step forward.
Thanks for the info. I am under the impression that Lazlo is aimed at Java Developers. Correct me if I am wrong. It provides a means for a Java Developers to create some rich UIs. However lot of us are working with existing frameworks. I believe it would attract lot more Java developers if it could be used with existing frameworks like Struts, Tiles etc. Basically I want to use the existing Model and Controller, but the View to be provided by Lazlo. Someone on Lazlo forums suggested mixing Lazlo and struts is doable, but havent found any good documentation with regard to the same.
Complaining about the total lack of reuse of strus classes? Use WebWork.
Lazslo is great. Its hard for folks like me, that have always developed for browsers, to understand this new paradigm that has no refreshs and pages ... so beautiful.
In terms of using Laszlo as the front end to a Struts application, Flex faces the same issue, communication with the remote systems. The article Providing a Flex Front End to Your Struts Applications (http://www.macromedia.com/devnet/flex/articles/struts.html) discusses the issue and offers two approaches:
The two approaches correspond to the two different ways a Flex application communicates with remote systems:
* Using the traditional HTTP request/response mechanism
* Using SOAP to invoke methods on remote services
My suggestion to people trying to integrate RIA app servers such as Flex and Laszlo with Struts is don't do it. I have been working with Flex for about 5 months have found out what works and what does not. Products like Flex have their own MVC architecture within them. Do you really need to maintain two MVC frameworks? Probably not. Unless you have a specific need to integrate Struts directly with an RIA then avoid this. Utilize the RIA client for what it was intended to do. This is definitely a mind-shift in thinking for traditional Struts-like developers where the page request/response paradigm has been hammered into our heads. Struts will not be the only consideration you have to think about when using an RIA. Our goal was to use Flex+Spring+Hibernate. After you get over the initial hurdles it should go smooth. It will take a while to get familiar with this type of technology and integration is the biggest issue IMHO.
Furthermore, this referenced article is regarding Flex 1.0. Flex 1.5 removes the SOAP protocol for remote objects and uses the AMF gateway (binary protocol similar to Flash remoting). I reject this article (http://www.macromedia.com/devnet/flex/articles/struts.html) and consider it bad architecture. Don't mix these technologies directly because it duplicates efforts in the presentation layer. Do we need two co-existing MVC frameworks? Just my two cents.
I can't see any downside to using struts or some other web mvc framework along with Laszlo. Many features of such frameworks (e.g., binding form controls to server data) wouldn't be applicable, but they're still an easy way to map URLs to code that interacts with the model, and if there's a need for a vanilla HTML interface, the same actions should be usable (though they'd need to be mapped to different views).
The laszlo UI will make an HTTP request (which is apparently proxied through the LPS based on the sequence diagram in the arch doc you link to, but either way ends up being forwarded to the URL specified in the LZX) so that the server ends up with a fairly plain-jane HTTP request. The request parameters can (and probably will) be the same that your traditional HTML forms submitted, so the server-side validation already in place is still appropriate.
All you need to make the response readable by Laszlo is a view that renders XML. A Servlet or JSP that simply generates XML based on request attributes would be a trivial, functional implementation. All the Laszlo UI needs to know is what XPath to use to look for error messages (which any good framework will always put in a standard location) and how success is indicated.
If you're using struts, here are example mappings for the same action that would be used to service the two flavors of client UI.
<!-- for HTML -->
<!-- for laszlo -->
Quoted from a blog by David Temkin, Laszlo's CTO and co-founder : http://www.richinternetapps.com/archives/000074.html
"I won't get into a feature comparison here, despite some clear inaccuracies above. But one defense for readers of this blog: Please consider that Laszlo has larger deployments by larger companies, and has been around longer. 'Nuff said."
Interesting stuff. But, all I see here is an applet, a hybrid language expressed via XML and a data driven designed applcation framework. Did I miss something.
Where is the back-end servlet code for the persistent connection example? Is the jsp simulating all the response data? It would be nice to see a back-end how you access the persistent connection.
I am trying to experiment on laszlo to use in my next project. For this project I am particularly interested about persistence connection, which is offered by LPS.
But all the documents say that, we should not try to use persistence connection in the production system, without proper explanation to the actual reason. If the persistence connection should not be deployed in the production, why did laszlo keep advising about the "Persistence connection" feature.
Do any of you know why persistence connections are problem?.
Any alternative technologies for pushing data from the server to client??.