OpenLaszlo a bag full of hurt? Tell me!

[rajubitter]

Some people have been complaining on Twitter that OpenLaszlo is a "bag full of hurt", once you get past the examples. I'd like to understand what the experience is like, maybe you'd like to provide some feedback.

I can imagine that much has to do with the state of the documentation, which seems to be falling behind more and more. At least the LZX syntax changes between releases are not as big as they were going 3.4 to 4.0 and for the versions with new SWF9 support.

Everyone else as well, if you start using OpenLaszlo with the current version, what are the greatest problems or areas of pain? What could be done to improve the situation?

Thanks in advance,

Raju

[stupiduser]

Hi rajubitter

i think the css in openlaszlo is not good if you compared it with css2
the css in openlaszlo feels like just an ordinary variable, we still need to insert "$style{'height'}" in every atribute, unlike the w3's css

that is just my stupid opinion

[rajubitter]

I agree with you, that was my first thought when I saw the OpenLaszlo CSS implementation as well.

Technically there's probably a good reason for it. I would suppose that it has to do with Flash8 support. At least based on my knowledge there was only very limited support for CSS styling in Flash8, but I'm no expert on that.

With Flex 2 and Flash CS3 things have changed for the Flash world: much better CSS support. But since OpenLaszlo in the current version still supports the SWF8/Flash8 runtime, the compiler can only built the support in the platform that will be supported across all runtimes.

Thanks for your feedback!

Raju

[falcor781]

I'm actually working on a complex endeavor -- a science tutoring system with interactive graphics. I've personally had to dig inside libraries to see what was going on to get much of my stuff working. I feel that, like most UI packages, it's quirky -- and in some cases quirkier than other languages due to replication and whatnot. For example, I've had inconsistent behavior with trees - my code works fine when I use a static tag whereas I get different behavior when using 'new', which makes zero sense to me.

The hardest thing in this language, I'd say, is the debugging aspect (1) because of some implicit assumptions on sequencing of events (2) challenges when working with bulkier XML structures that are dynamic in nature and (3) figuring out what's going on as your application becomes more interactive.

The constraint stuff and replication stuff has actually resulted in a smaller, cleaner code base though it's more "complicated" in nature since it requires more to understand what's going on.

.. The #1 thing that would help out most, in my opinion, (and hopefully this is happening) is if a few Laszlo developers kept tabs on a few larger projects and saw how those projects' developers were using their language and where the pitfalls were. It seems like there isn't a good communication loop between the users and creators.

[rajubitter]

Thank you for the valuable feedback! I really appreciate that.

The #1 thing: I think that's essential, to gather the feedback of users working on larger projects and send that back into the development loop.

When you list the areas where there's a lot of complexity in OpenLaszlo and LZX, I can only agree. Things like instantiation order, complex XML structures and updates to the XML files are not that comfortable.

Having to digg into the components, and the fact that there's a difference between static tags and objects generated at runtime is simply not acceptable - in my eyes. There are competing technologies where you definitely don't need look into component source code to get default behavior out of the components.

Would things be easier if you could code more directly in JavaScript, compared to using the tag based approach?

Best,
Raju

[bitwalker]

When I first started using Laszlo last year, it was pretty exasperating because I am mainly using it for audio visual stuff and in connection with a red5 streaming server. The documentation was not up to date and pretty scant. I had to get elbow deep in mediastream.lzx code to figure out what to do. I came across more than a few bugs and it became hard to know if I was just ignorant of how to do things, or if I had found a bug.

So yeah I was pretty down on things then, but if stage one is the examples and stage two is the bag of hurt, then stage three is much better. After I got my head around the declarative approach, fixed all the bugs I needed to (I stopped upgrading!) , and found where all the relevant documentation was, I have been able to do much more with laszlo and really enjoy working with it.. I like the power of replication , like constraints and delegates, being able to work with xml for the data. And I like the simplicity of the development environment ( a browser and text editor).

If I had some suggestions, I guess it would be to slow down on the release cycle, get the documentation and the demos all up to date. More example code would be nice too. (What happened to laszlocode.com ?) I get the feeling that some of the code in the documentation tries to show off how easy it is to do amazing looking stuff. But that really just hides what is going on behind the scenes and is not so useful once you actually have to do something real world.

[rarsa]

