RejectedSoftware Forums

Sign up

Utilizing registerFormInterface

Hi,

I would like to ask about registerFormInterface(). I read several examples (including whats in the unittest) but I would like to get a clear answer:

  1. Does the registerFormInterface makes it so that if I want todo a GET or a POST, I have to do something like class app{void getAccount(...){res.render!("account.dt", req);}} and access it by doing http://example.com/account ? I mean does it turn the account.dt into a accessible page for GET or POST or am I missing something?

  2. Is there a performance difference when using registerFormInterface compare do just registering each url by doing auto router = new URLRouter; router.get("/account",&account); ?

  3. How customizible is the registerFormInterface other than what the examples show? Is there a easier way than using registerFormInterface possibly with user defined annotations to define the url, http method, before the function?

Thank you and sorry if Im not clear. I am typing this late at night because I am still porting more of my code from node.js to vibe.d.

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 06:29:36 GMT, Darius Clark wrote:

Hi,

I would like to ask about registerFormInterface(). I read several examples (including whats in the unittest) but I would like to get a clear answer:

First off, for new code, I'd strongly recommend to use the newer vibe.web.web module, if possible, which is basically a re-implementation of the form interface module, but based on the same generic foundation as the rest interface module. registerFormInterface will get deprecated and removed at some point (not in the near future, though).

However, the new module doesn't yet have all the features available. Most notably, struct type parameters are not yet properly projected as form fields. I'll add some missing functionality and some examples in the coming days, when I port one of my projects to use it.

  1. Does the registerFormInterface makes it so that if I want todo a GET or a POST, I have to do something like class app{void getAccount(...){res.render!("account.dt", req);}} and access it by doing http://example.com/account ? I mean does it turn the account.dt into a accessible page for GET or POST or am I missing something?

That's right. The vibe.web.web module would just add a route for GET (according to the method prefix), while the registerFormInterface would accept both, GET and POST.

  1. Is there a performance difference when using registerFormInterface compare do just registering each url by doing auto router = new URLRouter; router.get("/account",&account); ?

No, they should be more or less exactly the same.

  1. How customizible is the registerFormInterface other than what the examples show? Is there a easier way than using registerFormInterface possibly with user defined annotations to define the url, http method, before the function?

vibe.web.web supports this using @method and @path annotations (see the documentation of vibe.web.rest for some examples). It also has some additional features, such as defining an InputStream parameter that gets the raw request body, returning an InputStream that is used to source the response body, and support for session local variables. There is also a little example project, which shows the basic usage.

Thank you and sorry if Im not clear. I am typing this late at night because I am still porting more of my code from node.js to vibe.d.

That noble goal definitely excuses everything ;) Let me know if anything is missing.

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 07:17:43 GMT, Sönke Ludwig wrote:

On Fri, 09 May 2014 06:29:36 GMT, Darius Clark wrote:

Hi,

I would like to ask about registerFormInterface(). I read several examples (including whats in the unittest) but I would like to get a clear answer:

First off, for new code, I'd strongly recommend to use the newer vibe.web.web module, if possible, which is basically a re-implementation of the form interface module, but based on the same generic foundation as the rest interface module. registerFormInterface will get deprecated and removed at some point (not in the near future, though).

However, the new module doesn't yet have all the features available. Most notably, struct type parameters are not yet properly projected as form fields. I'll add some missing functionality and some examples in the coming days, when I port one of my projects to use it.

  1. Does the registerFormInterface makes it so that if I want todo a GET or a POST, I have to do something like class app{void getAccount(...){res.render!("account.dt", req);}} and access it by doing http://example.com/account ? I mean does it turn the account.dt into a accessible page for GET or POST or am I missing something?

That's right. The vibe.web.web module would just add a route for GET (according to the method prefix), while the registerFormInterface would accept both, GET and POST.

  1. Is there a performance difference when using registerFormInterface compare do just registering each url by doing auto router = new URLRouter; router.get("/account",&account); ?

No, they should be more or less exactly the same.

  1. How customizible is the registerFormInterface other than what the examples show? Is there a easier way than using registerFormInterface possibly with user defined annotations to define the url, http method, before the function?

vibe.web.web supports this using @method and @path annotations (see the documentation of vibe.web.rest for some examples). It also has some additional features, such as defining an InputStream parameter that gets the raw request body, returning an InputStream that is used to source the response body, and support for session local variables. There is also a little example project, which shows the basic usage.

Thank you and sorry if Im not clear. I am typing this late at night because I am still porting more of my code from node.js to vibe.d.

That noble goal definitely excuses everything ;) Let me know if anything is missing.

Hello,

Thank you for your reply. I am looking through the example, and would like to know if theres a way to accept something like /example/:id ? Do I use "HTTPServerResponse res" to fetch the params from the url along with any other parameters?

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 07:42:17 GMT, Darius Clark wrote:

Hello,

Thank you for your reply. I am looking through the example, and would like to know if theres a way to accept something like /example/:id ? Do I use "HTTPServerResponse res" to fetch the params from the url along with any other parameters?

This can be done using an explicit path and "generic" parameters prefixed with an underscore. I'll add a proper example to the documentation.

@path("/example/:id")
void getExample(int _id)
{
    // ...
}

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 07:58:53 GMT, Sönke Ludwig wrote:

