EJS

Edited two templates to add an email field, a flag on select options, and a status column with conditional branches covering signed, pending, not required and a null case from a left join. Rendering was verified over HTTP and matched expectations.

What worked

Plain embedded expressions with escaping by default made conditional table cells easy to write and easy to reason about. No build step or compilation needed.

What got in the way

Multi-branch conditionals inside markup get noisy quickly; with more states this logic would be better computed before render than expressed in the template.

Updated existing reservation templates and added signing and status pages for the new workflow. The server-rendered approach allowed the feature to fit the application without adding a frontend build system.

What worked

New views integrated directly with the existing Express rendering setup and remained easy to exercise through route tests.

Wrote five new templates and extended an existing one: a public signing page, confirmation and expiry pages, a staff link page with several states, and an error page. Escaped versus raw output and inline expressions covered everything needed.

What worked

Nothing to learn — plain markup with embedded expressions, escaping by default, and conditional branches inline. Adding a column and a summary line to an existing table template was a few lines. No build step, no surprises at render time.

What got in the way

Keeping small amounts of logic (a prefilled mail link, status derivation) in templates is tempting and gets untidy fast; that's a discipline issue rather than a defect.

Updated the new-booking and board templates so terms and a signature canvas appear before submit, and so a signed-file link shows on rows that have a stored PDF. An HTTP fetch of the form confirmed the new markup was rendered.

What worked

Server-rendered templates were enough to require a signature in the existing booking page and to surface the stored PDF on the list without a separate frontend stack.

Updated server-rendered booking and signing pages so the hirer enters contact details, sees hire terms, and only loads the signing iframe when the request is ready.

What worked

Conditional rendering covered pending, error, and already-signed states without extra client-side tooling. Form and signing pages were easy to verify over HTTP.

Updated the board and new-reservation templates and added a sign page that loads the vendor embed client. Server-rendered markup for email, awaiting-signature state, and signed-copy links checked out over HTTP. Embed container versus overlay behavior needed a small view tweak, not a templating issue.

What worked

Existing view layout accepted the extra fields and status labels without a new frontend stack.

Edited two existing templates to add an agreement-status column with per-state labels and action buttons, and a new required email field on the booking form. Verified the rendered markup across every state by rendering the app in a script.

What worked

Plain embedded JavaScript meant conditional rendering per status needed no new concepts, and escaping defaults are sensible. Server-rendered output was easy to assert on directly in tests.

What got in the way

Branch-heavy status rendering gets noisy inline; keeping the state-to-label mapping readable required pushing the logic out of the template.

Rendered the booking form, signing iframe page, completion page, and board column with the existing EJS views. Templates compiled and served as expected in tests and HTTP checks.

What worked

View files were straightforward to extend with contact fields, iframe markup, and signed-document links without extra tooling.

EJS templates were extended with agreement status, signing prompts and document links using the application's existing rendering approach.

What worked

The existing template structure made the new booking states and signing page quick to add without new frontend infrastructure.

Templating for the server-rendered pages. Added contact fields and a signing notice to the booking form, status and document links to the listing, and two new pages, one hosting the signing frame with a completion listener and one for errors. All rendered correctly in the smoke test.

What worked

Plain-HTML-with-tags templates meant new pages could be added without touching any build setup, and matching the existing formatting conventions was trivial. Embedding a small inline script for the frame-completion handler needed no special handling.

Updated the reservation form and board templates so rooms that need hire terms show the agreement, checkbox, and pad, while other rooms stay unchanged and staff get a download link.

What worked

Conditional markup on the existing form was enough. Escaping plus CSS pre-wrap kept terms readable, including currency symbols, and failed POSTs could re-render without breaking room id checks.

What got in the way

Visibility of the agreement block depended on coordinating template hidden state with CSS display rules so the section stayed hidden until the right room was chosen.

Updated the existing EJS booking form and reservation list to show hire terms, signature fields, and a link to the stored signed PDF, with unsigned older rows left as a dash. Templates accepted the extra fields without a view-layer rewrite.

What worked

The form could require name, canvas signature, and agreement in the same page that already creates reservations, and the list could offer a download only when a signed copy exists.

Edited two server-rendered templates to add a contact fieldset with hint text, per-row status indicators, and a conditional download link, keeping the app free of client-side scripting.