As a farily beginer user (but highly experienced developer), I haven't yet reached the bag of pain stage.

I just found that I couldn't find enough examples of "doing it the laszlo way".

Of course one can do the same thing in many different ways but knowing how the creators intended to be used always helps.

I also found that although there is documentation included, which is a big step compared to other projects, some times it is incomplete or missleading. e.g. documentation showing the methods, attributes and events of an object but without a description.

So for me it's been a lot of trial and error, which is OK as I'm a hobbist, but I don't know I could be able to charge that time back if I was doing a real project. Although this is quite clearly explained in the "What does "open source" mean to the OpenLaszlo user? (http://forum.openlaszlo.org/showthread.php?t=12997)" sticky post. People doing a real project can pay for professional support and that makes sense to me.

Could it be that people complaining are trying to do professional work without professional support?

Maybe in my case, as a hobbist, buying the book will help. Are people reading the book more successful than the people just trying by themselves?

[Markus]

I'll gladly add my comments here. OpenLaszlo is a bold endeavor imho and the chosen path of multi-runtime/single source is certainly not the easiest. So far the lzx structure of handlers, nodes, datasets, classes and events is one of the most eloquent ones I've used to date.

Firstly, and I cannot stress this enough, reading Laszlo in Action is compulsory to get a basic understanding of "how to laszlo". Even though it hasn't been fully updated to the new 4.3+ syntax it's a worthy read. The example for how to call a service is so important I was surprised there isn't a <service> tag to begin with. Perhaps I should propose my evolved service class for the incubator....

CSS support has been mentioned but it's a major one. I also do jQuery based HTML projects and the freedom real CSS gives me when styling is such a relief. If I were able to have a CSS structure where I could dictate styles based on elements with classes I'd be a lot better off. So for example myClass text { fgcolor: #FF0000; }. Perhaps it would be even better to use the actual css2 attributes like color, background-color, etc. Not having padding or borders on views also feels lacking. Margins can be done with constraints as I feel it should be. I know padding and border can be done with a custom class and extra views but these all costs resources. Something that would be unneeded in the DHTML runtime at least.

Quality and skinning of UI components. It takes quite a bit of tinkering with the internals of a component to restyle them. The base-component approach alleviates this but Laszlo beginners or junior developers might find it hard to come to grips with how this works. It can also become an issue when updating to a new Laszlo version.
I had this problem with the combobox. I copied the Laszlo combobox class as a base for my own. I modified the visual bits leaving the methods as they were. When the next version(s) of Laszlo came around there were bugs fixed in the combobox methods (good!) which meant I had to check them by hand and update them one by one. Not something you want to do every release. There is a relation with the CSS support. In Flex you'd use the stock components and make style changes with your own CSS and be done with it. I wouldn't mind having the Flex UI components on the OpenLaszlo core language... Currently the OpenLaszlo grid and datapicker feel like they are a little heavy and/or slow. Combobox can be replaced with datacombobox most of the time but it's still a tricky control when used with data-binding and late initialization.

Datanode, dataelement and datapointer. These are well described in the Laszlo in action book. It took me and other developers a little while to get comfortable with the fact we'd have a datapointer sometimes and data-elements another where both have their own methods to manipulate the node tree. A unified way to handle data(nodes) might be beneficial for new users. With experience the advantage of one over the other does become clear. I personally prefer to use datapointers 99% of the time. Just have to remember to destroy them.

Debugging is vital for a developer. I'm using a combination of the laszlo debugger, firebug and the safari developer tools to get my answers about why my code isn't doing what I expected. So far I've been able to figure out every problem we had. I can imagine that for new developers it's a bit tricky to come to grips with how to program event based and asynchronous. The debugger is likely a bit different then what they are used to adding to the confusion. If they didn't read the topic in the developer guide about debugging they will have a hard time getting started. People seem a bit lazy to read the available documentation (surprise!) which is not a fault of Laszlo.

One of the biggest problems I'm having is being stuck with an older version for some projects. The big syntax change between 4.0 and 4.3+ is quite a hurdle for existing projects. Porting won't always give a tangible (short term *sigh*) benefit to the customer. This means we'd have to pay for the porting ourselves making it a low priority for our management. I know this is just the way it is but I wanted to voice it anyway. It certainly makes it a lot more work for the developers.

Developing for SWF and switching to DHMTL (or going from swf8 to 9) means you might have to take different approaches in the core of your application. We've been using roundrects for quite a bit of styling in flash which are not very portably to DHTML. Font embedding is another but this is a general html problem and not something I'd point to Laszlo for. It's all doable but certainly not a matter of just switching the radio button from flash to dhtml. At least not yet. DHTML experiences and samples are still a bit sparse. Which is understandable considering how the DHTML runtime is still new and being actively developed.

It's not a "world of hurt" to develop with Openlaszlo. There is certainly room for improvement and there are some maturity issues with parts of the platform. Mostly components and CSS imho. Flex has the advantage of a huge user community. If a component is missing a community member will likely have made one (with varying levels of quality). Flex is however fuly bound to flash where Laszlo gives you more flexibility *IF* you can dedicate the time to dive (deep) into the subject matter. A lot of developers new to any RIA platform are just too lazy. Any shortcomings in a platform appear to be blown up to a huge scale because of it. Laszlo has shortcomings as does Flex and so do people themselves. It's always easier to complain then to contribute. I try to use the proper tool for the proper job with varying levels of success. Laszlo has it's place for service oriented web applications with rich user interaction. Your milage may vary.

[kmeixner]

Now before I say this, I'll say that overall I like OpenLaszlo. It has helped us do things that we found difficult or impossible to do with straight AJAX and with Flash Professional 8. Outside of OpenLaszlo forums I mostly give positive comments to people about OpenLaszlo. But since you asked I do think there is much room for improvement. I am still using OL 3.4.0 so please excuse me if some things are no longer applicable in 4.x:

A) Too many Syntax changes too fast:

