[Lazarus] GUI development for web UI

[Michael Van Canneyt]

On Thu, 2 Dec 2010, Marcos Douglas wrote:

> 2010/12/2 Michael Van Canneyt <michael at freepascal.org>:
>>
>>
>> On Thu, 2 Dec 2010, Marcos Douglas wrote:
>>
>>> On Thu, Dec 2, 2010 at 1:12 PM, <michael.vancanneyt at wisa.be> wrote:
>>>>
>>>>
>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>
>>>>> W dniu 2010-12-02 11:38, michael.vancanneyt at wisa.be pisze:
>>>>>>
>>>>>>
>>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>>
>>>>>>> W dniu 2010-12-02 09:25, michael.vancanneyt at wisa.be pisze:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> ExtPascal uses threads to handle multiple connections. I remember
>>>>>>>>>>> you
>>>>>>>>>>> don't accept this way, right? BTW, what is there wrong if
>>>>>>>>>>> ExtPascal
>>>>>>>>>>> uses threads?
>>>>>>>>>>
>>>>>>>>>> I accept using threads, but not the way ExtPascal does it. Threads
>>>>>>>>>> should be
>>>>>>>>>> optional. In extpascal, the thread is equal to the session: if you
>>>>>>>>>> have many
>>>>>>>>>> sessions, the application will create as many threads as there are
>>>>>>>>>> sessions.
>>>>>>>>>
>>>>>>>>> I use different architecture: each session has own thread and each
>>>>>>>>> connection has own thread. Sessions are separated from connections and
>>>>>>>>> communicate via FIFO queue.
>>>>>>>>> Session runs whole life time in the same thread. With this i can use
>>>>>>>>> modal form and thread var in the same manner, as normal (desktop)
>>>>>>>>> application.
>>>>>>>>
>>>>>>>> I understand this is the easy way.
>>>>>>>>
>>>>>>>> But you don't need this architecture to do that. As long as a single
>>>>>>>> request
>>>>>>>> runs in a single thread, there is no problem with decoupling sessions
>>>>>>>> and
>>>>>>>> threads, and still be able to keep everything in memory.
>>>>>>>
>>>>>>> I dont understand.
>>>>>>> I parse single request in single thread (for each request new thread)
>>>>>>> and what can I do (other) with sessions?
>>>>>>
>>>>>> One scenario looks like this:
>>>>>> - Request comes in (on whatever thread).
>>>>>> - Determine session data (your form) for the request.
>>>>>>  Session data is in a global list.
>>>>>> - Find a thread to handle the request.
>>>>>> - Pass session data to thread and let it handle request.
>>>>>>
>>>>>> Another way is
>>>>>> - Connection is accepted.
>>>>>> - An idle thread to handle request is found.
>>>>>> - Thread looks up session data from data in request.
>>>>>> - Thread handles request using found session data.
>>>>>>
>>>>>
>>>>> At the beginning I use second attempt, after that first. But both have
>>>>> limitation, because not follow (not act as desktop OS) desktop architecture.
>>>>> There are  not pass to more complicated application (when it is porting
>>>>> from Delphi).
>>>>>
>>>>
>>>> This is correct, but I assume that when starting a web application, you
>>>> will start with a fresh design.
>>>>
>>>>> 1. All task of application should be prepare as response for request,
>>>>> there is problem with modal forms, which stop and wait to user action, and
>>>>> after response go on (next statement in current procedure, not other ).
>>>>> 2.  When application is busy for long time with preparing response, its
>>>>> no chance to make simple response with message of waiting (or progress bar)
>>>>
>>>> I don't see the connection of these problems with how threads are used.
>>>> A simple WaitForEvent()/SetEvent() should do this.
>>>>
>>>>> 3. With second attempt session data is computing with different threads,
>>>>> thus thread vars can't be used
>>>>
>>>> They are only a problem if you use global variables. You should never use
>>>> global variables, unless maybe the database connection and global
>>>> application configuration.
>>>>
>>>> None of my 4 web applications uses global variables (except said database
>>>> connection and global configuration object). The other programmers have
>>>> not yet complained. They know global variables
>>>> are evil from their work on our regular desktop program :-)
>>>
>>> How do you work to manipulate sessions?
>>
>> There is a global sessionlist (simple hashlist: string is session GUID,
>> object is session module).
>> based on the session cookie, I get the session. All other things are stored
>> in a descendent of the session module.
>
> There is just a global sessionlist accessed for many threads, at the same time?
> The fpWeb framework manages thread conflicts?

No, it does not. The sessionlist is not in fpWeb (although I have planned that), 
only in some private code (the list is obviously protected with a critical section).
What conflicts do you expect ?

Michael.