Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Prepare a new instance for filling from an active form definition and form attachments #316

Open
lognaturel opened this issue Feb 26, 2025 · 0 comments
Open

Prepare a new instance for filling from an active form definition and form attachments #316

lognaturel opened this issue Feb 26, 2025 · 0 comments

Comments

@lognaturel
Copy link
Member

User story

As the developer of a host application,
I want the option to request preparing a new instance for form filling after a user has made a submission
So that I can support a workflow that requires filling a form multiple times

As a form end user,
I want the option to immediately fill out another instance of the active form after submitting
So that I can quickly carry out my next task

Notes

  • This is the current behavior from Central when accessing form filling from Submissions > New
  • This needs to be opt-in -- there are many cases in which the host application will want to redirect or do something else after submission
  • Preparing a new instance involves resetting all values to defaults, triggering all preloads, and triggering odk-instance-first-load.
eyelidlessness added a commit that referenced this issue Mar 4, 2025
@eyelidlessness
engine: entrypoint interface overhaul, split form load and instance c…
dd88b02 
…reation

This addresses a few overlapping concerns.

**Engine support for #316: Prepare a new instance for filling from an active form definition and form attachments**

A client can now load a form (definition, related resources such as external secondary instances) once and create any number of instances from the result. This is handled by splitting the interface for those aspects of what was formerly named `initializeForm` into:

1. `loadForm`, which now produces a `LoadFormResult`.
2. `createInstance`, exposed to clients as both:
    - A contextualized member of `LoadFormResult`
    - A convenience entrypoint composing steps 1 & 2 (in both its signature and behavior)

**Lay groundwork for edit-oriented equivalents to `createInstance`**

In subsequent commits, we’ll expose additional entrypoints for editing instances. Those additional entrypoints will follow the same pattern as `createInstance`, both as members of `LoadFormResult` and as composed convenience entrypoints.

**General cleanup of related types, documentation, exports, package structure**

This is a fairly broad category, and it accounts for the vast majority of diff noise in this commit. The vast majority is related to either refining terminology, or usage flow changes. There’s also some opportunistic cleanup of structure. Hopefully this is all pretty straightforward in review at the commit level!

- - -

**A couple additional notes on `LoadFormResult`**

