Changes to fpWeb...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Changes to fpWeb...

Michael Van Canneyt

Hello,

I have committed a serious change to the way fpweb handles requests.

Especially routing of requests was changed.

The old Delphi style routing worked with Datamodules only. The pattern was
strictly /modulename/actionname or through query variables: ?module=xyz&Action=nmo

This old routing is still available by setting the LegacyRouting property of
webhandler or webapplication (custweb) to true. (the new routing described
below is then disabled)

The new routing is more flexible in 3 ways.

- It is no longer required to use datamodules, but this is still supported.
   There are now 4 methods that can be used to register a route:

   - Using a callback procedure
     TRouteCallback = Procedure(ARequest: TRequest; AResponse);

   - Using a callback event:
     TRouteEvent = Procedure(ARequest: TRequest; AResponse) of object;

   - Using an interface
     IRouteInterface = Interface ['{10115353-10BA-4B00-FDA5-80B69AC4CAD0}']
       Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse);
     end;
     Note that this is a CORBA interface, so no reference counting.
     (although a reference counting version could be added, if desired)

   - Using a router object:
     TRouteObject = Class(TObject,IRouteInterface)
     Public
       Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse); virtual; abstract;
     end;
     TRouteObjectClass = Class of TRouteObject;

     The object class needs to be registered. The router will instantiate the
    object and release it once the request was handled.

   - Using a datamodule, as it used to be.

   More methods can be added, if need be.
   All routes are registered using the HTTPRouter.RegisterRoute method.
   it is overloaded to accept any of the above parameters.

