Skip to content

Loading…

Add support for inputList #52

Open
LukeHoersten opened this Issue · 14 comments

5 participants

@LukeHoersten

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.

@ocharles

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.

@cimmanon

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).

@ghost

me three, err four

@mightybyte

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.

@ocharles

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.

@mightybyte

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.

@jaspervdj
Owner

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.

@ocharles

I feel like I have something that's working nicely now, you can compare the work I've done so far in https://github.com/ocharles/digestive-functors/compare/input-list.

The remaining outstanding work is:

  • digestive-functors-snap won't work with a list of inputs like foo.0.name, foo.2.name (assume the user has deleted the entry foo.1.name). 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 :)

@ocharles

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...

@jaspervdj
Owner

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...
@ocharles
  • 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 https://gist.github.com/853b7733d35eeaeeb7e2; 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.

@cimmanon

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:

http://stackoverflow.com/q/12769153/1652962

@mightybyte

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.