Help for GSoC proposal (Formset improvements)

[PARTH PATIL]

I was planning  to do the "Formset Improvements" project in GSoC. I would need some more explanation on what is expected as nothing was clearly mentioned there.

You can link the related tickets or elaborate on what is needed that would be helpful.

I dug a little bit deeper into this. and found some related issues 1 | 2.

I'm planning to add a request variable in the BaseFormSet Class and then handle it such that it will be available within every form (not completely polished till now).

1. Is this a good approach?
2. Will this solve the problem? (If not please mention the problems which will not be solved

I am also looking for some additional features that maybe added to formset so am open for suggestions.

I'm currently in middle of making the abstract so before moving forward i would like to get some confirmation that this is correct approach. Thank you

[Dmitriy Sintsov]

It would be nice to have paginated formsets when there are lots of one to many relationships in the inline form, otherwise such rendered formset is slow and huge.

[Carlton Gibson]

Hi Parth, 

Yes, something along those lines will be right. 

First-off, what are the existing work-arounds (i.e. how are people handling this in the wild: overriding `__init__()` methods etc...) — can these be summarised and documented, where worth recommending?

Then, API changes to improve on that situation, like passing in request objects. (From experience with DRF and django-filter, making the request available solves **most** issues for **most** users — "But I need X! — But that's just `request.X`" 9 times out of 10.) 

THEN, look at open accepted issues on Forms. There are ≈70. Begin with FormSets issues, then spread out. Which are related? (#10403?) Which can you target? You don't have to solve them all (!) but a good goal for a 12 week project would be to become a total expert on django.forms, and to have handled a number of issues as part of that. 

HTH.

Kind Regards,

Carlton

[PARTH PATIL]

Thanks for your help 😀

[PARTH PATIL]

(Sorry I typed the incomplete message in the last post)

I came across this ticket while going over the feature list of Forms and Formsets (# 18830)

Feature requested in this thicket is something like

FormWizard:

     It will be like a container which can have forms, formsets, and formwizards itself.

     

1. Is this kind of feature still required?
2. Will this be a good addition to the Form?
3. Should I mention this in my proposal, as there is few time left for the final submission I may not be able to draft it properly?

The possible use of this will be to attach different forms in an HTML and this form wizard will handle saving, etc of the forms. I was thinking of keeping something like a management form similar to formset which will handle the individual object and ensure which fields correspond to which form/formset element within the wizard.

[Carlton Gibson]

Hi Parth. 

Well, the wizard (&co) got moved out to it's own app https://django-formtools.readthedocs.io/en/latest/

But yes, there's no reason why this sort of thing wouldn't potentially in scope. 

Kind Regards,

Carlton

[PARTH PATIL]

I researched a bit on FormWizards, and what I felt is that it is oriented more towards the idea of multiple form submission similar to that of Google forms where we have multiple pages. 

I was thinking of creating a FormSetContainer which would be like a collection instance of different Forms, FormSets. or FormSetContainers themselves. It would be oriented more towards how we handle it in the backend, like the saving process, validation, etc rather than the frontend side. And the FormWizard View may be revived to display the FormContainer.

This would be another level of abstraction over the FormSet and can be helpful in the case where the user needs to get data for different model objects at once.

Please comment on need and feasibility of this.