- The router can now match more complex, parametrized routes.

   A route is determined by the path part of an URL; query parameters are not examined.

   /path1/path2/path3/path4

   In these paths, parameters and wildcards are recognized:

   :param means that it will match any request with a single part in this location
   *param means that it will match any request with zero or more path parts in this location

   examples:

   /path1
   /REST/:Resource/:ID
   /REST/:Resource
   /*/something
   /*path/somethiingelse
   /*path

   The parameters will be added to TRequest, they are available in the (new) RouteParams array property of TRequest.

   Paths are matched case sensitively by default, and the first matching pattern is used.

   The HTTP Modules are registered in the router using classname/* or defaultmodulename/*

- A set of methods can be added to the route registration (default is to  accept all methods).
   The router will  match the request method. If the method does not match, it will raise an
   exception which will result in a 405 HTTP error.

I have added a demo application. It behaves well, just as the testcases, but I would appreciate
feedback if you have cases where your datamodules no longer behave as they
used to (both with LegacyRouting=true or false)

Some more improvements to fpweb are planned, but they will not be as invasive as this.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Bls: Changes to fpWeb...

Mr Bee
Will this new fpWeb be included in the next FPC release? v.3.2? v.3.0.2?

Thank you.
 

–Mr Bee



Pada Sabtu, 14 Januari 2017 5:36, Michael Van Canneyt <[hidden email]> menulis:



Hello,

I have committed a serious change to the way fpweb handles requests.

Especially routing of requests was changed.

The old Delphi style routing worked with Datamodules only. The pattern was
strictly /modulename/actionname or through query variables: ?module=xyz&Action=nmo

This old routing is still available by setting the LegacyRouting property of
webhandler or webapplication (custweb) to true. (the new routing described
below is then disabled)

The new routing is more flexible in 3 ways.

- It is no longer required to use datamodules, but this is still supported.
  There are now 4 methods that can be used to register a route:

  - Using a callback procedure
    TRouteCallback = Procedure(ARequest: TRequest; AResponse);

  - Using a callback event:
    TRouteEvent = Procedure(ARequest: TRequest; AResponse) of object;

  - Using an interface
    IRouteInterface = Interface ['{10115353-10BA-4B00-FDA5-80B69AC4CAD0}']
      Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse);
    end;
    Note that this is a CORBA interface, so no reference counting.
    (although a reference counting version could be added, if desired)

  - Using a router object:
    TRouteObject = Class(TObject,IRouteInterface)
    Public
      Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse); virtual; abstract;
    end;
    TRouteObjectClass = Class of TRouteObject;

    The object class needs to be registered. The router will instantiate the
    object and release it once the request was handled.

  - Using a datamodule, as it used to be.

  More methods can be added, if need be.
  All routes are registered using the HTTPRouter.RegisterRoute method.
  it is overloaded to accept any of the above parameters.

- The router can now match more complex, parametrized routes.

  A route is determined by the path part of an URL; query parameters are not examined.

  /path1/path2/path3/path4

  In these paths, parameters and wildcards are recognized:

  :param means that it will match any request with a single part in this location
  *param means that it will match any request with zero or more path parts in this location

  examples:

  /path1
  /REST/:Resource/:ID
  /REST/:Resource
  /*/something
  /*path/somethiingelse
  /*path

  The parameters will be added to TRequest, they are available in the (new) RouteParams array property of TRequest.

  Paths are matched case sensitively by default, and the first matching pattern is used.

  The HTTP Modules are registered in the router using classname/* or defaultmodulename/*

- A set of methods can be added to the route registration (default is to  accept all methods).
  The router will  match the request method. If the method does not match, it will raise an
  exception which will result in a 405 HTTP error.

I have added a demo application. It behaves well, just as the testcases, but I would appreciate
feedback if you have cases where your datamodules no longer behave as they
used to (both with LegacyRouting=true or false)

Some more improvements to fpweb are planned, but they will not be as invasive as this.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Changes to fpWeb...

Michael Van Canneyt


On Sun, 15 Jan 2017, Mr Bee wrote:

> Will this new fpWeb be included in the next FPC release? v.3.2? v.3.0.2?
> Thank you. 

It will not be in 3.0.2; That is already at RC1.

It probably will end up in the release following that;
This can be 3.0.4 or 3.2.0...

Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Changes to fpWeb...

Marcos Douglas B. Santos
On Sun, Jan 15, 2017 at 7:45 AM, Michael Van Canneyt
<[hidden email]> wrote:

> On Sun, 15 Jan 2017, Mr Bee wrote:
>
>> Will this new fpWeb be included in the next FPC release? v.3.2? v.3.0.2?
>> Thank you.
>
>
> It will not be in 3.0.2; That is already at RC1.
>
> It probably will end up in the release following that; This can be 3.0.4 or
> 3.2.0...

But it will work if we try to use this new package with the current FPC version?


Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Changes to fpWeb...

Michael Van Canneyt


On Sun, 15 Jan 2017, Marcos Douglas B. Santos wrote:

> On Sun, Jan 15, 2017 at 7:45 AM, Michael Van Canneyt
> <[hidden email]> wrote:
>> On Sun, 15 Jan 2017, Mr Bee wrote:
>>
>>> Will this new fpWeb be included in the next FPC release? v.3.2? v.3.0.2?
>>> Thank you.
>>
>>
>> It will not be in 3.0.2; That is already at RC1.
>>
>> It probably will end up in the release following that; This can be 3.0.4 or
>> 3.2.0...
>
> But it will work if we try to use this new package with the current FPC version?

Yes.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Changes to fpWeb...

Marcos Douglas B. Santos
On Sun, Jan 15, 2017 at 12:00 PM, Michael Van Canneyt
<[hidden email]> wrote:
>> But it will work if we try to use this new package with the current FPC
>> version?
>
>
> Yes.

OK, thanks.


Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Bls: Changes to fpWeb...

Mr Bee
In reply to this post by Michael Van Canneyt
This is really a great news. Thank you, Michael and all other contributors for the great work. 

It would only need more complete documentation with adequate demo and code samples.

Regards,
 

–Mr Bee



Pada Sabtu, 14 Januari 2017 5:36, Michael Van Canneyt <[hidden email]> menulis:



Hello,

I have committed a serious change to the way fpweb handles requests.

Especially routing of requests was changed.

The old Delphi style routing worked with Datamodules only. The pattern was
strictly /modulename/actionname or through query variables: ?module=xyz&Action=nmo

This old routing is still available by setting the LegacyRouting property of
webhandler or webapplication (custweb) to true. (the new routing described
below is then disabled)

The new routing is more flexible in 3 ways.

- It is no longer required to use datamodules, but this is still supported.
  There are now 4 methods that can be used to register a route:

  - Using a callback procedure
    TRouteCallback = Procedure(ARequest: TRequest; AResponse);

  - Using a callback event:
    TRouteEvent = Procedure(ARequest: TRequest; AResponse) of object;

  - Using an interface
    IRouteInterface = Interface ['{10115353-10BA-4B00-FDA5-80B69AC4CAD0}']
      Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse);
    end;
    Note that this is a CORBA interface, so no reference counting.
    (although a reference counting version could be added, if desired)

  - Using a router object:
    TRouteObject = Class(TObject,IRouteInterface)
    Public
      Procedure HandleRequest(ARequest : TRequest; AResponse : TResponse); virtual; abstract;
    end;
    TRouteObjectClass = Class of TRouteObject;

    The object class needs to be registered. The router will instantiate the
    object and release it once the request was handled.

  - Using a datamodule, as it used to be.

  More methods can be added, if need be.
  All routes are registered using the HTTPRouter.RegisterRoute method.
  it is overloaded to accept any of the above parameters.

- The router can now match more complex, parametrized routes.

  A route is determined by the path part of an URL; query parameters are not examined.

  /path1/path2/path3/path4

  In these paths, parameters and wildcards are recognized:

  :param means that it will match any request with a single part in this location
  *param means that it will match any request with zero or more path parts in this location

  examples:

  /path1
  /REST/:Resource/:ID
  /REST/:Resource
  /*/something
  /*path/somethiingelse
  /*path

  The parameters will be added to TRequest, they are available in the (new) RouteParams array property of TRequest.

  Paths are matched case sensitively by default, and the first matching pattern is used.

  The HTTP Modules are registered in the router using classname/* or defaultmodulename/*

- A set of methods can be added to the route registration (default is to  accept all methods).
  The router will  match the request method. If the method does not match, it will raise an
  exception which will result in a 405 HTTP error.

I have added a demo application. It behaves well, just as the testcases, but I would appreciate
feedback if you have cases where your datamodules no longer behave as they
used to (both with LegacyRouting=true or false)

Some more improvements to fpweb are planned, but they will not be as invasive as this.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal