I don't know about anyone else but we've been using OpenLaszlo for 18 months
and we are now in the process of moving away from it to plain ajax/jsf
infrastructure.   The reason given by management is the lack of visual
design tools.   The opinion (and I have to agree) is that it takes too long
to train the new engineers on the specifics of laszlo design / layout on top
of everything else they have to learn about our product.   Too many of the
other tools out there are allowing you to visually tweak the layout and look
and feel of UI and laszlo is unfortunately behind the times with regard to
this functionality.
 
 

  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of mt1
Sent: Tuesday, April 03, 2007 7:12 AM
To: laszlo-user
Subject: Re: [Laszlo-user] IDE4Laszlo status


David,

 I know what your opinion on the IDE of OpenLaszlo.
 Yes, i agree with you about what you said there are a lot of good XML
editors and OpenLaszlo
programers can use them.
  Until a few month ago, i also used Eclipse with IDE4Laszlo.
 But now, i am using simple text editor to edit coding, and i am satisfied
with using it.
 It was too heavy for my PC that was working Eclipse, Tomcat with LPS and
PostgresSQL for database.

 But in the other hand, many engineers are using Eclipse.
 I fond a result of using IDE research by Nikkei-BP in Japan, as following.

 http://itpro.nikkeibp.co.jp/article/OPINION/20070329/266887/

  Unfortunately it described with Japanese, but i say simply, Visual studio
is the most used and
Eclipse is the second.  From this research, we don't look out the Eclipse
environment.
 
 We should mention who are use the IDE.
 You know OpenLaszlo provided IDE for Eclipse at the first, but in Flex, the
first was the FlexBuilder,
the second was for Eclipse. I think we should give attention the IDE for
whom.
 If we have image for *power* engineers, we don't any take care about IDE,
because they can find some
good programing tool which they like.
 If we have image for *ordinary* engineers, we might to provide for Eclipse
environment. Because most
of the engineers are in a IT department in their company and they can hardly
to choice their 
*environment* for their development. The reason why, the one is the issue of
standardization and the another is the
*custom* for their coding style, and there are many more, i guess. Just i
can say, there are
many barrier to introduce some *new developing tool* into their corporate
department. But if it is based on
Eclipse, it can easy to introduce into it. Because they already *have* and
*know* it.
 But if we have image for *beginner* engineer, that mean who is a web
designer or a novice programer,
the visual design tool will be big present for them.
 I know you are almost thinking about those.

 Back to your opinion, the visual tool is great efficient tool. But it
should have relation with the text coding tool
or it ought to include it. Because it must occur with bit control on the
editor, like x/y position control or some 
attribute and more.
  I can say it dose not work on Eclipse, but Eclipse plugin have a advantage
compare with it.
  It mean not *tool* but *strategy*. 
  OpenLaslzo and Webtop are very cool, but most of engineers requires a
development tool too.
  I have no doubt it is very important point to generalize OpenLaszlo. 

 So my opinion, it is glad for them to get two coding tool. The one is the
*special* design tool( like FlexBuilder )
and the other is the plugin for Eclipse. :-)

 mt1
 

jamesr wrote:



On Mar 24, 2007, at 12:16 PM, David Temkin wrote: 



mt1, 

IDE4Laszlo -- we (Laszlo Systems) haven't done anything with it and  don't
plan to. Doesn't mean someone else can't do something with it. 

One idea that we're discussing now is to kick off a project to make  an
LZX-based graphical editor. It's scope would be limited to the  graphical
layout, positioning, linkage, attributes, etc of LZX  objects. It would not
be code editing-focused -- there are tons of  tools for that. It would be
written in LZX, and would run in the  browser. It would support "round-trip"
editing, so that you could  edit with an IDE/code editor, and then the
visual editor, and then  the code editor again, without loss. The back-end,
which would read  and manipulate the LZX files, would be written in Java,
and would  run in the same context as OL itself. 

What do you think of this approach? Right now it's just a concept. 

- D. 




I did thought experiments and prototyped a system like this bit back.  It is
doable, with a set of limitations as to what can be edited. You  couldn't
see the effects of editing Javascript in the IDE (you'd have  to compile
because eval isn't strong in there) but you could see the  effects of adding
and removing attributes, changing layouts, etc. To  me the concept hinged on
building components - classes with  specifications that could be read by the
IDE - that would become  available to use. It wouldn't just be any set of
LZX code, but an  easily extendable ever growing list of "prepared" classes.
This way  the parameters to any class could be known and displayed properly.


I saw something similar to RealBasic's IDE coming out of this approach. 

I had this running in Blooms  (a laszlo templating system) and  although i
wasn't targetting reading from LZX - it was going to  choose a Blooms
language intermediate that would render to LZX - I  had some interesting
ideas as to how the layout of the IDE would  work. For instance, since the
blooms thing has "server" transforms  that build XML datasources,
datasources would also be included in the  IDE in a "cloud" that you'd pair
and move around in groups of their  functionality (in python fwiw). From a
visual standpoint, i thought  it would be nice to describe complete
applications with server side  resources in a single environment. 

The proof of concept system properly read in the list of components  and
their attributes, and allowed you to make new components on  screen, to
prove it was possible. It seems so. 

Hope this is topical, 
    James. 












Reply via email to