Component Sluggishness??

[TheCatWhisperer]

Hi again,

So I've been playing more with your comonents and attempting to mirror our current app (in a non-dynamic/non-db fashion). I've noticed a few get issues with speed so far, these verywell may be me missusing a component or not understanding how they should be applied effectively. The two main sluggish points are:

A: Switching to "Tab 5" can take a couple seconds. Should be immediate. Will this dissapear when optomized??

B: The scrollbar contained withing the list (inside the Tab-pane: "Master Criteria 1") on "Tab 5" is VERY VERY slow, clicking on one of the arrows results in a 1-2 second wait for the scroll to take place. Trying to pull the slide bar is painful.

I'm attaching the file to this for any of you who might have ideas. Again, it could be my fault. I'm new :)

/c

[metasarah]

Thanks for posting your app. It was very helpful to see your code in diagnosing the problems you describe and in understanding what you are trying to acheive.

(A) Why is it show when you click on tab 5? Tabs are built so that the content that is not visible when the app starts, may be init'd later (internally it uses the option initstage="late"). If you wait a bit before you click tab 5, there is no delay because the initialization happens in the background. If you optimize your app, tab 5 opens quickly when you first start up. This should be in the reference guide, but its not (yet).

(B) This is a bug. Thanks for finding it. It is related to the menus associated with each list item. If you comment out the popup menus, scrolling performance improves dramatically. In the final release you can expect that popup menus will have no performace implications when they are not visible.

Notes:
- menus go away when you click elsewhere. Since you cause them to appear when the mouse rolls over an item (rather than clickling on it), you'll want to add some logic to make the currently up menu close when you open a new one

- in this app you might consider creating the list items from a dataset. This often leads to a more maintainable app and if the list gets long you can use dataoption="lazy" to optimize performance. There are examples of this in the reference guide.

Thanks for giving our new components a whirl! The quality of the menus in the preview release are not representative of the overall quality of the components.

We really appreciate your feedback.

Sarah

[TheCatWhisperer]

Thanks for the quick replies :) Yeah, I was guessing that the menus might be causing me grief. Unfortunately, they are a required part of the application :|

I have not yet tried to play with dynamically creating the lists, actually, that whole side area (including the number & labels of the slide-panels) will need to be dynamic. In our current app (dHTML/JSP) this is created when the page generates from meta-data in the DB (SQL server). Many parts of the application will need to be created on the fly based on meta-data we get from our databases, as each customer will have different data & requirements and the app has to function the same with all of them, we do not custom build the base app, it builds itself based on the DB. (Am I making any sense?? I fell rambly.. ;)

Our app is mid-sized, but very dynamic. It will grow & has to be able to integrate with other applications (at least on the Back End). For more info on what we do, feel free to visit our site (link in my sig). Wish I could give you a little demo so you could see where I'm coming/going, but I need to get that approved. If you are interested, let me know & I'll see if I can't set up a web-ex or something.

Anyway, my evaluation of your product is broken into 3 sections:

1: Components & ease of use - how much of a learning curve is there, how fast can I create/recreate a page with your system, compared to our original and others?

2: Using data - currently data is given to our app via HTTP requests. This will be changing in the not TOO distant future to be web-service & streams. Therefore, I'm going to be testing your (and other software) using XML data.

3: Sending & Receiving, Web Services, Other special features - How easy is it to get XML data in & out of the application, to & from our web services. Can we do nifty things like drag & drop, streaming content, live data (tickers, IM, file ul/dl, etc).

So far, I'm still playing with #1, and am very happy. I've recreated portions of our app in 1/4 of the time or less than it takes with dHTML. I'm shortly going to be moving on to web service like data (not pulled from a web-service just yet, but "pretending it is". If you have any links that would be helpful, that would be great. You've been a great help so far & if there is anything i can do to help you guys, let me know :)

/c

[antun]

I thought I'd fill you in on the three areas of your evaluation:

Components & ease of use

I'm glad you like the components! The new LZ Components that ship with 2.0p have been completely rewritten. Don't forget - the LPS is a platform; you can also make your own components to suit your needs. A lot of the time, it's not hard at all to make a data-driven component that allows the user to view or edit data in some unique way.

Using data

Right now the LPS supports XML over HTTP. SOAP support is planned. You can always have a service (e.g. JSP, PHP etc) of your own that translates data if need be. Remember that data requests happen without a page refresh.

Sending & Receiving

Like I said data requests happen without a page referesh. Check out the Amazon app (http://www.laszlosystems.com/lps/sample-apps/amazon/amazon2.lzo?lzt=html) to see what I mean. You might also want to check out these two tutorials on data:

http://www.laszlosystems.com/developers/learn/documentation/tutorials/data.php

and

http://www.laszlosystems.com/developers/learn/documentation/tutorials/data_app_1.php

Hope this helps!

-Antun