[Lazarus] GUI development for web UI

[Michael Van Canneyt]

On Wed, 24 Nov 2010, Dariusz Mazur wrote:

>>> That's not true. Transfer every action to server is very simple task, and 
>>> computing results also. Thus (on my web app) it took less than 10ms and 
>>> every user very rare generate more actions than 1 per second.  Computing 
>>> and sending pdf reports took much more (more than 90% of working time). As 
>>> I observe two on core machine can work 100 users concurent without 
>>> problem. With more can be problem, but  with memory.
>> 
>> Yes, I remember my discussion with you. I also remember that the round trip 
>> time I observed is over 100 ms, which is noticeable. (maybe not on 
>> intranet, but definitely on internet)
>
> You told about scalability.
> 10ms is on server, on user side You should add transfer as ping (but this not 
> load server)

Let me put it differently. In the interface I was talking about, I need 
exactly 3 HTTP requests, no matter how much the user clicks/hits keyboard 
to set checks:
1. Fetch form 
2. Fetch data.
[grid is built on client using fetched data]
3. Save Data (user presses save buton)

Your implementation needs 3 (maybe 2) requests to fetch form and data and 
process save, plus additionally a request for each user click/keyboard hit 
to set a check.

If that is correct, I don't even need to build these 2 systems to know 
that my system will scale better.

And - unless I understand your code wrong - you keep the complete form 
state on the server ? (I.e. keep a pascal instance of all visible
TForms and controls in memory).

I don't need that at all. The amount of data I need on the server 
per user session is roughly 200 bytes, and it doesn't much change during 
the session.

Again, if my assumption is correct, my system again scales better, 
because it does not need nearly the memory your system uses.

Looking at recent trends (Ajax, rich client interface toolkits) 
people agree more with me than with you. But I may definitely 
be wrong; everybody sees the world through his own spectacles...

>> Secondly, you have not very demanding users and/or GUI, it seems :-)
> Of course this is not game application, but on every ERP application (like 
> my)  are places with rather sophisticated GUI.
>
>> I'll describe an interface which I currently have: A grid with about 600 
>> checkboxes (don't ask why, they want it so).  Users click the checkboxes in 
>> rapid succession, thus generating much more than 1 event per second.
>
> I have forms with similar widgets too. Second: faster than clicks is 
> keyboard.

Well, most likely not if you must check which key was pressed, discard bad 
keypresses etc, on the server.

I also proposed keyboard but they require the mouse :(

> But even that: its no problem when response arrive after next 
> click. If response is under 300ms users thinks : "that is at now"

On average the user sets 50 checkboxes before he presses save.
50x300ms = 15.000 Ms = 4 minutes just to process the checks ?
I don't think so :-)

>> But if you believe in it: why not cooperate with the Lazarus team and
>> create a web widget set ? All options must be explored, you obviously have 
>> a good basis for it, so why not share it 
>
> I try to share my work  (without this hope I simply not write this post) but 
> nobody is interesting.
> link: http://www.emadar.com/fpc/xwebdemo.zip

I think most people on the Lazarus list simply didn't know about it.

But I hope for you that this will change now, and that people 
look at it and prove me wrong. And in doing so, hopefully they
create a good Lazarus widget set.

That is finally what it is about for me: advancing FPC/Lazarus.
I have my idea about how to do this, but if other ideas exist: 
the more, the better.

Michael.