Documentation
¶
Overview ¶
Package controllers holds this application's controllers.
The directory is app/Http/Controllers, in CamelCase, which is where people look for it. The package name follows Go and stays lowercase.
A controller reads the request, calls a service and renders. It never reaches the database: a controller holding a repository is a controller that skipped the service, and therefore skipped the policy, and `aru doctor` refuses it.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Controller ¶
type Controller struct{}
Controller is the type every controller in this directory embeds.
It carries no dependencies, and that is deliberate. A base controller that grows authorize(), validate() and dispatch() grows them because there is nowhere else to put them, and each one hides a collaborator. Here it holds only what is about answering a request, and a controller's collaborators are fields it declares and the constructor sets.
func (Controller) Invalid ¶
Invalid answers a failed validation with the fragment HTMX swaps back in.
The status is 422, not 200. A form that answers 200 with the errors in it tells the browser, the logs and every dashboard that the write succeeded -- and HTMX still swaps the fragment either way, so nothing looks wrong until somebody asks why the success rate is 100%.
func (Controller) Validated ¶
func (Controller) Validated(errs validation.Errors) bool
Validated reports whether a request passed validation, and answers the caller when it did not.
if errs := req.Validate(); !c.Validated(errs) { ... }
It exists so the check reads the same in every controller. What it does not do is decide the response: the view and its data are the page's business, and a base class that picked them would be a second router.
type HomeController ¶
type HomeController struct {
Controller
// contains filtered or unexported fields
}
HomeController answers the landing page.
It is the smallest complete example of the shape: a struct, a constructor that takes what it needs, and one method per route that returns an error.
func NewHomeController ¶
func NewHomeController(appName string, sessions *security.SessionStore, csrf *security.CSRF, people *auth.Service, tenant string) *HomeController
NewHomeController returns the controller. `bootstrap` builds it and hands it to the routes.
The parameter list is the one `go run github.com/arandu-io/ui@latest auth` publishes, and it has to stay that way. That command replaces this file with no flag at all -- the layout and the pages that extend it are one unit -- and a constructor it emits that bootstrap/app.go does not call is a project that stops compiling on a command whose whole promise is that it can be run again.
func (*HomeController) Index ¶
func (c *HomeController) Index(ctx *http.Context) error
Index renders the landing page.
The data is views.HomeData, the struct the view itself declares. Hand it anything else and the build fails, naming both sides -- which is the whole reason the view is compiled instead of interpreted.
view.Page is the chrome the layout draws, embedded rather than repeated. The navigation draws a link only for what answers: the skeleton registers the framework's sign-in route and nothing else, so registration stays off until there is a handler behind it -- a link to a route nobody registered is a 404 the layout put there.
Source Files