Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a make_floppy utility method #137

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Adding a make_floppy utility method #137

wants to merge 4 commits into from

Conversation

ghinch
Copy link

@ghinch ghinch commented Jan 22, 2015

When you are using Form classes which have already been created in an external app, sometimes it's not practical or desirable to create entirely new Floppyform classes which mimic the field structure. I've created a simple utility method, make_floppy, which should allow you to take advantage of Floppyforms on existing Forms, without having to create new classes.

Updated version of #136

@ghinch ghinch closed this Jan 23, 2015
@ghinch ghinch reopened this Jan 23, 2015
@ghinch
Copy link
Author

ghinch commented Jan 23, 2015

Build failed because it failed to download Django on Travis side apparently, odd. Closed/reopened to do a new Travis build.

In any event, this PR is fully open for discussion, both about implementation as well as the feature itself, if you want to add it. I'm finding it a needed and useful tool in a couple projects I'm using Floppyforms in, and thought others might as well.

@gregmuellegger
Copy link
Collaborator

Hey, thanks for this idea. There is an alternative implementation to floppify a form in django-admin2: https://github.com/pydanny/django-admin2/blob/develop/djadmin2/forms.py#L250

The approach in django-admin2's method is to create a subclass of the form and only switching out the widgets. It then uses a predefined mapping (_django_to_floppyforms_widget) of which attributes should be copied etc. So it's a more static version, but might be easier to troubleshoot and special case for specific fields if required.

Your approach therefore might be future proof since it tries to introspect the field arguments were possible. I'm not sure of what the better approach here is.

Do you have an opinion about the code that is used in django-admin2 in comparison to your pull request? I'm very keen on hearing about this from you.

Otherwise I'm a bit concerned about introducing a make_floppy feature into django-floppyform, mostly because of the maintanance burden since the forms that might be put into it can be very diverse. However the feature would be a very helpful thing to have when needed.

Thanks for bringing up this topic. I think it's something worth exploring a bit!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants