Pet Tracker · Amber V2
Track the animals moving through the foster network.
Add a petField note
<%= escape_html(article[:summary]) %>
<%= render(partial: "articles/_meta.ecr") %>Time remaining: 30
``` Escape user-controlled attribute values. The view owns the value; the controller owns reusable behavior. ## Build and verify **Run from: the application root after every module change.** ```bash amber assets build amber assets check crystal spec amber watch ``` Verify in order: 1. the manifest contains the application and every controller logical path; 2. the one import map contains fingerprinted local URLs and the intended pinned Stimulus URL; 3. every mapped response returns `200` with a JavaScript content type; 4. the controller connects and the keyboard and pointer interaction work; 5. navigation away cleans up timers and listeners; and 6. the browser console contains no import-map, CSP, or module errors. Trace failures through the actual ownership chain: `app/assets/javascript/` source → `amber assets build` → `public/assets/manifest.json` → `src/views/layouts/application.ecr` → the `data-controller` element. --- ## Configuration Canonical page: https://amberframework.org/docs/v2/guides/assets/configuration # Asset Pipeline configuration > **Supported web path:** This is the asset contract generated by Amber CLI > `2.0.6` for Amber `2.0.0-beta.5` and asset_pipeline `0.37.0`. Complete [Asset Pipeline](../) first. Every filesystem path below is resolved from the application root, beside `shard.yml`. ## Keep build-time and runtime responsibilities separate **File: `config/assets.cr` — this complete generated file configures only the runtime manifest resolver.** ```crystal Amber::Assets.configure( manifest_path: "public/assets/manifest.json" ) ``` Do not require the compiler from `config/assets.cr`. That file is loaded into the running server, which only needs Amber's resolver. Keeping the compiler in the CLI or a build script prevents release tooling from becoming an accidental runtime dependency. The three paths have different owners: | Setting | Value | Owner | |---|---|---| | `source_root` | `app/assets` | source files developers edit | | `output_root` | `public/assets` | generated release files | | `public_path` | `/assets` | URLs emitted into the manifest | Never point `source_root` and `output_root` at the same directory. Never store uploads in either directory. The build is allowed to replace generated output; it must not delete application source or runtime data. Nested logical paths are preserved. **Reference structure — authored source files:** ```text app/assets/stylesheets/app.css app/assets/javascript/controllers/menu.js app/assets/images/marketing/hero.webp app/assets/fonts/Manrope-Variable.woff2 ``` remain distinct logical entries with the same relative paths, even though the emitted filenames include content digests. Directory preservation prevents two files such as `admin/logo.svg` and `store/logo.svg` from colliding. **File: `scripts/build_assets.cr` — an existing pre-2.0.5 application can use this complete build-only wrapper.** ```crystal require "asset_pipeline/static_assets" AssetPipeline::StaticAssets::Compiler.new( source_root: Path["app/assets"], output_root: Path["public/assets"], public_path: "/assets" ).build ``` ## Configure Amber's resolver **File: `src/my_app.cr` — verify the application entry point loads top-level configuration before controllers and models.** ```crystal require "../config/*" ``` Replace `my_app` with the target name. The generated V2 entry point uses that wildcard, so `config/assets.cr` is loaded. If a migrated app has a narrower require list, add `require "../config/assets"` explicitly after the configuration file that loads Amber. Do not put the setup in the empty `config/initializers/` directory unless the app explicitly requires it. The resolver is strict for logical paths. A missing entry is a build or deploy failure to fix, not a reason to fall back silently to an unhashed URL. External URLs, absolute application paths, fragments, and `data:` URLs pass through. ## Inspect the manifest directly Application views should normally use Amber's helpers. Build tooling can load the same manifest directly when it needs structured metadata. **File: a build verification program, for example `scripts/verify_assets.cr` — create this complete file.** ```crystal require "asset_pipeline/static_assets" manifest = AssetPipeline::StaticAssets::Manifest.load( Path["public/assets/manifest.json"] ) manifest.verify(Path["public/assets"]) puts manifest.path("stylesheets/app.css") puts manifest.integrity("stylesheets/app.css") entry = manifest.entry("fonts/Manrope-Variable.woff2") puts "#{entry.content_type} #{entry.bytes} bytes" ``` Each entry records its public path, full SHA-256 digest, SRI value, content type, and byte count. `verify` checks those values against the emitted bytes and deterministic gzip companions. `path`, `integrity`, and `entry` are strict lookups; a miss stops release verification. **Run from: the application root, after building assets.** ```bash crystal run scripts/verify_assets.cr ``` ## CSS references **File: `app/assets/stylesheets/app.css` — use paths relative to this source stylesheet for local authored files.** ```css @font-face { font-family: "Manrope"; src: url("../fonts/Manrope-Variable.woff2") format("woff2"); font-display: swap; } .hero { background-image: url("../images/marketing/hero.webp"); } ``` The build rewrites those local references to the fingerprinted public paths. Keep an external URL, root-absolute URL, fragment, or data URL only when that is deliberately outside the manifest. A missing relative file is an error. Relative CSS `@import` references are rewritten too. Query strings and fragments on a local reference are preserved after the fingerprinted path. The compiler also rewrites relative static imports, exports, dynamic imports, and source-map references in browser-ready JavaScript. Bare module names stay unchanged so an import map can resolve them. Asset Pipeline copies the bytes supplied to it. Generate real responsive image sizes and formats in an earlier deterministic build step if the application needs them, then put every emitted variant under `app/assets/images/` and list the real logical paths in `srcset` or `Status: ok
``` **Run from: the application root while `amber watch` is running.** ```bash curl -H 'Accept: application/json' http://127.0.0.1:3000/status curl http://127.0.0.1:3000/status.json curl http://127.0.0.1:3000/status.md ``` Keep serialization explicit. For typed request parsing and structured API errors, use the [Schema API](../schema-api/index.md). --- ## Cookies Canonical page: https://amberframework.org/docs/v2/guides/controllers/cookies # Cookies Cookies are read and written through **Amber::Base::Controller\#cookies**. The cookies being read are the ones received along with the request, the cookies being written will be sent out with the response. Reading a cookie does not get the cookie object itself back, just the value it holds. It's advisable that you only store simple data \(strings and numbers\) in cookies. If you have to store complex objects, you would need to handle the conversion manually when reading the values on subsequent requests. Amber also has an encrypted cookie jar for storing sensitive data. The encrypted cookie jar encrypts the values in addition to signing them, so that they cannot be read by the end user. ## Examples of writing ```crystal class CommentsController < ApplicationController def new # Auto-fill the commenter's name if it has been stored in a cookie @comment = Comment.new(author: cookies[:commenter_name]) end def create @comment = Comment.new(params[:comment]) if @comment.save flash[:notice] = "Thanks for your comment!" if params[:remember_name] # Remember the commenter's name. cookies[:commenter_name] = @comment.author else # Delete cookie for the commenter's name cookie, if any. cookies.delete(:commenter_name) end redirect_to @comment.article else render action: "new" end end end ``` ## Examples of reading ```crystal cookies[:user_name] # => "david" cookies.size # => 2 JSON.parse(cookies[:lat_lon]) # => [47.68, -122.37] cookies.encrypted[:discount] # => 45 ``` Please note that if you specify a :domain when setting a cookie, you must also specify the domain when deleting the cookie: ```crystal cookies.set "name", "a yummy cookie", expires: 1.year.from_now, domain: "domain.com" cookies.delete "name", domain: "domain.com" ``` The optional parameters for setting cookies are: ```crystal path # The path for which this cookie applies. Defaults to the root of the application. domain # The domain for which this cookie applies so you can restrict to the domain level. # If you use a schema like www.example.com and want to share session with user.example.com # set :domain to :all. Make sure to specify the :domain option with :all or Array again # when deleting cookies. domain: nil # Does not set cookie domain. (default) domain: :all # Allow the cookie for the top most level domain and subdomains. domain: %w(.example.com .example.org) # Allow the cookie for concrete domain names. tld_length # When using :domain => :all, this option can be used to explicitly set the TLD length # when using a short (<= 3 character) domain that is being interpreted as part of a TLD. # For example, to share cookies between user1.lvh.me and user2.lvh.me, set :tld_length to 1. expires # The time at which this cookie expires, as a Time object. secure # Whether this cookie is only transmitted to HTTPS servers. Default is false. httponly # Whether this cookie is accessible via scripting or only HTTP. Defaults to false. ``` --- ## Filters Canonical page: https://amberframework.org/docs/v2/guides/controllers/filters # Filters Filters are methods that are run "before", "after" or "around" a controller action. Filters are inherited, so if you set a filter on`ApplicationController`, it will be run on every controller in your application. ## Before filter "before" filters may halt the request cycle. A common "before" filter is one which requires that a user is logged in for an action to be run. You can define the filter method this way: ```crystal # Filters are methods that are run "before", "after" a controller action. before_action do # runs for specified actions only [:index, :world, :show] { increment(1) } # runs for all actions all { increment(1) } end ``` ## After filter "after" filters are executed after the request cycle. A common "after" filter is one which requires to cleanup user data after an action has been run. You can define the filter method this way: ```crystal after_action do # runs for specified actions only [:index, :world] { increment(1) } end ``` --- ## Flash Canonical page: https://amberframework.org/docs/v2/guides/controllers/flash # Flash The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available on the next request, which is useful for passing error messages etc. ## Accessing the flash scope It is accessed in much the same way as the session, as a hash. Let's use the act of logging out as an example. The controller can send a message which will be displayed to the user on the next request: ```crystal class LoginsController < ApplicationController def destroy session[:current_user_id] = nil # Alternatively, `flash.notice=` could be use. flash[:notice] = "You have successfully logged out." redirect_to root_url end end ``` ## Rendering the flash message ```markup