On Fri, 3 Jun 2011, ABorka wrote:
On 6/2/2011 10:46, Leonardo M. Ramé wrote:
>>>>>>> Michael, I added a webmodule to testhttp and got two problems.
>>>>>>>
>>>>>>> 1 - Could not determine HTTP module for request "". Even if I
>>>>>>> call it
>>>>>>> the same way as I use with fpCGI and fpEmbWeb.
>>>>>>
>>>>>> This error usually happens when the project main program does
not
>>>>>> have
>>>>>> the webmodule unit in it's uses statement.
>>>>>
>>>>> I managed to reproduce the error; The error is only apparent if
there
>>>>> are
>>>>> multiple modules registered. I committed a fix in 17647.
>>>>>
>>>>> This raises the question again of the FPWeb behaviour for
>>>>>
>>>>> http://somehost/path
>>>>>
>>>>> Now, 'Path' is interpreted as the name of the action for the
default
>>>>> module.
>>>>>
>>>>> For an embedded server, this is not logical. This should be the
module
>>>>> name, not the action name.
>>>>>
>>>>> Michael.
>>>>
>>>> I disagree. The vast majority of web applications do not need
multiple
>>>> web
>>>> modules (usually the default module is used), but they use
multiple
>>>> actions.
>>>> Therefore, action names should have priority over module names if
only
>>>> one of
>>>> them is passed.
>>>
>>> Hm. My experience is very different:
>>> I didn't make a web application yet that had a single module.
>>> All had at least 3 or 4... And they're all in production.
>>>
>>> Except some demo applications for FPC, they usually have 1 :-)
>>>
>>> Maybe we should introduce 'TWebHandler.PreferModuleName :
Boolean',
>>> which
>>> is
>>> False by default.
>>
>> And you do not specify the actions in the URLs when multiple web
modules
>> are in your application? I think actions are always specified when
web
>> modules are in the calling URL. But it is not true the other way
around.
>
> Well, I never use actions. I always use the OnRequest handler of the
module
> itself.
>
> Michael.
Heh, then we use fpweb differently (as I am sure other people prefer
doing it in many additional ways). :)
I use one single web module with dozens of actions compared to
multiple
web modules with a single request handler that sorts out things. Much
simpler and shorter calling URLs needed this way (an important thing
when encrypting the action name and request Query parameters), and for
me this way gives a nice organized source code in the web module, as
all
functions are nicely separated into action event handlers.
I am sure there are many perfectly good ways - other that the two of
us
are using - to use fpweb.
In my humble opinion, if someone uses Web Actions (and they are there
and highly visible in the object inspector - not like web modules -,
as
well as Delphi-converts most probably know about them already) then
Actions have higher priority than web modules in the calling URLs.
Logically, - as a design paradigm - a web application has more actions
than web modules (not that I can really put a definition on why and
when
multiple web modules would be needed...).
However, if someone is not using Web Actions at all, then this is not
true in the case they use multiple web modules.
But, since your suggestion to add a TWebHandler.PreferModuleName
(Default is False) - or similar - would not break any current
projects,
it would be an easy addition for the above cases.
I also have a question: Could you please list the function of the
multiple web modules in your web applications? I never really saw a
good
use for multiple web modules, but they were implemented more than 10
years ago in Delphi already too, so there must be a reason for that.
I separate the different functionalities in web modules.
Look at the fpwebdata and jsonrpc parts in fcl-web.
I have one module, responsible for handling all data requests.
Another module which handles RPC requests.
A third which takes care of server management routines and producing
HTML/images.
A fourth that handles uploads/downloads of files.
etc.
Modules are rarely very long (a couple of thousand lines at most).
Usually, complete modules can be re-used in another application.
This is harder to do if you are using actions.
Also, since there are several members in a team, each person usually works on
different modules. This keeps the chances of conflicts in SVN minimal.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
