The motivation of this pull request is to deal with the problem that the person edit page included post and party selects for every current election in the database - this might be repeated for hundreds of elections, which makes the page very slow to load and crashes some browsers. (See https://github.com/mysociety/yournextrepresentative/pull/740 for more details.)
On the DemocracyClub fork of YNR, this problem has been dealt with by using Javascript to dynamically add those form elements. However, in this upstream versions, so far, all of the site works without Javascript, on the principle that progressive enhancement is a Good Thing, so I was reluctant to merge those changes as-is. This pull request adds a method which is not Javascript-dependent to do the same thing, and we can use this as a base to apply the DC Javascript enhancement in the future. (Which I'm intending to do.)
The person edit page still uses lots of queries in its generation, which is bad, especially since there are fixes for those issues that I made in the DC fork; however, those fixes will apply most easily after the Javascript enhancement has been merged, so my plan is to get this merged, apply the Javascript enhancement of adding new candidacies, and then apply the fixes for excessive queries.
I guess @symroe or @struan might be best placed to review this, if either of you have time? n.b. @symroe, we discussed recently that the formtools wizard examples suggest you need to specify condition_dict as a keyword parameter to as_view, but it works fine when specified as a class attribute instead, as in this example.
The motivation of this pull request is to deal with the problem that the person edit page included post and party selects for every current election in the database - this might be repeated for hundreds of elections, which makes the page very slow to load and crashes some browsers. (See https://github.com/mysociety/yournextrepresentative/pull/740 for more details.)
On the DemocracyClub fork of YNR, this problem has been dealt with by using Javascript to dynamically add those form elements. However, in this upstream versions, so far, all of the site works without Javascript, on the principle that progressive enhancement is a Good Thing, so I was reluctant to merge those changes as-is. This pull request adds a method which is not Javascript-dependent to do the same thing, and we can use this as a base to apply the DC Javascript enhancement in the future. (Which I'm intending to do.)
The person edit page still uses lots of queries in its generation, which is bad, especially since there are fixes for those issues that I made in the DC fork; however, those fixes will apply most easily after the Javascript enhancement has been merged, so my plan is to get this merged, apply the Javascript enhancement of adding new candidacies, and then apply the fixes for excessive queries.
I guess @symroe or @struan might be best placed to review this, if either of you have time? n.b. @symroe, we discussed recently that the formtools wizard examples suggest you need to specify
condition_dictas a keyword parameter toas_view, but it works fine when specified as a class attribute instead, as in this example.