Laszlo complexity

[aarondc]

Is it just me, or is Laszlo in its present form damn complex? (I've jumped right into Chapter 28+29).

I have some pretty solid experience developing in Dataflex, Delphi, Coldfusion, PHP and even Assembler, and my head hurts reading 3 chapters / day of the online Developer's Guide. [It has too many see (???) instances too :(]

I can see how the environment is fully flexible and powerful / expandable, I just get the feeling that a layer or 2 of abstraction is going to be necessary before the mainstream developer can jump in and develop useful, useable applications (whilst retaining some sanity).

Not a complaint, I understand to some degree the technology acceptance lifecycle. Would you consider present users as "early adopters"?

What I really appreciated about Dataflex and then Coldfusion, was the fact you could write your own programming constructs (DF) / custom tags (CF), etc. Really maniuplate the language and bend it to your own will, should you ever so desire, but could achieve 80% of what was required with the vanilla codebase.

I like what I have seen of Laszlo so far. I can see I will write many classes to hide all the fiddly little details...

[blakely]

I'm a J2EE architect, and I'm working on my first major Rich Internet Application using Laszlo. Sure thing, Laszlo is complex. But I'm think you'll have no troubles if you remember "Blake's Rule".

Blake's Rule: "Rich" != "Thick".

There are all kinds of wondrous tools built-in that really do allow you to pawn off all the "work" on something more appropriate server-side (a servlet, web service, or what have you).

The more work you try to cram in to the LZX files the more you'll pull your hair out. They've done a nice job with it, but XML just simply isn't a "programming language", and all that ECMAscript business is, well, ECMAscript.

So, I'm having great success with it. Keep it simple, treat the LZX just like the view in a standard MVC pattern, chop it up in to manageable pieces, and you're all set.

-Blake

[shawn]

Great point about the View.

I suspect that as Laszlo experience increases we will see two not-so-different, yet discrete designs emerge -

1. The standard MVC2 paradigm, where is LZ is reduced to a simple view in place of JSP/HTML/XSL. For the short term I'm not sure this is going to be a completely practical solution because the lazlo files are rather large. This, by nature, would seem to requires tons of little LZs everywhere -- however it would seem to be much easier to do a site "face lift" via this approach.

Essentially, this is a 1-to-1 replacement of existing views.

2. LZ as embedded application containing their own MVC where they interact with front controlling Servlet/JSP/ASP/what-have-you. This seems to be the direction of LZ based solely on the designs of their demos.

This would be an N-to-1 replacement.

[blakely]

I agree with your assessment here. My point was that, while LZ is complex, the temtation is to make it *too* complex by cramming in to the *.lzx what should be left to other structures.

I come from a Java Swing background, so I'm having good luck building LZ apps in the same way that I'd think about building swing GUIs (more or less).... Just create widgets that do what they're told and interpret what they're given, rather than actually trying to make them a real honest-to-goodness control structure.

-b

[lipe]

Sorry to say that, but in my humble opinion Laszlo is complex to people that are used to develop like: drag´n´drop x 10^100 = application.

Developing in Laszlo is almost as easy as html, but even easier because it works. The basic tags to make basic interfaces can´t get any simpler.

To make use of the more impressive features, if the developer is used to the MVC paradigm/pattern, and very little object oriented programming, that should get the job done.

[aarondc]

If it isnt complex for you, please explain

http://www.laszlosystems.com/lps-2.2/docs/guide/databinding.html#d0e16917

in particular how the example listed at

5.1.2. Clones and the onclones event

works. There are no comments in the code.


[The application I am most fond of developing was an interrupt-driven TSR com-port driver, hand-coded in assembler. Good old Borland TASM.]

[shawn]

Aarondc,
It seems that LZ is showing us the importance of using delegates when working with clones (apparently due to the timing of the event firing) - "because the onclones event is sent when the clones attribute is set, it only signals the start of view replication, but in this example it is used to determine the exact moment when replication is finished. Since replicated views are initialized in the same order they are in inserted in the clones array, we only need to wait for the oninit event for the last clone in the list."

So the example goes on to show how to used the clones properly (per the onclones event and delegation to the cloned views onit event).

I agree, some documentation would have been nice.

It also seems that this example is a bit awkward, in that you could have (seemingly) used the datapath attribute on "gs" and "ds" directly and had the "create tabs" functionality reload the datapath -- of course this is geared more towards lazy instantiation than there example.

The bit that I do not understand is why are these clones? Is it because <repltabelt name="pane"> exists in both "views"? LZ states - "A replication manager is a runtime object that is created automatically whenever data replication occurs as a result of a datapath matching more than once"
What does sharing a datapath have to do with cloning the calling object?

[aarondc]

Ahha!! From http://www.laszlosystems.com/lps-2.2/docs/guide/databinding.html#d0e16917

I understood -why- the tabs were cloning/replicating, I just didnt understand how the code

<method event="onclones">
if (!this['doneDel']) {
this.doneDel = new LzDelegate(this, 'openOH')
this.doneDel.register(clones[clones.length - 1], 'oninit')
}
</method>

could possibly generate the oninit event for the final view/clone and that clone ONLY. Makes no sense to me at all... Also, where is 'doneDel' created in the example code?


As it turns out, I have sorted the tips by Antun in reverse order (wow, you do alot of work around here, thanks!), and am reading them all, one at a time... I just discovered the following:
http://www.laszlosystems.com/developers/community/forums/showthread.php?s=&threadid=659

<attribute name="doneDel" value="null"/>
...
<method event="onclones" args="clones">
var lastclone = clones[ clones.length - 1 ];
if ( !this.doneDel ){
this.doneDel = new LzDelegate( this, 'replicationDone');
} else {
this.doneDel.unregisterAll();
}
this.doneDel.register( lastclone , "oninit" );
</method>

The differences are:
1. doneDel is created somewhere
2. The unregisterall() call removes the delegate registered by this.doneDel.register( lastclone , "oninit" );

I understand how this piece of code does what it is meant to, but how does the original (and in my mind complex, mainly because it was purported to be doing something and I couldn't see how) piece of code work? There is no unregisterall(), so the first clone (only) now has a delegate pointing to its oninit event that will surely be fired?

No longer a concern for me, the second tip has sorted it out. Maybe the code from Chapter 29 is incorrect and needs debugging.