boltless.me
targeting
master
from
sl/uvpzuszrulvq
Obviously file naming of appview/web/handler/*.go files are directly against to go convention. Though I think flattening all handler files can significantly reduce the effort involved in file naming and structuring. We are already grouping core services by domains, and doing same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee git@boltless.me
tangled.org
oauth.User type
oauth.MultiAccountUser
MultiAccountUser.Active from template
.Handle from oauth.AccountInfo
AuthReturnInfo
AddAccount session data
Pds field from oauth.User
None yet.
None yet.
This patch was likely rebased, as context lines do not match.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
This file has not been changed.
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : domain-level services
```
Each handlers are pure by receiving all required dependencies as
parameters. Ideally we should not pass base dependencies like `db`, but
that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee <git@boltless.me>