"One of the biggest problems I'm having is being stuck with an older version for some projects. The big syntax change between 4.0 and 4.3+ is quite a hurdle for existing projects. Porting won't always give a tangible (short term *sigh*) benefit to the customer. This means we'd have to pay for the porting ourselves making it a low priority for our management"

-- I agree, my application is still in version 3.4:

- There was absolutely no benefit for me to port to version 4.0 since our application is dependent upon SWF format items that have no equivalent in DHTML, so porting to 4.0 would have just slowed down our application and costed us a lot of unpaid development time (since no customer was paying for this).
- The main reason I haven't ported to 4.2+ is all of the required syntax changes. We have a fairly stable application in version 3.4.0, I am concerned all the required syntax changes might result in bugs in our application. Once again no customer is paying us to rewrite our application to run in SWF9 since, aside from some speed improvement in theory, there are no new features available to our customer from the port.

Also, this hasn't affected me personally but I have seen lots of new users on forums that have been confused by out-of-date documentation and examples after OpenLaszlo 4.x was released, you might want to make sure the documentation and examples are kept up-to-date for the latest release.

B) Difficult to Debug Large Projects:

"Debugging is vital for a developer. I'm using a combination of the laszlo debugger, firebug and the safari developer tools to get my answers about why my code isn't doing what I expected. So far I've been able to figure out every problem we had. I can imagine that for new developers it's a bit tricky to come to grips with how to program event based and asynchronous."

-- I agree, events do not always fire in the order you think they do, the documentation does not really make it clear what order things occur and sometimes things seem to behave differently than the documentation (initstage set to defer on an item seems to get called automatically last even when no completeInstantation() method is called for example). Also, it is not always clear what object is throwing an event or calling a method when you are debugging. Memory leaks are a nightmare to debug. The OpenLaszlo debugger really needs improvement when it comes to debugging large complicated projects.

C) Skinning:
(Difficult to Skin OpenLaszlo Components, no support for multiple application looks on same OpenLaszlo install, some base components are considered ugly by our customers)

The biggest turn off from most people we demonstrate our application to (based upon their comments) is the actual look of the OpenLaszlo components themselves. What I would like to see instead of the current skinning method is as follows:

1) A setting in the configuration file where you can set the directory where you want the OL component images/SWFs to be loaded from instead of the current hard-coded paths in the base components themselves. This would allow you to change the default look of the OpenLazlo components without actually altering any of the base OpenLaszlo classes.

2) An optional setting (tag at top of application? attribute of canvas tag?) that would allow you to set a path for the component images overriding the default component look for the specific application that you are loading. This would allow you to have different looks for different applications that are running under the same OpenLaszlo install, this is useful if you have different customers and/or different applications with different preferences for the look running off of the same OpenLaszlo install.

