[QUESTION] Inconsistent naming

[tuhao1020]

1. to get query parameters from a request, there are two methods: ctx.ReadQuery and ctx.URLParam (ctx.URLParamSlice) but the names are inconsistent.

why not use ctx.ReadQuery and ctx.QueryParam (ctx.QueryParamSlice) ？

2. FormValue method comment says that it returns a single parsed form value by its "name", including both the URL field's query parameters and the POST or PUT form data. its name is FormValue but it can parsed from URL, is it a bit weird?

[kataras]

Hello @tuhao1020

Look, the ctx.ReadQuery binds a Go structure to the URL query parameters, the ctx.URLParam returns a string value of a single URL query parameter, the ctx.URLParamSlice returns a []string of a single url query parameter (e.g. &names=makis&names=tuhao). I don't like the URLParamSlice name too, but the inconsistent naming is to not break the existing URLParams method which returns a map of the URL query parameters.

About the FormValue, I don't understand the confusion, the go standard library works the same, the HTML form values can be part of URL Query too.

[kataras]

However, if you have any suggestions please say so. I really don't want to break the existing URLParams though, many users use that method...

[tuhao1020]

@kataras In Java it is called query param, so when I saw URLParam and ReadQuery, I thought they meant something different, but in fact, both of them are actually get query param(s) from url. I don't suggest to change the method name, that will lead to compatibility issues, but I think you can add new method such as QueryParam and do the same things that URLParam do. Java programmers will welcome such changes.

I don't know about FormValue in standard library, if so, I would only say the standard library is a little strange, too. 😄

[kataras]

So you proposing adding a QueryParam and call the URLParam as it's? This will not lead to confusion to the users? :/

[tuhao1020]

This is also a problem :(

Methods in Java can be marked as deprecated, but Go seems to have no such mechanism. 😞

[kataras]

That's not our only problem, if we add QueryParam we must also add QueryParamXXX of all URLParamXXX methods, such as URLParamDefault, URLParamExists and 4-5 more..

[AlbinoGeek]

Perhaps then the easier thing to do is have a function alias ReadQuery -> ReadURL -- it even makes sense phonetically. You are reading the URL Parameters into a struct.

[kataras]

@AlbinoGeek I though of ReadURL before but URL may imply collect path parameters too, not only URL queries....Maybe we can add a ReadURL which will read both URL Query and dynamic path parameters, we already have a ReadParams for binding dynamic URL path parameters, so a ReadURL can be a shortcut of ReadQuery+ReadParams , sounds ok?

[kataras]

Example Code:

package main

import (
    "github.com/kataras/iris/v12"
)

type myURL struct {
    Name string   `url:"name"` // or `param:"name"`
    Age  int      `url:"age"`  // >> >>
    Tail []string `url:"tail"` // >> >>
}

func main() {
    app := newApp()

    // http://localhost:8080/iris/web/framework?name=kataras&age=27
    // myURL: main.myURL{Name:"kataras", Age:27, Tail:[]string{"iris", "web", "framework"}}
    app.Listen(":8080")
}

func newApp() *iris.Application {
    app := iris.New()

    app.Get("/{tail:path}", func(ctx iris.Context) {
        var u myURL
        // ReadURL is a shortcut of ReadParams + ReadQuery.
        if err := ctx.ReadURL(&u); err != nil {
            ctx.StopWithError(iris.StatusInternalServerError, err)
            return
        }

        ctx.Writef("myURL: %#v", u)
    })

    return app
}