[fpc-devel] Questions and suggestions to fpWeb

[Luiz Americo Pereira Camara]

Michael Van Canneyt escreveu:
>
>
> On Tue, 3 Aug 2010, Luiz Americo Pereira Camara wrote:
>
>> Michael Van Canneyt escreveu:
>>>
>>>
>>> On Fri, 30 Jul 2010, Luiz Americo Pereira Camara wrote:
>>>
>>>> Hi,
>>>>
>>>> I've playing a bit with fpWeb and have some suggestions and questions:
>>>>
>>>> - In TFPWebAction.DoHandleRequest if request is not handled by 
>>>> OnRequest and inherited, the content is copied to the response and 
>>>> handled is checked by the response content.
>>>> - FContensts will be always created even if is not created previously
>>>> - At this point AResponse.Contents can have some content?
>>>> - If so the handled checking is wrong. See these conditions
>>>>    AResponse.Contents.Text <> '';
>>>>    Self.Contents.Text = '';
>>>>    Handled will be true. Should be false.
>>>
>>> Why ? It is handled ?
>>
>> No. Because TWebAction.Contents is empty.
>
> But that can be a perfectly valid result ?

Yes. But in this case the appropriate way to mark as handled is to set 
Handled in OnRequest.

Moreover, how to leave Handled as false if even an empty Contents is 
treated as a value that affects the Handled state?

>>>> - Content and Contents properties are redundant. Also can lead to 
>>>> some performance issues. See the code of DoGetContent:
>>>>
>>>>   If (Self.Content<>'') then
>>>>     Content.Write(Self.Content[1],Length(Self.Content));
>>>>
>>>> Content is computed (Contents items concatenated) three times.
>>>>
>>>> Don't be surprised if users do things like
>>>>
>>>> while  not ready do
>>>> Content := Content + 'xxx';
>>>
>>> I agree that the contents/content properties should be reduced to 1
>>> property. But this is a change which will break backwards 
>>> compatibility.
>>
>> AFAIK the fpWeb interface is still in progress. Anyway, better change 
>> now than later.
>
> The question is: which one ?

Contents is more versatile and does not lead to performance pitfalls 
like using it as a simple AnsiString property


[..]
>>
>> OK. BTW what's the intention of adding TWebHandler AFAIK only add 
>> another layer.
>
> There is a simple reason: if you want to have a service application, 
> there
> will be 2 application objects. Now you can have only 1 application object
> (service application) which uses the webhandler to process requests.
>
> You can now also produce 1 binary which can be configured to run as a
> CGI/FCGI/Service/standalone server, and which will have 1 single 
> application
> instance for all 4 cases.

Good.

Do you have an simple example of such program?

Luiz