3) I would like to see some option that would let you choose between a few standard default looks for the base components built in that would mimic popular Operating System looks, like a Mac look, Vista look and Google App look for example. This would provide an easy way to make your customers comfortable with a familiar look.

4) Very Poor CSS support:

"Perhaps it would be even better to use the actual css2 attributes like color, background-color, etc. Not having padding or borders on views also feels lacking. Margins can be done with constraints as I feel it should be. I know padding and border can be done with a custom class and extra views but these all costs resources."

-- I agree, I would like to see the CSS be much more similar to normal HTML CSS2 and it is inefficient and awkward to have to put a view into another view just to put a border around it.

[Markus]

I'm a little disappointed about the lack of response to this thread. I took a fair bit of time to put everything in writing in response to a call for information. Acknowledge or deny as you see fit but some response would have been appreciated.

[max]

I'm a little disappointed about the lack of response to this thread. I took a fair bit of time to put everything in writing in response to a call for information. Acknowledge or deny as you see fit but some response would have been appreciated.

Hi Markus et al,

First off we want to thank you for your detailed responses. It's been really helpful to hear everyone's criticism to help us prioritize. We're aware of these issues and in particular, I want to improve CSS a lot. We're also looking at adding support for HTML 5 features as low-level primitives like round rects, embedded fonts and drop shadows. Doing this will make porting to DHTML much easier. As HTML becomes more powerful, Flash becomes less and less important and we are uniquely positioned to make the transition more easily than anyone else.

Rest assured, we're listening. Please keep filing bugs - and bringing them to our attention - the laszlo-dev and laszlo-user mailing lists are a great way to get in touch with the core team. In the mean time, thanks for all you do!

[rajubitter]

Hi Markus,

As I'm not working for Laszlo, and I'm pretty busy on a project right now, I haven't found the time to respond earlier.

First, let met say that your feedback is really valuable. I haven't started this thread to get the feedback for myself. I was hoping for some valuable feedback that could be collected by the OpenLaszlo team and prepared when talking to the Laszlo management team, steering the future direction for OpenLaszlo and the LZX language.

Now that the DHTML runtime feels solid and mature enough to build large applications on top of it, the OpenLaszlo team can focus on improving some of the pain points we as OpenLaszlo developers experience every day.

And I'm sure that 80-90% of all developers and project managers working with OpenLaszlo will tell you the same thing: overall experience is good, but components are a bit ugly, skinning of components is far to complicated, some components are not working that well, CSS support could be better, too many changes in the syntax, ...

One comment on the syntax: To be fair, it's much easier to have a single runtime RIA platform and be able to stick with one version of the language for a longer period of time. With JavaScript 1.2 and ActionScript 3 support that's not easy for OpenLaszlo, since many of the syntax changes were required to support the new runtimes.

