angular-dynamic-forms
angular-dynamic-forms copied to clipboard
danhunsaker
keeping order using a json object is a bit of a headache
Trying to use you module. I am generating the form template dynamically using python. However, I want to have control over the order in which the form items appear. I think using an array of objects could be a better approach ?
Sander.
This sounds like a Python issue, to me. The order isn't changed by JavaScript - the order in which they're defined is the order in which they're rendered. If Python doesn't maintain that internally, I'm not certain what to suggest. If it allows sorting, you could try naming your fields to be easily sortable...
The early prototype of this module used an array of objects, as you suggest, and was considerably more verbose than I desired. Plus an array of objects seemed a tad silly when each of them had an ID I could use as a key instead of a property. Though I think my use case also needed the ability to quickly find and manipulate fields, and objects provide that better than arrays. All that said, it might be possible to support an array of objects as well as an object of objects. I'll look into it when I have the time.
Disclaimer: I am not a Javascript expert. But as far as I know looping through the items of a javascript object does not garantuee to return the items in the order in which they were defined.
http://stackoverflow.com/questions/280713/elements-order-in-a-for-in-loop
In raw JS, this is often true, but we're not using raw JS. AngularJS has a number of enhancements (some of which were adapted from jQuery) which make things more predictable. One of these things is angular.forEach(), which this module uses exclusively for all iterative processes. I've never encountered any issues with Angular and maintaining the order of object properties.
Alright, then this would be a python issue. As a python dictionary / hash table does not keep order when iteration over it. would be nice though if your library can digest a list of json objects too....
OK, I just looked at the angular.forEach() code, and I was mistaken - it does use for ... in behind the scenes. Browsers tend toward definition order, but by no means are they required to honor it, and this is a problem for us. I will start making the required changes (unless someone submits a PR for it before I get the chance) as soon as I have the time free to do so.
My apologies for being reticent.
It does seem rather a multi-language tendency. We tend to use associative arrays in PHP instead of actual objects, because they have less overhead (among other things), and being arrays, they maintain definition order. Unordered collections are fairly common elsewhere, though, and associative arrays (ones which use alphanumeric keys instead of purely numeric indices) are actually pretty rare (with hash tables and similar unordered structures being preferred), which seems a bit silly to me as well.
Still, since that's the reality of things, I will accept the necessity of using arrays (indexed) when order matters, and objects (keyed) when it does not.
would it not be easiest just to add a new config to each control like {order: X} and let the user just put 1,2,3,4 in there and just use that when you render it? i realize it would be nice to just let the order the configs appear dictate the order, but we do have a simple approach that take about 30 seconds to add to even a form with 20 items right? then you can press on with the fieldset enhancement ;) (totally shameless i know)
It would be possible, but not necessarily easier. There's a good chance I'll support both array-defined-order and object-key-order approaches, in fact, as well as object-ambiguous-order for BC purposes. We'll see what happens when I get there.
OK, I'm going to probably add support for an order key, but I just realized that you can already use an array of objects (a "list of JSON objects", as @sander76 calls it) by simply setting model instead of relying on the template key. Indeed, the latest demo uses this approach in the templateUrl section (see demo/form-template.js).
I'll still need to add some logic to support this approach for the select field's options key (and any others like it, such as radio's values...), but this has actually already been supported since the initial release. I'll update the documentation accordingly as soon as the options version of this is added.
Documentation updated, but select and radio option lists are still unconverted to the array format, so I'll leave this one open for now.
@danhunsaker can you pleaes tell em whats wrong here - http://stackoverflow.com/questions/37384061/form-data-ignores-ngmodel/37385047?noredirect=1#comment62281231_37385047?
