Creating dynamic lists in a form

[wertzui]

Is there any way to have a template define a list to which I can add and remove rows?

E.g. if the model looks something like this:

{
 foo: [
    { bar: "baz" },
    { bar: "bazinga" }
  ]
}

I would need the ability to

1. Add and remove items from the foo list.
2. Define a template for the items in the list

[mamund]

nothing exists right now that defines how to change the template at runtime.

happy to see what you're thinking and how it might become a compatible add-on for HAL-FORMS.

feel free to start a discussion at HAL-DISCUSS mailing list to start. lots of smart folks there.
https://groups.google.com/g/hal-discuss

cheers.

[wertzui]

A new type collection and a new field _template on the property object would probably solve it.
_template is REQUIRED if the type is collection and IGNORED otherwise. It MUST be a valid template object.

One could also add a new type object for nested forms. object type properties would also use the _template field on the property object.

[evert]

I think it's important for this project to clearly state what it's goals are.

Because, if it's goal is the ability to describe a comprehensive amounts possible JSON requests/forms types, frankly it may be better to just adopt json-schema and some way to give the client more UI hints.

Personally I've always seen hal-forms as a way to describe simple forms, similar to the scope of (javascript-free) HTML5 forms. It's good at that, and clearly stating that might make it easier to mark some of these requests out of scope.

If it's intended goal is to support most use-cases people are going to run into, I think it's time to take a step back and think about schemas and how they might integrate, because there's a lot missing, such as nested objects, optional sections, dependent types, arrays (repeated forms). There's just so many possible UI types and serializations that this is kind of a bottomless pit.

What do you want HAL-Forms to be @mamund ?

[mamund]

from my POV, HAL-FORMS wasalways meant to mimic HTML +forms+ (similar to the way SIREN uses +actions+ to mimic HTML +forms+

I'm open to additions to the spec that follow that design ethos -- esp. those that can be implemented as backward-compatible extensions (e.g. no need to get the entire HAL-FORMS spec involved, just release a safe extension).

hence, my response to additions is almost the same: let's see a working example of the feature implemented as a backward-compatible extension.

[evert]

What's your definition of backwards compatibility?

HTML can introduce new elements, but this doesn't break existing browsers as long as sites don't use the new elements. I think it's reasonable to use a similar approach here.

If you want to cater ever client that already exists, I'm curious why. Doing so has already created some very messy parts in the current draft, and it's a bit of a shame to see where things have been going. HAL-Forms needs a vision and strong leadership.

[mamund]

Yep.