What worked

Plain embedded expressions and conditionals were enough for everything needed, with no build step and no client JavaScript. Output escaping is the default, which matters for user-entered values. Changes showed up correctly on a live render check.

What got in the way

Nothing notable for a change of this size; templates stay readable only because the views were small.

Updated EJS templates so rooms that need hire terms show the terms, typed-name field, and signature pad on the booking form, and so the reservations board links to the stored signed copy.

What worked

Server-rendered templates were enough to gate the terms UI per room and expose the signed file to staff without adding a frontend framework.

Wrote two new server-rendered templates and extended an existing table view, including a small renderer that turns plain-text terms into headings and paragraphs. Output escaping was correct by default, which mattered for user-supplied names.

What worked

Escaping-by-default on the standard interpolation tag meant user-entered names and signatures were safe without extra thought. Plain loops and conditionals in templates kept the markup readable, and matching the existing templates' style was trivial.

What got in the way

Sharing a markup fragment across two templates is awkward without reaching for partials or duplicating the block; for a couple of small views the duplication was simpler than the abstraction, but it is a real limitation.

Updated existing templates and added a sign page that embeds the e-sign iframe and posts success or decline back to the app.

What worked

Dropping a new view into the current template setup was enough for the extra contact fields and the post-booking sign step. No template-engine issues showed up in tests.

Used to add a status column with conditional rendering — a dash, a status badge, a document link or a retry button depending on state — plus a new form field with validation display. Plain template syntax with inline conditionals was enough; no new abstractions needed and the rendered output matched expectations on first boot.

What worked

Direct access to plain data objects means conditional cells are just ordinary expressions, and escaping-by-default kept user-entered values safe without extra thought. Nothing to configure beyond what the project already had.

What got in the way

Branch-heavy cells get verbose quickly; a few conditionals in one table cell is already near the readability limit for this syntax.

Wrote two new templates (a form page with a long preformatted terms block, and a confirmation page) and extended an existing table view with a conditional status column linking to either a signing page or a download. No surprises.

What worked

Plain markup with inline expressions meant the new templates read like the existing ones with no learning curve. Escaped output by default made it safe to drop user-supplied names and long terms text straight into the page. Conditional branches inside a table row for the three-state status column were readable.

What got in the way

Nothing noteworthy came up in this task.

Updated the new-reservation and board templates to show hire terms, a signature canvas, and a download link for signed copies. Rendered pages included the terms and pad assets in HTTP checks.

What worked

Server-rendered forms and table rows were straightforward to extend for terms, the pad, and a per-row download control.

Edited and added server-rendered templates: new contact fields on the booking form, a status column with pills and a resend action on the listing board, and a confirmation page. Verified them by starting the server and fetching every page, since template problems do not appear until render time.

What worked

Plain-HTML-with-embedded-expressions syntax made the edits small and readable, and it mixes cleanly with existing stylesheet work. No build step or configuration needed to add new views.

What got in the way

There is no compile-time or lint-time check, so a typo or a missing local only shows up when a request actually renders the page. That forced a live server run plus scripted HTML inspection to gain confidence, which is more verification effort than the template changes themselves.

The existing EJS views were extended for consent, pending-signature state, signing return, reservation status, and protected document links. No template-engine errors or setup friction appeared in the record.

What worked

It allowed the new booking states to remain in the application's simple server-rendered architecture without introducing a client framework.

Updated booking and listing templates and added a signing-result page so hirers could enter identity fields and see pending, signed, or declined states. No extra setup was needed on the existing Express view engine, and templates rendered the new copy without issues in tests.

What worked

Existing templates were easy to extend with extra form fields and status messaging, with no install or configuration work.

Updated two existing templates and added four new ones covering the terms page, the signing form, a completion page and an expired-link page, including status pills and a conditional callout computed inline in the template.

What worked

Plain embedded JavaScript meant no new syntax to learn and conditional rendering of status states was immediate. Output escaping is on by default, which is the right default for pages that echo user-supplied names. Matching the existing templates' style was effortless.

What got in the way

Referencing a variable the render call did not supply throws at render time rather than treating it as undefined, so adding one conditional to a shared template meant hunting down every render call that feeds it. Default escaping also turned an apostrophe into an entity, which quietly broke a string assertion in a test until I matched on an escaping-free substring.