[Lazarus] GUI development for web UI

[Marcos Douglas]

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?

Marcos Douglas