[fpc-pascal] Servlet server for Fpc apps

Dariusz Mazur darekm at emadar.com
Mon Mar 30 23:58:55 CEST 2009

Michael Van Canneyt pisze:
> On Mon, 30 Mar 2009, Dariusz Mazur wrote:
>> Michael Van Canneyt pisze:
>>>>> I just want to make them in pascal and keep the codebase and know-how I
>>>>> have
>>>>> in my team.
>>>> As I. I want (i;ve done succesfully) reuse 90% of desktop code in
>>>> webbased.
>>>> But you want to rewrite quite huge part to JS. Why? What for.
>>> Because some of the (rather complex) business logic must be in the client to
>>> make it respond as a desktop application. 
>>> A simplified example: 2 sets of data. 2 comboboxes. User chooses from set 1
>>> in combobox 1. Based on his choice, the data in the second checkbox must be
>>> filtered. This must be done without round-trip to the server, because the
>>> data 2 set is large, and combobox 1 is used often. So I need some part of
>>> the business logic (complex relation between items in 2 sets of data) on the
>>> client.
>> I don't agree. Only one requirement should be fulfill, respond in reasonable
>> time, say less than 500ms.
> 500 ms is WAY too slow.
I've just test morfik issue tracker on http://m2.issuetracker.morfik.com,
no one of response was faster than 500ms (by firebug),
for many action browser need mode than one transmit  to server
and for many action, like last issue, find with zero results, filter by 
status time of compute new site was longer than 3 s
And its only 195 records database.
>> My way:  only visible rows are send to browser, say 30 rows, they took  about
>> 3kb, time 3ms in LAN, 100ms when server is on second side of world. Rendering
>> 100..300ms, on slow browser maybe longer. Even it it will be done after each
>> of user action its no problem for server neither rest of infrastructure. On
>> application side: its no matter that is desktop or web based, events and
>> response are the same.
> Nono. We're not talking about 30 rows, more like 5000-7000. Transmitted once,
> when the window is opened. That the window is slow to open initially is OK, 
> but once opened it should work lightning fast for the duration of use.
30 rows are transmit to browser. In database I have 1M and more.
I doubt that filtering from 5000 by JS will be faster than transmit 30 
rows. But for 50000 im quite sure.

> I simplified it a bit, but it is a real life example.

>> Your way: first transmit whole database to browser, JS compute what part
>> should be display. When set of date is bigger you can send partial. But after
>> select combobox all data must be send  to compute filtering. On slight set it
>> may work, but not on big.
>> But even on small sets of data time of response will be notable (I've seen
>> ExtJS demo, its only on browser side, and its work rather slow, can you
>> expect, that most of your code will have better optimization)
> I've seen it in action in Morfik, and it works fast.
What about issue tracker. Its rather simple application, very small 
database and for me work slow.
>> And what about transfer tons on JS to browser?
> Ah, morfik has a nice thing for this: you can preload forms asynchronously.
Small resume about morfik:
it doesn't use CSS
it doesn't use cookie to identify session (with this browser don't cache 
It just use HTML and JS, as most of web application
it transfer each user action to server and wait for response (I say the 
server response are quite big (simple login form need 11kb)

of course morfik looks good,  then have very skill designer


More information about the fpc-pascal mailing list