Skip to content


Add support for inputList #52

LukeHoersten opened this Issue · 14 comments

5 participants


I'd be nice to be able to dynamically add form elements or subforms client-side in a way that would yield a list of form results in d-f server-side. Looks like it's existed in the past thanks to the work of Doug, Jasper, and some others but lost in overhauls:

I know this is a big request but I figured just documenting a demand for the feature would help in justifying the work.


I'd just like to add my support for this request - I've just ran into some code that needs a [String], but I seem to be out of luck in constructing that right now.


I have a few forms in the project that I'm just about finished with that really could have used a list of subforms (my forms are the result of cross joining 2 different tables in the database: the user has to supply information for each intersection point).


me three, err four


I wish I could do the port, but I simply don't have the time to do it myself. I'd be happy to provide support to anyone who wants to work on it.


I'm going to need this for paid work in the next few days, so anyone willing to provide pointers I'm certainly interested in helping implement stuff.


Start with the pull request Luke linked to in the issue. That'll give you an idea of the scope of code that I wrote. Then check for surrounding commits to see if I made any later changes. Try to do a direct port of what was there and if you have any questions, I'll be happy to help.


Yeah. I think you might want to read through the df code a bit first, since it's quite different now. I'd guess the most straightforward way to implement this is to add a new constructor to the FormTree type. I'm also available if you need some pointers.


I feel like I have something that's working nicely now, you can compare the work I've done so far in

The remaining outstanding work is:

  • digestive-functors-snap won't work with a list of inputs like, (assume the user has deleted the entry I think that it should simply require a monotonic sequence number, but not necessarily something continuous. The Snap Env can probably convert 'index 1' to mean foo.2.
  • digestive-functors-heist has not been updated.
  • digestive-functors-happstack has not been updated.
  • No tests have been written.
  • No documentation has been written.

I'd love to hear thoughts on this, and if anyone wants to help me do some testing (maybe you have a Snap/Blaze app) - now's the time :)


Oh, I'd also like to know if the Heist/Happstack stuff needs to be done before we can release this. Neither of those are libraries I have really ever used, so it's going to take me a while to work on that, and I don't quite feel I can justify spending work time on it...


That's okay, I can port the Heist/Happstack libraries later.

A few things:

  • You mentioned the monotonic sequence numbers, but I think we'd rather handle that in the digestive-functors library instead of digestive-functors-snap, since this probably applies to all backends? OTOH, we need a JavaScript portion for this as well, so can't we fix it there?
  • Do you have a small working example somewhere?
  • I'm not sure if the ActualPath/MetaPath/Container isn't a bit "heavy" because it adds a lot of additional complexity too various modules. If we work with an actual hidden length field, we don't even need to make any changes to digestive-functors-snap, which is a huge advantage...
  • The only way for digestive-functors to deal with it is to pass the entire list of possible values over in the Env and have digestive-functors mangle it apart. If we're doing this, I'd be tempted to say Env shouldn't be Path -> [FieldInput] but should instead just return some sort of tree. Not sure what you mean about a JavaScript portion.

  • All I can show you for now is; I have a Snap application with file uploads and everything but that's at work. Will paste that on monday.

  • We will always have to change digestive-functors-snap because it has to report the size of lists. I wanted ActualPath and MetaPath because then it lets us pattern match in the Env to understand the question being asked. However, I don't think I've necessarily got this solved in the correct way. I would like to keep the clarity of 'I want the length of field x, not the value of field x', if possible.


When support for lists is implemented, it would be great if we could get a new answer for this Stack Overflow question regarding implementing lists of subforms:


This issue can be closed now. In other news, I improved this dynamic list support today. You can see it here Soostone@87488e3. I've tested it and it seems to work, but I'm not quite ready to issue a pull request. If anyone else could do some independent testing to verify that this works, it would be a big help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.