Add support for url.URL argument type
oakad opened this issue · 7 comments
Urls are pretty common args to go apps and it makes sense to support url validation early on. The alternative is to rely on rather ugly boilerplate in all apps in need of that feature.
The example of ugly boilerplate that better be hidden inside the lib:
type urlValue struct {
u *url.URL
}
func (uv *urlValue) Parse(s string) error {
u, err := url.Parse(s)
*uv.u = *u
return err
}
cli.RegisterFlagParser("urlParser", func(ptr interface{}) cli.FlagParser {
return &urlValue{
u: ptr.(*url.URL),
}
})
Is "Reader read from url", #34, what you are looking for?
If yes, take a look at
https://github.com/suntong/cascadia#twitter-search
Not at all.
I'm talking about situations of:
app -arg http://google.com
with args struct:
type rootArgs struct {
cli.Helper
someArg url.URL `cli:"arg" usage:"give me some url"`
}
Oh, ok. Is url.URL
something new or already supported?
Something new compared to what? It's an stdlib type (import net/url
), which can parse and validate urls. I'm using it right now with a help of a custom parser boilerplate (as outlined in my OP). However, considering that validating urls is a pretty common task in Go world, I hoped that it can be incorporated into the "cli" library as one of the basic types (similar to string and int).
@mkideal is not active nowadays as he used to be.
Previously bugs get fixed within days, usually within 48 or even 24 hours.
Now he's in sleeping mode that nobody seems to be able to wake him up.
I mean, you'll have better chances if you submit a PR, with some well-thought test cases covered.
I have decided to abstain from PRs on github these days. :-)
Everybody says, "submit a PR", but when someone does it always deteriorates into a never ending PR-ball, which usually makes a rather lousy pastime.
oh, that's an odd story, but good to hear.