We, the OpenLaszlo community members, can influence the direction of the OpenLaszlo project. Let's collect all the information in this thread - suggestions, improvements and anything of interest - on this wiki page:
OpenLaszlo 5 Community Wishlist (http://wiki.openlaszlo.org/OpenLaszlo_5_community_wishlist)

Thanks for all comments, let's keep the discussion going!

Best,
Raju

[rajubitter]

Developing for SWF and switching to DHMTL (or going from swf8 to 9) means you might have to take different approaches in the core of your application. We've been using roundrects for quite a bit of styling in flash which are not very portably to DHTML. Font embedding is another but this is a general html problem and not something I'd point to Laszlo for. It's all doable but certainly not a matter of just switching the radio button from flash to dhtml. At least not yet. DHTML experiences and samples are still a bit sparse. Which is understandable considering how the DHTML runtime is still new and being actively developed.

Some comments on that: Which features in Flash did you use, that are doable in JavaScript? As I've stated in one of my blog posts, much of what Flash can do right now is supported in the "good browsers", Webkit/Safari, Firefox, Google Chrome, Opera 10, iPhone and Palm Pre/webOS browser.

Adding the missing features to the platform, is not a matter of months, but more a matter of 3-4 weeks for 2 developers. The community can play a big role here!

Just check the text shadow demo I built a while ago:
http://openfuture.rajubitter.com/2009/08/25/openlaszlo-dhtml-css-3-demo-to-flash-or-not-to-flash-is-no-question/

If you look at the code you'll see that it doesn't take much to add Flash-like features to OpenLaszlo. Text-shadow support can be added with a total of 40-50 lines of code, I'd say - and you need to touch as little as 4 files in the LFC for that.

True, IE won't support those features, but you can still deliver the Flash version to IE6/7/8.

Here are some of the JIRA bugs I filed to tackle some of the interesting features:

Box shadow support - http://jira.openlaszlo.org/jira/browse/LPP-8399
Text shadow support - http://jira.openlaszlo.org/jira/browse/LPP-8409
Downloadable fonts - http://jira.openlaszlo.org/jira/browse/LPP-8313 (Check out this demo page http://opentype.info/demo/webfontdemo.html)
HTML 5 Web Socket support - http://jira.openlaszlo.org/jira/browse/LPP-8454
HTML 5 drag & drop desktop integration http://jira.openlaszlo.org/jira/browse/LPP-8458

Other things like rounded corners are part of the CSS3 standard, and here's a demo page showing that:
http://www.james-blogs.com/2009/02/03/rounded-corners-in-css3/

That means, you could have your rounded corners, drop shadows filter, text shadow filter and many other cool things running in DHTML.

Best,
Raju

[rajubitter]

Added a request for a new feature for rounded-box or rounded corners across runtimes into JIRA: http://jira.openlaszlo.org/jira/browse/LPP-8508

- Raju

[Markus]

Max, Raju, thanks for responding.

Raju, I've seen your shadow demonstrations before this thread went up. Impressive. Your point about using flash for old browsers and dhtml for real browser is music to my ears. More often then not our customers rely on IE6 for their corporate desktops. IT Policy about upgrades, old applications, yada yada yada. It's a very real problem regardless of which technology I use. My colleagues can tell when I'm working on a jQuery project that needs IE6 support. They stay the hell away from me. I'm anxious to see if OpenLaszo can really perform this small miracle on a medium to large customer project. Apart from a few odd quirks where IE abused the flash plugin I've had no problems with flash compiled Laszlo projects.

In regards to which features flash has that javascript doesn't I'd have to agree that modern browser can do most if not all of it. I'm happily using these features in pure HTML projects. The only thing I could think of right now is the smoothness of animation which is superior in flash 9. Although frameworks like mootools are getting very close in performance. HTML5 is a big blip on my radar as well.

I'm also happy to see the wiki pages and the Jira issues you've created. At this time however I'm more likely to stay a platform users then contributor. Other then bug reports and the odd forum post of course. My boss keeps me mighty busy (which is good since it pays the bills) which leaves little time to try out the latest and greatest versions of Laszlo. I'm still looking for an opportunity to get a project going with the latest laszlo version and DHTML as a target. As you can imagine there is quite a bit of politics involved.

I'm noticing a trend in customers asking for non-flash solutions. So I often have to answer the question 'why pick openlaszlo over a solution like jQuery?'. 'Isn't a browser native approach faster?' 'Which one is quicker to develop?' 'Can we hire people to speed up the project?'. We've currently got more experience with OpenLaszlo but the javascript frameworks are gaining ground. Our own MVC approach in Laszlo is paying off for development speed but it could just as well be applied to javascript. XML handling in Laszlo is superior at this time.

One thing I'd like to mention is XPath. Selectors in javascript engines are a joy. CSS3 based or otherwise. The XPath engine in Laszlo is a similar joy but lacks some features. Selecting a node by (partial) text() instead of just attributes would be welcome. We usually have to script around this. Less script is better in my book. I believe this feature is on the wishlist already.

Right. Time to go back to my weekend. I'll keep an eye on this thread, the wiki and Jira. I'll also keep looking for that Laszlo DHTML opportunity. Might be I'll just have to start a personal project.

[caclark]

For me, it was mainly 2 things: The DHTML technique and development time. But there are some other pain points, too.

1) The short, easy one: I compiled one of my apps to DHTML. I don't care for the 1 large Javascript file approach. I prefer smaller pieces of code going across the wire if & when needed.

