Moving controller to a sub-package fails to map REST methods properly

[oleksandr]

What I did is taking an example web-server and moving out the ThingsController into the ./controllers sub-package:

package controllers

import ( "github.com/stretchrcom/goweb" "github.com/stretchrcom/goweb/context" "net/http" )

// ThingsController is the RESTful MVC controller for Things. type ThingsController struct { }

// Before gets called before any other method. func (r *ThingsController) Before(ctx context.Context) error { return nil }

// After gets called before any other method. func (r *ThingsController) After(ctx context.Context) error { return nil }

func (r *ThingsController) Create(ctx context.Context) error { return goweb.Respond.WithStatus(ctx, http.StatusCreated) }

func (r *ThingsController) ReadMany(ctx context.Context) error { return goweb.API.RespondWithData(ctx, "DEMO!") }

func (r *ThingsController) Read(id string, ctx context.Context) error { return goweb.Respond.WithStatus(ctx, http.StatusNotFound) }

func (r *ThingsController) DeleteMany(ctx context.Context) error { return goweb.Respond.WithOK(ctx) }

func (r *ThingsController) Delete(id string, ctx context.Context) error { return goweb.Respond.WithOK(ctx) }

Then mapped it using:

goweb.MapController("/api/things", new(controllers.ThingsController))

As a result:

Pipe 0: *\ - 0x35e0

Pipe 1: / - 0x3a50 OPTIONS /api/things - 0xe9240 OPTIONS /api/things/{id} - 0xe9340 *\ - 0x3b20

Pipe 2: *\ - 0x36b0

The other REST methods are not mapped and requests return 404. Moving the code back into the same main.go makes things work again.

[matryer]

How weird -

I will look at that today. Feel free to write a test to prove it? If not, I will later.

Mat

Sent from my iPhone

On 12 Jun 2013, at 06:42, Oleksandr Lobunets notifications@github.com wrote:

What I did is taking an example web-server and moving out the ThingsController into the ./controllers sub-package:

package controllers

import ( "github.com/stretchrcom/goweb" "github.com/stretchrcom/goweb/context" "net/http" )

// ThingsController is the RESTful MVC controller for Things. type ThingsController struct { }

// Before gets called before any other method. func (r *ThingsController) Before(ctx context.Context) error { return nil }

// After gets called before any other method. func (r *ThingsController) After(ctx context.Context) error { return nil }

func (r *ThingsController) Create(ctx context.Context) error { return goweb.Respond.WithStatus(ctx, http.StatusCreated) }

func (r *ThingsController) ReadMany(ctx context.Context) error { return goweb.API.RespondWithData(ctx, "DEMO!") }

func (r *ThingsController) Read(id string, ctx context.Context) error { return goweb.Respond.WithStatus(ctx, http.StatusNotFound) }

func (r *ThingsController) DeleteMany(ctx context.Context) error { return goweb.Respond.WithOK(ctx) }

func (r *ThingsController) Delete(id string, ctx context.Context) error { return goweb.Respond.WithOK(ctx) }

Then mapped it using:

goweb.MapController("/api/things", new(controllers.ThingsController))

As a result:

Pipe 0: *\ - 0x35e0

Pipe 1: / - 0x3a50 OPTIONS /api/things - 0xe9240 OPTIONS /api/things/{id} - 0xe9340 *\ - 0x3b20

Pipe 2: *\ - 0x36b0

The other REST methods are not mapped and requests return 404. Moving the code back into the same main.go makes things work again.

— Reply to this email directly or view it on GitHub.

[oleksandr]

I will now.

[oleksandr]

Weird, just wrote a simple test and it worked fine. After comparing line by line figured out that problem was here:

import ( "github.com/stretchrcom/goweb" "github.com/stretchrcom/goweb/context" "net/http" )

This didn't produce any of compilation or runtime errors. But changing it to:

import ( "github.com/stretchr/goweb" "github.com/stretchr/goweb/context" "net/http" )

has solved the issue. Now methods a mapped properly.

[matryer]

That is strange! We just got an improved repo name stretchf instead of stretchrcom, so were worried this might break things for people.

Maybe it didn't product an error because the stretchrcom packages were still there... but then why didn't it work?

Weirdest Goweb Bug of the Year award goes to you, congratulations.

I'll add a note to the homepace.