- This interface continues to keep the engine’s “form” concepts relatively private from clients (except for the parts we already over-expose as node `definition`s. I expect we’ll expand the interface over time, exposing more about a form as it’s parsed and resolved. I’ve deferred that for now, in favor of putting more thought and intention into how we expose any still-internal concepts and/or structures.

- The interface _is not_ a great candidate for exposing certain mid-parse details, such as a listing of `jr:` URLs parsed from the form definition. But it’s pretty easy to see where another split could be introduced to accomplish that.

- It also begins to lay some groundwork for expressing errors in the engine/client interface. It handles a very small subset of this problem, and the actual shape of `Result` types will probably be different when we address that concern more fully. The intent here is to carve out a reasonably narrow slice of fallibility as a proving ground for that eventual effort.
eyelidlessness added a commit that referenced this issue Mar 4, 2025
@eyelidlessness
web-forms (Vue UI): minimal changes to integrate engine entrypoint revs
8c876b1 
As this is minimal, this leaves aside opportunities to take advantage of:

1. Engine support for creating multiple instances for the same form. This is the remaining aspect of #316.
2. Somewhat clearer production of errors on form load. There is a bit of an opportunity here, but it may fit better in the work on point 1.
eyelidlessness added a commit that referenced this issue Mar 4, 2025
@eyelidlessness
engine: entrypoint interface overhaul, split form load and instance c…
7989d81 
…reation

This addresses a few overlapping concerns.

**Engine support for #316: Prepare a new instance for filling from an active form definition and form attachments**

A client can now load a form (definition, related resources such as external secondary instances) once and create any number of instances from the result. This is handled by splitting the interface for those aspects of what was formerly named `initializeForm` into:

1. `loadForm`, which now produces a `LoadFormResult`.
2. `createInstance`, exposed to clients as both:
    - A contextualized member of `LoadFormResult`
    - A convenience entrypoint composing steps 1 & 2 (in both its signature and behavior)

**Lay groundwork for edit-oriented equivalents to `createInstance`**

In subsequent commits, we’ll expose additional entrypoints for editing instances. Those additional entrypoints will follow the same pattern as `createInstance`, both as members of `LoadFormResult` and as composed convenience entrypoints.

**General cleanup of related types, documentation, exports, package structure**

This is a fairly broad category, and it accounts for the vast majority of diff noise in this commit. The vast majority is related to either refining terminology, or usage flow changes. There’s also some opportunistic cleanup of structure. Hopefully this is all pretty straightforward in review at the commit level!

- - -

**A couple additional notes on `LoadFormResult`**

- This interface continues to keep the engine’s “form” concepts relatively private from clients (except for the parts we already over-expose as node `definition`s. I expect we’ll expand the interface over time, exposing more about a form as it’s parsed and resolved. I’ve deferred that for now, in favor of putting more thought and intention into how we expose any still-internal concepts and/or structures.

- The interface _is not_ a great candidate for exposing certain mid-parse details, such as a listing of `jr:` URLs parsed from the form definition. But it’s pretty easy to see where another split could be introduced to accomplish that.

- It also begins to lay some groundwork for expressing errors in the engine/client interface. It handles a very small subset of this problem, and the actual shape of `Result` types will probably be different when we address that concern more fully. The intent here is to carve out a reasonably narrow slice of fallibility as a proving ground for that eventual effort.
eyelidlessness added a commit that referenced this issue Mar 4, 2025
@eyelidlessness
web-forms (Vue UI): minimal changes to integrate engine entrypoint revs
015589c 
As this is minimal, this leaves aside opportunities to take advantage of:

1. Engine support for creating multiple instances for the same form. This is the remaining aspect of #316.
2. Somewhat clearer production of errors on form load. There is a bit of an opportunity here, but it may fit better in the work on point 1.
eyelidlessness added a commit that referenced this issue Mar 12, 2025
@eyelidlessness
engine: entrypoint interface overhaul, split form load and instance c…
5931859 
…reation

This addresses a few overlapping concerns.

**Engine support for #316: Prepare a new instance for filling from an active form definition and form attachments**

A client can now load a form (definition, related resources such as external secondary instances) once and create any number of instances from the result. This is handled by splitting the interface for those aspects of what was formerly named `initializeForm` into:

1. `loadForm`, which now produces a `LoadFormResult`.
2. `createInstance`, exposed to clients as both:
    - A contextualized member of `LoadFormResult`
    - A convenience entrypoint composing steps 1 & 2 (in both its signature and behavior)

**Lay groundwork for edit-oriented equivalents to `createInstance`**

In subsequent commits, we’ll expose additional entrypoints for editing instances. Those additional entrypoints will follow the same pattern as `createInstance`, both as members of `LoadFormResult` and as composed convenience entrypoints.

**General cleanup of related types, documentation, exports, package structure**

This is a fairly broad category, and it accounts for the vast majority of diff noise in this commit. The vast majority is related to either refining terminology, or usage flow changes. There’s also some opportunistic cleanup of structure. Hopefully this is all pretty straightforward in review at the commit level!

- - -

**A couple additional notes on `LoadFormResult`**

- This interface continues to keep the engine’s “form” concepts relatively private from clients (except for the parts we already over-expose as node `definition`s. I expect we’ll expand the interface over time, exposing more about a form as it’s parsed and resolved. I’ve deferred that for now, in favor of putting more thought and intention into how we expose any still-internal concepts and/or structures.

- The interface _is not_ a great candidate for exposing certain mid-parse details, such as a listing of `jr:` URLs parsed from the form definition. But it’s pretty easy to see where another split could be introduced to accomplish that.

- It also begins to lay some groundwork for expressing errors in the engine/client interface. It handles a very small subset of this problem, and the actual shape of `Result` types will probably be different when we address that concern more fully. The intent here is to carve out a reasonably narrow slice of fallibility as a proving ground for that eventual effort.
eyelidlessness added a commit that referenced this issue Mar 12, 2025
@eyelidlessness
web-forms (Vue UI): ~minimal changes to integrate engine entrypoint revs
67a55ef 
This leaves aside opportunities to take advantage of engine support for creating multiple instances for the same form. This is the remaining aspect of #316.
eyelidlessness added a commit that referenced this issue Mar 12, 2025
@eyelidlessness
engine: entrypoint interface overhaul, split form load and instance c…
5af1b49 
…reation

This addresses a few overlapping concerns.

**Engine support for #316: Prepare a new instance for filling from an active form definition and form attachments**

A client can now load a form (definition, related resources such as external secondary instances) once and create any number of instances from the result. This is handled by splitting the interface for those aspects of what was formerly named `initializeForm` into:

1. `loadForm`, which now produces a `LoadFormResult`.
2. `createInstance`, exposed to clients as both:
    - A contextualized member of `LoadFormResult`
    - A convenience entrypoint composing steps 1 & 2 (in both its signature and behavior)

**Lay groundwork for edit-oriented equivalents to `createInstance`**

In subsequent commits, we’ll expose additional entrypoints for editing instances. Those additional entrypoints will follow the same pattern as `createInstance`, both as members of `LoadFormResult` and as composed convenience entrypoints.

**General cleanup of related types, documentation, exports, package structure**

This is a fairly broad category, and it accounts for the vast majority of diff noise in this commit. The vast majority is related to either refining terminology, or usage flow changes. There’s also some opportunistic cleanup of structure. Hopefully this is all pretty straightforward in review at the commit level!

- - -

**A couple additional notes on `LoadFormResult`**

- This interface continues to keep the engine’s “form” concepts relatively private from clients (except for the parts we already over-expose as node `definition`s. I expect we’ll expand the interface over time, exposing more about a form as it’s parsed and resolved. I’ve deferred that for now, in favor of putting more thought and intention into how we expose any still-internal concepts and/or structures.

- The interface _is not_ a great candidate for exposing certain mid-parse details, such as a listing of `jr:` URLs parsed from the form definition. But it’s pretty easy to see where another split could be introduced to accomplish that.

- It also begins to lay some groundwork for expressing errors in the engine/client interface. It handles a very small subset of this problem, and the actual shape of `Result` types will probably be different when we address that concern more fully. The intent here is to carve out a reasonably narrow slice of fallibility as a proving ground for that eventual effort.
eyelidlessness added a commit that referenced this issue Mar 12, 2025
@eyelidlessness
web-forms (Vue UI): ~minimal changes to integrate engine entrypoint revs
a5621bd 
This leaves aside opportunities to take advantage of engine support for creating multiple instances for the same form. This is the remaining aspect of #316.
@eyelidlessness eyelidlessness mentioned this issue Mar 12, 2025
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
Web Forms
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lognaturel