On Fri, 09 May 2014 07:42:17 GMT, Darius Clark wrote:

Hello,

Thank you for your reply. I am looking through the example, and would like to know if theres a way to accept something like /example/:id ? Do I use "HTTPServerResponse res" to fetch the params from the url along with any other parameters?

This can be done using an explicit path and "generic" parameters prefixed with an underscore. I'll add a proper example to the documentation.

@path("/example/:id")
void getExample(int _id)
{
    // ...
}

Thank you :) Just to clarify could I do

@path("/example/:id")
void getExample(int _id){

}

@path("/example/:id/:next")
void getExample(int _id, string _next){

}

so I could define a path without it depending/relying on the name of the diet file? Since my diet files are like home.index.dt, home.blog.dt, etc (as you suggested in a previous topic), I dont want it to contain links like that.

Thank you again for your replies. This will make my code easier to review and cleaner.

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 08:08:27 GMT, Darius Clark wrote:

On Fri, 09 May 2014 07:58:53 GMT, Sönke Ludwig wrote:

On Fri, 09 May 2014 07:42:17 GMT, Darius Clark wrote:

Hello,

Thank you for your reply. I am looking through the example, and would like to know if theres a way to accept something like /example/:id ? Do I use "HTTPServerResponse res" to fetch the params from the url along with any other parameters?

This can be done using an explicit path and "generic" parameters prefixed with an underscore. I'll add a proper example to the documentation.

@path("/example/:id")
void getExample(int _id)
{
    // ...
}

Thank you :) Just to clarify could I do

@path("/example/:id")
void getExample(int _id){

}

@path("/example/:id/:next")
void getExample(int _id, string _next){

}

so I could define a path without it depending/relying on the name of the diet file? Since my diet files are like home.index.dt, home.blog.dt, etc (as you suggested in a previous topic), I dont want it to contain links like that.

Thank you again for your replies. This will make my code easier to review and cleaner.

Definitely. The Diet templates are rendered with the explicit file name and the special vibe.web.web.render!() template, which doesn't need an explicit HTTPServerResponse parameter, so they are completely independent:

@path("/example/:id/:next")
void getExample(int _id, string _next)
{
    render!("home.something.example.dt", ...);
}

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 08:31:35 GMT, Sönke Ludwig wrote:

On Fri, 09 May 2014 08:08:27 GMT, Darius Clark wrote:

On Fri, 09 May 2014 07:58:53 GMT, Sönke Ludwig wrote:

On Fri, 09 May 2014 07:42:17 GMT, Darius Clark wrote:

Hello,

Thank you for your reply. I am looking through the example, and would like to know if theres a way to accept something like /example/:id ? Do I use "HTTPServerResponse res" to fetch the params from the url along with any other parameters?

This can be done using an explicit path and "generic" parameters prefixed with an underscore. I'll add a proper example to the documentation.

@path("/example/:id")
void getExample(int _id)
{
    // ...
}

Thank you :) Just to clarify could I do

@path("/example/:id")
void getExample(int _id){

}

@path("/example/:id/:next")
void getExample(int _id, string _next){

}

so I could define a path without it depending/relying on the name of the diet file? Since my diet files are like home.index.dt, home.blog.dt, etc (as you suggested in a previous topic), I dont want it to contain links like that.

Thank you again for your replies. This will make my code easier to review and cleaner.

Definitely. The Diet templates are rendered with the explicit file name and the special vibe.web.web.render!() template, which doesn't need an explicit HTTPServerResponse parameter, so they are completely independent:

@path("/example/:id/:next")
void getExample(int _id, string _next)
{
    render!("home.something.example.dt", ...);
}

Thank you again :)

I do not know if this was meant to be but the vibe.web.web is not in vibe.d.

Re: Utilizing registerFormInterface

Am 09.05.2014 10:38, schrieb Darius Clark:

I do not know if this was meant to be but the vibe.web.web is not in vibe.d.

It only exists since the latest version 0.7.19, released on the 9th of
April. Maybe you need to upgrade?

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 11:40:30 +0200, Sönke Ludwig wrote:

Am 09.05.2014 10:38, schrieb Darius Clark:

I do not know if this was meant to be but the vibe.web.web is not in vibe.d.

It only exists since the latest version 0.7.19, released on the 9th of
April. Maybe you need to upgrade?

Yes I went on and upgraded from 0.7.19-openssl to 0.7.20 beta and it seems to work now. Thank you :)

Last question, how are sessions handled using this method?

Re: Utilizing registerFormInterface

On Fri, 09 May 2014 10:23:31 GMT, Darius Clark wrote:

On Fri, 09 May 2014 11:40:30 +0200, Sönke Ludwig wrote:

Am 09.05.2014 10:38, schrieb Darius Clark:

I do not know if this was meant to be but the vibe.web.web is not in vibe.d.

It only exists since the latest version 0.7.19, released on the 9th of
April. Maybe you need to upgrade?

Yes I went on and upgraded from 0.7.19-openssl to 0.7.20 beta and it seems to work now. Thank you :)

Last question, how are sessions handled using this method?

You can use member variables of type SessionVar!T to store data in a session. Setting a session variable will automatically start a new session if none is already running. For manual session access, you can define function parameters of type HTTPServerResponse and/or HTTPServerRequest to access startSession and terminateSession.

See also postLogin and postLogout in the example project.