2) But, mainly, the issue was development time. There are 2 components to this - debugging and the code-compile-test cycle. I can flat out develop faster using other frameworks. After coding 2 decent size apps over a 3 year period in OL, I was able to redevelop the UI for one of them using another framework _much_ faster. Granted, there is some benefit of having the UI design done and implemented in OL, but that was only a small part of it. Markus on 09-16-2009 @ 03:56 AM summed it up well: CSS, skinning, the datanode/dataelement/datapointer fiasco, and *debugging* were major pain points for me, too. I've found in my 25 years of development experience that a lot of people can lay down code. A far smaller number are good at debugging (especially someone else's code). I don't feel like there is a good, comprehensive, integrated set of debugging tools to do OL development.

In the app that I redeveloped the UI for, the enhancements I've made to it since converting have come so much easier. I found that I had been putting off enhancements and bug fixes due to the pain-in-the-butt factor of debugging. I've switched to a different Java + markup language framework. It's nice to hand a data model that's bound to a ui element a collection of Java objects and it renders it. No conversion to XML. No replication quirkiness. And if I need to see what's going on, I set breakpoints in Eclipse and debug. It's much faster and easier for me using a markup language for the UI that is similar to OL but has a complete Java backing to it to step through and not ActionScript. Whether it's my code or the framework, I appreciate the ability to step through it all. I don't like to have to step through the framework, but when I have to, I can. No framework is perfect but it's been nice to step into it to see what's going on.

The code-compile-test cycle time is way too slow with OL. You might be saying "what? with today's fast machines....". In OL, if I have my own window class/instance and want to make a change to it, I have to recompile the entire app and reset my test. I broke my code down into small chunks, as is good practice, and used the "<include href="xxxx.lzx"/>" paradigm. If xxxx.lzx changed, it was a recompile. When you're deep into a non trivial app and need to change that file, it's a bag full of hurt to recompile and navigate back to where you were. With the framework I'm using now, I can change the appropriate source file, close just the window defined in it, reopen it without restarting my app, and I'm back to where I was in just a few seconds. I don't have the slowest or fastest machine on the planet, but doing this in a decent size app in OL could easily be a 1 minute turn around just to get logged back in. And then I had to navigate back to my test point. And when you have a "doh!" moment or 2, you realize how nice it is to save the source change, click to close the window, click to reopen it, and continue what you were testing.

In addition to the redeveloped application, I also developed a completely new app from scratch that I believe was done in 1/2 the time it would have taken in OL. Of course, there is no objective way to measure this, but I had done 2 apps in OL and this was my second using the other framework, so I think I have a good gut feel about it.

3) What do you mean you can't easily tell me how many items are being replicated before replication is complete? The hoops we jumped through just to know when replication was done was laughable. If there's an easy way, it sure escaped me. I haven't done any development post 4.5, so there might be an easy way now. But there wasn't back in the 3.x - 4.1 "good" old days.

4) Paging of long lists. This was a "fully manual" process as one of my developer brothers says when politely describing something that you have to completely do yourself (and probably shouldn't have to).

5) Rendering of grids using components other than static text was slow. I had 1 major piece of functionality that I had to leave out of the OL version of my second app because of speed. Even in Flash 9 it was dog slow. I tuned it too with lazy init all I could and used lighter weight components, but it was just never acceptable. I'm sure soom of this was Flast and some was OL. But, that's part of the problem - issues that the OL dev team cannot control. I have a solution in place now using list grouping that performs quite fast.

As you can tell, I've continued to check in on OL even though I haven't done active development in it for roughly a year. I've also intentionally not named the framework to which I've moved because I don't want this to be a slamming-OL-and-praising-XXXX post. You solicited input, I've tried to give it objectively, and I hope it provides some insight as to why I moved away from OL.

Cary

[pierrearinsal]

I'm gonna be a bit tuff, but as we say in french "qui aime bien chatie bien" (i.e the more you love the more you punish... or something like that!)

I use openlaszlo since 2 or 3 years. mainly to provide my clients with basic database interfaces.

I would love to use it more often or for bigger project but here are the reasons why I don't.

1/ a lot of new releases, new stuff, blablabla, svg, dhtml, swf8,9,10, you can even release a swf125, what's the point of having so many when NONE OF THEM REALLY WORKS. don't get me wrong, it's nice to have a lot of projects, when you have a leading one that actually works. I don't know. choose one (swf8...), make it hard rock solid, or just make it work, and then reproduce success on other. what the point of having a datepicker that has never been usable, ported to new engines (swf9,dhtml, svg...), when it has been so badly designed at the first place! it's success one should reproduce, not failure!!!!

STOP doing new useless releases. There is no point in painting a building to make it looks like new when the very basis of your building are colapsing!!!!

2/ NO DOCUMENTATION. and I mean it. openlaszlo doc is out of date and USELESS. the only doc is the sources code.

3/ Except Senshi, is any body in ol staff aware of ol forum existence?

3/ and maybe the worst : basic widgets do not work. yeah ol has bling-bling datepicker, chart, video, sound.... but they just don't work. it is still not possible to have a simple list with alternated colors, except if you patch it yourself (see last week post, the one that haven't been answered yet!!!!).

4/ java, javascript, action script, dhtml, xml, swf 8,9,10, svg, ..... why not tk, gtk, qt, why not X, and what about integrate the kernel sources directly into openlaszlo? I mean let be serious for 1 second. how many staff ol has. how many projects ? how many that works or are close to? I don't want to be rude, but when I proposed openlaszlo as a possible ui for ours applications, here is the response I received : openlaszlo is a bunch of spoiled kids, probably gifted, playing with their computers, doing fun stuff. but NO USABLE TOOLS, NO DOCS, NO SUPPORT, A "DO IT BY YOURSELF COMMUNITY" ...

I don't think I have to go further...

ol is now a dieing project cause it goes in too many directions without having a single one working.
the "spoiled kids" thing is not mine. that's really what I have been said! and I must say I had nothing to answer to that, cause it sounds really true. I would love too to have a job when I can play with my computer trying new stuff without giving a flying fart about end costumers, docs, forums, ..., just releasing once every two months a new brutal not working, not documented version of the toys I have been playing with recently!

If ol has some new available positions, I'm in!! because here, in the real world, that's not how it works....

so to sum up :
ol is a nice toy to play with.
except for very VERY basic app, forget about professional use.
NO DOCS = NO FUTURE, even with insane new not working scheduled releases...

maybe it's time for ol to stop being a spoiled playing kid and to start enter the serious working professional adult world.... (and if it is so... well, forget about the available positions... :-)

pierre

[Ag_Smith]

1)Implement selector, class, identifier, pseudoclass, pseudoelement and all related stuff of css syntax

2)Miscellaneous runtime, for example at moment we can't use audio/video in dhtml, we can introduce some attribute like runtime="swfx/swf8/swf9/swf10/dhtml", this is useful also for a lot of things that we know work better on a runtime instead of another

3)Stop releasing openlaszlo with version as folder name!! for each version I have to update the apps path !! this is a very annoying thing! simply put the version into a text-file if someone work with more than one version than he will rename folder!

[rajubitter]

@Ag_Smith: Some more good points, I agree with 1). I see the danger of ending up with views and 100+ attributes to match all the new CSS features.

2) Max has done an example of how to embed an SWF app into a DHTML app a long time ago (2007, I guess). Here's the link:
http://labs.openlaszlo.org/trunk-nightly/examples/musicdhtml/index.jsp
There's a detailed WIKI page discussing that scenario (http://wiki.openlaszlo.org/SWF_in_DHTML), as well as a JIRA entry. Would be good to be able to say <view runtime="swf10" /> within a DHTML app to run the content of that view as SWF. But that would be a lot of work to implement.

3) Which folder are you talking about? The name of the WAR file, or folders inside the WEB-INF or lps folder structure?

- Raju

[navdeep.mahajan]

Following are the things i didn't liked about laszlo:
1. No good IDE available
2. Java RPC errors result in timed out error always, specific errors not provided
3. Dynamic object creation using Javascript is not intutive and some of the features like dynamic scroll bar doesn't work easily
4. Large volumes of data inflow causes Action Script running slowly errors, there doesn't seems to be built in pagination support

[Ag_Smith]

3) Which folder are you talking about? The name of the WAR file, or folders inside the WEB-INF or lps folder structure?


i am talking about the name of the war file...
actually i am working with this path:
/home/gioacchino/Desktop/development/lps-4.6.1/Server/lps-4.6.1/my-apps

you can see that -4.6.1 appear... also to see my apps on a web browser i need to know the version
http://localhost:8080/lps-4.6.1/my-apps/
also is annoying rename or link every time by hand...