Hello and thank you
4 views
Skip to first unread message
Karsten
Dec 15, 2009, 2:20:40 AM12/15/09
to django-dataforms
Hello,
great you've created this group, I think django-dataforms has a lot of
potential and needs a place where users and developers can exchange
experiences.
First, I wanted to say thank you for creating d-df at all. One of my
several duties here at $COMPANY is to create forms the callcenter
agents fill in, and from these forms create tickets in our
Ticketsystem. d-df has, together with django-dbtemplates (which I
discovered much too late), allowed me to delegate most of the (boring)
content work to the callcenter administrators, which leaves me more
time for the interesting stuff :-)
During our last micro-project (which started last wendsday and went
live yesterday - this would not have been possible without d-df!), I
collected some feedback and found some smaller issues:
0) Please put a prominent link to this group on the google code site.
It should not be nescessary to track developers down on facebook to
provide feedback ;-)
1) It would be great if required fields would have an additional css
class so they can be styled differently.
2) If I have a MultiSelect field and create a binding to one of its
choices, the binding only gets active if this choice is the only one
selected. In my eyes this behaviour should be at least configurable,
if it's not a bug at all.
3) The use of validators is unclear to me. Could you provide a little
example on how to use them?
4) To generate tickets, I run render_to_string with a ticket template
and form.cleaned_data. For choice fields, this includes only the
choice values, but not the choice titles. To work around this, I
created a small template filter (included below). Maybe it's of use to
someone, feel free to include it into the package if it's worth it:
from django import template
from django.template.defaultfilters import stringfilter
from dataforms.models import Choice
register = template.Library()
@register.filter
@stringfilter
def choice_title (value):
"""
Resolve the displayed title of a dataforms choice.
"""
return Choice.objects.get(value=value).title
That's it for now, I'm sure I will find some more stuff while
converting some of our old forms to d-df.
Yours
Karsten
great you've created this group, I think django-dataforms has a lot of
potential and needs a place where users and developers can exchange
experiences.
First, I wanted to say thank you for creating d-df at all. One of my
several duties here at $COMPANY is to create forms the callcenter
agents fill in, and from these forms create tickets in our
Ticketsystem. d-df has, together with django-dbtemplates (which I
discovered much too late), allowed me to delegate most of the (boring)
content work to the callcenter administrators, which leaves me more
time for the interesting stuff :-)
During our last micro-project (which started last wendsday and went
live yesterday - this would not have been possible without d-df!), I
collected some feedback and found some smaller issues:
0) Please put a prominent link to this group on the google code site.
It should not be nescessary to track developers down on facebook to
provide feedback ;-)
1) It would be great if required fields would have an additional css
class so they can be styled differently.
2) If I have a MultiSelect field and create a binding to one of its
choices, the binding only gets active if this choice is the only one
selected. In my eyes this behaviour should be at least configurable,
if it's not a bug at all.
3) The use of validators is unclear to me. Could you provide a little
example on how to use them?
4) To generate tickets, I run render_to_string with a ticket template
and form.cleaned_data. For choice fields, this includes only the
choice values, but not the choice titles. To work around this, I
created a small template filter (included below). Maybe it's of use to
someone, feel free to include it into the package if it's worth it:
from django import template
from django.template.defaultfilters import stringfilter
from dataforms.models import Choice
register = template.Library()
@register.filter
@stringfilter
def choice_title (value):
"""
Resolve the displayed title of a dataforms choice.
"""
return Choice.objects.get(value=value).title
That's it for now, I'm sure I will find some more stuff while
converting some of our old forms to d-df.
Yours
Karsten
Fotinakis
Dec 15, 2009, 7:12:10 PM12/15/09
to django-dataforms
Karsten,
Thanks for your interest in the project—I'm glad it's been useful to
you and your company.
> 0) Please put a prominent link to this group on the google code site. <snip>
Thanks for the push to create this group, just hadn't got around to
it. I added a link to this group on the Google Code project after this
list had been created.
> 1) It would be great if required fields would have an additional
css
> class so they can be styled differently.
We want to let each project determine how their own templates display
the created forms, but it would be easy to add an {% if %} tag that
would check if the field is required and add a CSS class. I've updated
our template example code to show that:
http://code.google.com/p/django-dataforms/source/browse/trunk/example/templates/index.html
<div class="form-row{% if field.field.required %} required{% endif
%}">
> 2) If I have a MultiSelect field and create a binding to one of its
> choices, the binding only gets active if this choice is the only one
> selected. In my eyes this behaviour should be at least configurable,
> if it's not a bug at all.
Ya, I think that is a bug. Will you file a report on our issue
tracker? I'll look into it.
> 3) The use of validators is unclear to me. Could you provide a little
> example on how to use them?
The validation system is a little bit magical and I'll work on writing
some documentation for it. For now, if you take validation_example.py,
copy or rename it to validation.py and then run the example, I think
you'll get the idea. The validation is loaded dynamically if the
dataforms can import a module named "validation" and find a class name
that corresponds to the dataform slug it is processing (i.e.,
"PersonalInformationForm" is the class name in the validation module,
for the dataform with the slug of "personal-information-form"). Then,
inside that class, we just use Django's standards for form and field
validation ( http://docs.djangoproject.com/en/1.1/ref/forms/validation/
). The clean() method can perform dataform-level validation, and the
clean_field_slug() methods can perform field-level validation. These
methods are dynamically injected onto the form object when it's
created so that Django's own validation system can be used. Does that
make sense?
> 4) To generate tickets, I run render_to_string with a ticket template
> and form.cleaned_data. For choice fields, this includes only the
> choice values, but not the choice titles. To work around this, I
> created a small template filter (included below). Maybe it's of use to
> someone, feel free to include it into the package if it's worth it:
<snip>
Cool, good idea. Just thinking about it though, there's no guarantee
that a choice slug is unique (I don't think they should be—there are
probably many cases where different titles would use the same choice
value). So, the code of Choice.objects.get(value=value).title will
throw an exception if there are multiple Choices with the same slug.
> That's it for now, I'm sure I will find some more stuff while
> converting some of our old forms to d-df.
Thanks for your input, let me know if you have other issues. I like
the name "d-df", it's catchy. ;)
- Mike
Thanks for your interest in the project—I'm glad it's been useful to
you and your company.
> 0) Please put a prominent link to this group on the google code site. <snip>
Thanks for the push to create this group, just hadn't got around to
it. I added a link to this group on the Google Code project after this
list had been created.
> 1) It would be great if required fields would have an additional
css
> class so they can be styled differently.
the created forms, but it would be easy to add an {% if %} tag that
would check if the field is required and add a CSS class. I've updated
our template example code to show that:
http://code.google.com/p/django-dataforms/source/browse/trunk/example/templates/index.html
<div class="form-row{% if field.field.required %} required{% endif
%}">
> 2) If I have a MultiSelect field and create a binding to one of its
> choices, the binding only gets active if this choice is the only one
> selected. In my eyes this behaviour should be at least configurable,
> if it's not a bug at all.
tracker? I'll look into it.
> 3) The use of validators is unclear to me. Could you provide a little
> example on how to use them?
some documentation for it. For now, if you take validation_example.py,
copy or rename it to validation.py and then run the example, I think
you'll get the idea. The validation is loaded dynamically if the
dataforms can import a module named "validation" and find a class name
that corresponds to the dataform slug it is processing (i.e.,
"PersonalInformationForm" is the class name in the validation module,
for the dataform with the slug of "personal-information-form"). Then,
inside that class, we just use Django's standards for form and field
validation ( http://docs.djangoproject.com/en/1.1/ref/forms/validation/
). The clean() method can perform dataform-level validation, and the
clean_field_slug() methods can perform field-level validation. These
methods are dynamically injected onto the form object when it's
created so that Django's own validation system can be used. Does that
make sense?
> 4) To generate tickets, I run render_to_string with a ticket template
> and form.cleaned_data. For choice fields, this includes only the
> choice values, but not the choice titles. To work around this, I
> created a small template filter (included below). Maybe it's of use to
> someone, feel free to include it into the package if it's worth it:
Cool, good idea. Just thinking about it though, there's no guarantee
that a choice slug is unique (I don't think they should be—there are
probably many cases where different titles would use the same choice
value). So, the code of Choice.objects.get(value=value).title will
throw an exception if there are multiple Choices with the same slug.
> That's it for now, I'm sure I will find some more stuff while
> converting some of our old forms to d-df.
the name "d-df", it's catchy. ;)
- Mike
Karsten
Dec 16, 2009, 4:10:27 AM12/16/09
to django-dataforms
On Dec 16, 1:12 am, Fotinakis <mike.fotina...@gmail.com> wrote:
> > 1) It would be great if required fields would have an additional
> css
>
> > class so they can be styled differently.
>
> <div class="form-row{% if field.field.required %} required{% endif
> %}">
That was too easy :-) Great, works out of the box now.
> %}">
> > 2) If I have a MultiSelect field and create a binding to one of its
> > choices, the binding only gets active if this choice is the only one
> > selected. In my eyes this behaviour should be at least configurable,
> > if it's not a bug at all.
>
> Ya, I think that is a bug. Will you file a report on our issue
> tracker? I'll look into it.
> > 3) The use of validators is unclear to me. Could you provide a little
> > example on how to use them?
> ("PersonalInformationForm" is the class name in the validation module,
> for the dataform with the slug of "personal-information-form").
[...]
okay, I was missing that bit. the rest is clear.
>> 4) To generate tickets, I run render_to_string with a ticket template
> So, the code of Choice.objects.get(value=value).title will
> throw an exception if there are multiple Choices with the same slug.
Okay, so I'll have to deploy a local policy for this as long as I
> throw an exception if there are multiple Choices with the same slug.
don't find a better solution for this. But to be sure I'll wrap the
filter code into a try: .. except: return value block so at least it
won't break.
Thank you so far, I'm already thinking about what to ask next ^^
Karsten
Reply all
Reply to author
Forward
0 new messages