speakerfight
speakerfight copied to clipboard
Pull Request for Issue #280
I have added a new feature on all the widgets where you can now add a new value in the attrs with the key name data_form_class in order to prepend that class in the form for only that field(along with form-group). For Example ,
'due_date': CustomDateTimeWidget(attrs={
'id': 'id_due_date',
'class': 'inline-input',
'placeholder': 'Due Date',
'data_form_class':'col-md-4'
}),
will make the date field only 4 cols long.
I have also done the necessary changes for the #280. The Screenshots for the same are given below.
Please let me know on the changes need and review
Hi @Pratyum, i have a few notes:
-
due_date
andevent_closing_date
are the same thing, if that has a better naming we can just change the field name, if you look at my mockup there are Two Dates: 1) The Date when the Call For papers will close (due_date
) and the Date when the Conference will happen (event_date
from #197 ). - 'data_form_class' can you tell me if just using the 'django-bootstrap3' filter in the field will not work?
- 'slots' - forms.TextInput should be ca Integer Input.
- I think that '{% bootstrap_field field layout='inline' form_group_class=field.field.widget.attrs.data_form_class|add:' form-group' %}' is not a good way, As we are just using templates and forms, i prefer to write down each field instead of doing that. If something needs to be explained in two places its not a good solution :(
Sorry for a bad gramma in somewhere :(
To address your concerns:
due_date and event_closing_date are the same thing, if that has a better naming we can just change the field name, if you look at my mockup there are Two Dates: 1) The Date when the Call For papers will close (due_date) and the Date when the Conference will happen (event_date from #197 ).
- I have renamed the variable to event date
'data_form_class' can you tell me if just using the 'django-bootstrap3' filter in the field will not work?
- I am using the django-bootstrap3 filters and template tags and it would not work if I do it on the form since we need a specific class on the level of the form-group wrapper and it does not happen on just certain fields by declaring it on the form attrs. Hence it is necessary to create them field by field.
'slots' - forms.TextInput should be ca Integer Input.
- I have done that
I think that '{% bootstrap_field field layout='inline' form_group_class=field.field.widget.attrs.data_form_class|add:' form-group' %}' is not a good way, As we are just using templates and forms, I prefer to write down each field instead of doing that. If something needs to be explained in two places it's not a good solution :(
- I have just explained for the sake of it. There would be no need to change anything in templating in case of new files. All you need to do is add a new data_form_class in widgets that you would need to change
If there are any ideas let me know and I shall try them out.
When you implement the event_date
you crossed the blocking issue #197. This cannot happen, or you implement just using html, for visual proposals or leave the last col empty.
You need to delete that migrations, it makes sense on your local database, but its not good to hit the production db to create a field e delete it in the next migration.
About the form filters for that should be something like a solution for this:
diff --git a/deck/forms.py b/deck/forms.py
index 9b36e49..214fa79 100644
--- a/deck/forms.py
+++ b/deck/forms.py
@@ -25,20 +25,17 @@ class EventForm(forms.ModelForm):
exclude = ['author', 'jury']
# data_form_class : To give custom form classes to in the form
widgets = {
- 'title': forms.TextInput(attrs={'class': 'inline-input'}),
+ 'title': forms.TextInput(attrs={
+ 'class': 'inline-input'
+ }),
'due_date': CustomDateTimeWidget(attrs={
- 'id': 'id_due_date',
'class': 'inline-input',
'placeholder': 'Due Date',
- 'data_form_class':'col-md-4'
}),
'event_date': CustomDateTimeWidget(attrs={
- 'id': 'id_paper_closing_date',
'class': 'inline-input',
- 'placeholder': 'Paper Closing Date',
- 'data_form_class':'col-md-4'
+ 'placeholder': 'Event Date',
}),
- 'slots': forms.NumberInput(attrs={'class': 'inline-input','data_form_class':'col-md-4'}),
}
diff --git a/deck/templates/event/event_form.html b/deck/templates/event/event_form.html
index 9c29536..b78ec1f 100644
--- a/deck/templates/event/event_form.html
+++ b/deck/templates/event/event_form.html
@@ -51,14 +51,29 @@
{{ form.errors.description }}
</div>
{% endif %}
- <!-- Iterate through all rows to make all the fields
- If a field has a custom form class(declared in attr with attr name 'data_form_class') then this will also be prepended to the form class group
- -->
- {% for field in form %}
- {% bootstrap_field field layout='inline' form_group_class=field.field.widget.attrs.data_form_class|add:' form-group' %}
- {% endfor %}
- <!-- {% bootstrap_form form layout='inline' %} -->
+ {% bootstrap_field form.title layout='inline' %}
+ {% bootstrap_field form.description layout='inline' %}
+ {% bootstrap_field form.is_published layout='inline' %}
+ {% bootstrap_field form.allow_public_voting layout='inline' %}
+ {% bootstrap_field form.anonymous_voting layout='inline' %}
+
+ <div class="form-group">
+ <div class="col-md-2">
+ {% bootstrap_field form.slots layout='inline' %}
+ </div>
+ <div class="col-md-10">
+ <div class="row">
+ <div class="col-xs-6">
+ {% bootstrap_field form.due_date layout='inline' %}
+ </div>
+ <div class="col-xs-6">
+ {% bootstrap_field form.event_date layout='inline' %}
+ </div>
+ </div>
+ </div>
+ </div>
+
{% buttons %}
<button type="submit" class="btn-flat success text-upper">
<i class="icon icon-edit"></i>
The way that you were trying to do we cannot create this breakpoints for small resolutions and everything else.
The problem with this way is that it is hard coded. If you add a new field later you need to change code a 3 files. And that might not be very intuitive right?
I agree in part with you, if we have a simple form. line after line its okay for have just the {% bootstrap_form form ... %}
as we still have in some places on speakerfight. But sometimes we need a more better designed form, so it makes sense to put each field in his place.
In parallel with this we have another issue to improve the layout #273.
Please note that I have changed the fields to reflect something like you have discussed!
Okay @Pratyum!
Please review and merge code.