Skip to content

Draft: Spec creation workflow

Edith Coates requested to merge spec_create_flow into main

This is a proof-of-concept for making our browser client a little more RESTful. My goal is to see if it's possible to create a single template for the entire spec creation process, and offload the rendering of the creation GUI entirely to the browser.

Also, I'd like to do away with the StagingSpecification model and let the browser keep track of the "staging" spec entirely. It would mean that spec creation wouldn't be possible across multiple sessions however. That might be fine - just give a big warning dialog if there's unfinished work and the user wants to close the browser tab. Perhaps we can look into client-side caching too.

Also also, I think we've been under-utilizing Alpine.js in our frontend - we've been using HTMX for almost all of our browser/server communication but I think Alpine with the vanilla JS Fetch API we can have a flexible, RESTful client that uses not all that much JS code. In this branch, my plan is to give Alpine an object from the server representing the specification resource. It lives in a top-level div element's x-data attribute, and all of its fields can be updated by child elements of that div. Then all of the progress checks and validation can be done client-side and all we need is a single fetch PATCH or PUT request to save the spec. At that point, the server can do some more checks and save the model to the Specification table. Same functionality, but no need to hack around with forms and helper functions making tens of HTML blobs that have to be passed around.

TODO

  • djlint passing
  • works without reference PDF
  • file new issue to reintroduce reference PDF
  • server-side vs client-side validation decisions
  • what else?
Edited by Edith Coates

Merge request reports