Hi,

• Removed examples that called functions that just aren't there
• Fixed the rest of the examples
• Removed Makefiles
• Ran "go fmt" on everything

Best regards, Alexander Rødseth

This change support Google App Engine. #72

If you merge this change, minimal instruction to setup google appengine with web.go is follow: #1. Setup web.go for google appengine

$ git clone https://github.com/hoisie/web github.com/hoisie/web
$ rm -rf github.com/hoisie/web/.git
$ rm -rf github.com/hoisie/web/Readme.md
$ rm -rf github.com/hoisie/web/LICENSE
$ rm -rf github.com/hoisie/web/Makefile
$ rm -rf github.com/hoisie/web/examples
$ rm  -f github.com/hoisie/web/web_test.go

#2. Write you app

package mattnwebgo

import (
    "github.com/hoisie/web"
    "net/http"
)

func init() {
    web.Get("/", func() string {
        return "hello"
    })

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        web.ServeHTTP(w, r)
    })
}

#3. Add app.yaml

application: your-web-app
version: 1
runtime: go
api_version: go1

handlers:
- url: /static
  static_dir: static
- url: /.*
  script: _go_app

#4. Upload

$ appcfg.py update .

FAQ

If you want to use application context of appengine

package example

import (
    "appengine"
    "appengine/urlfetch"
    "github.com/hoisie/web.go"
    "http"
    "io/ioutil"
)

func init() {
    var c appengine.Context

    web.Get("/", func(ctx *web.Context) {
        client := urlfetch.Client(c)

        r, _, err := client.Get("http://www.getwebgo.com/")
        if err != nil {
            ctx.Abort(500, err.String())
            return
        }
        defer r.Body.Close()
        b, err := ioutil.ReadAll(r.Body)
        if err != nil {
            ctx.Abort(500, err.String())
            return
        }
        ctx.Write(b)
    })

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        c = appengine.NewContext(r)
        web.ServeHTTP(w, r)
    })
}

Starting with the tutorial, I get the following error when trying to go build hello.go

hello.go:4:5: import "github.com/hoisie/web": cannot find package

The following changes were made for Go 1 compatibility.

1. Run go fix to automatically fix some of the code (os.Error -> error, for example)

2. Manually made some changes to timestamps. Use of int64 replaced by either Time or Duration. Some constants would probably be moved to the top.

3. Removed the Heap debug profiler since it doesn't appear to be present in that package anymore. I think the correct behavior is to use Index?

4. Cleaned up the makefile to be only reliant on the go tool.

While you might not take in these changes verbatim, I hope this helps! Not sure how to test locally since it tries to build the examples by installing from your master.

Here's a small example. This doesn't compile because web.Get doesn't like me passing an interface method.

https://gist.github.com/Altonymous/c95c233b21ac7de3b7bc

I've also tried... var webContext *web.Context = new(web.Context) web.Get("/machines/?", s.index(webContext))

I'm not sure if there is a way to do this, but if there is I'd appreciate knowing how.

Assuming you have set up a route like this: web.Get("/album/(.?)/(.?)/info", AlbumInfo)

Requests which contain an encoded slash (%2F) would now break this route, because the route handling is operating on the already url-decoded path. Consider this example:

http://.../album/Manowar+%2F+Friends/Into+Glory+Ride+%2F+Hail+to+England/info

The routing-handler would see this as: http://.../album/Manowar+/+Friends/Into+Glory+Ride+/+Hail+to+England/info

My fix uses the encoded requestURI to detect the right route and then unescapes the specified arguments only before calling the user-handler.

Still having issues compiling this example with golang 1.0.2

time do not have Nanoseconds() func strconv do not have Itoa64 method FormatInt has been suggested (likely easy to fix this one) ctx.Request do not have Params map (reports to be of type *http.Request)

To support this (https://github.com/hoisie/web/issues/105)

func upgradeWebsocketHandler(wsHandler websocket.Handler) interface{} {
        return func(ctx *web.Context) {
                wsHandler.ServeHTTP(ctx.ResponseWriter, ctx.Request);
        }
}

Removed the interface type web.ResponseWriter and replaced with http.ResponseWriter

Log more informations in console:

• all requests (including static files)
• duration
• request ip

If you are ok with this improvement, I'd like to make another PR so that the LogRequest becomes a Config option so that anyone can override the default logging behaviour.

I'd line to also add information about:

• whether this was a file or a handler
• the HTTP status in the response

Sending XML thought POST seems to result in an invalid Params map.

Test by sending some xml with xml header:

.....

curl -d @data/simple-request.xml -H "Content-Type: text/plain;charset=UTF-8 " http://localhost:9999/

func hello(ctx *web.Context, val string) {
    for k,v := range ctx.Params {
        fmt.Print(k)
        fmt.Print(" -> ")
        fmt.Println(v)
    }
    ctx.WriteString("hello")
}
func main() {
    web.Post("/(.*)", hello)
    web.Run("0.0.0.0:9999")
}

This is (almost) my first experience with web development using a compiled language. I've become extremely used to being able to just change my code, and when I refresh the page, it runs differently. I do this literally more than once a minute.

Compiling a binary every time I want to see a change, even if compilation is almost instantaneous, is hard work. I don't think it's a fundamental issue with compiled languages, though -- how about if some scheme like the following was followed:

The system is aware of the source from which it is compiled, and tracks those files for changes. When a new HTTP request comes in, if changes to the source have been made, it dies, recompiles, starts again, and then handles the request. There'd be issues if you're storing application state in memory, but ... I don't.

I should say, this management would be done by another binary rather than the app itself. Let's call it runwebgo, and I can call it as with any other binary. And let's say for my application, called blog, I provide a plaintext file called .runwebgo, which contains:

• a list of relative paths to sourcecode files to watch
• a command to execute when recompilation is required (e.g. make)
• a port on which my running app will listen

Now, instead of running make and then ./blog every time, I just run runwebgo in the top level of my app directory. runwebgo then:

• parses my .runwebgo file for the list of files, the command, and the port
• watches all files for updates, setting a changed flag when a file changes
• starts up my app
• runs as a web server (in exactly the same way as a normal web.go app) listening on some odd port (other than the 9999 or 80 which I may have my app configured to)
• every time a request is received, it checks the changed flag. If things have changed, it kills my app, recompiles it, re-runs it. In either case, it then sends on the request to the port of my app.
• when it is killed, it kills my app as well.

It could also observe changes to the .runwebgo file itself, and dynamically update the source list if I resave it.

I imagine creating this would not be too hard or use anything outside the standard library. The upshot IMO is massive: I just run one command and leave it for my whole coding session.

Since the context package is part of standard library, I think we should support it.

And web.go had a struct called Context and is used to passing values to handler, I think we can reuse it as a context.Context interface. The easist way to do it is embed the context.Context from http.Request.Context() to web.go's Context.

Fix the format error and let latest go compile can compile it.

Bumped the go version in .travis file also, dropped old version go support, because some dependency package is not supported and can't compiled on this versions.

Every exported function in a program should have a doc comment. The first sentence should be a summary that starts with the name being declared. From effective go.

PR generated by CodeLingo. Install here to drive Continuous Higher Standards.