#9958: Split contrib.comments CommentForm class to allow easier customization
----------------------------------------------+-----------------------------
Reporter: arne | Owner: nobody
Status: new | Milestone:
Component: django.contrib.comments | Version: SVN
Resolution: | Keywords: comments,
customization
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------------+-----------------------------
Comment (by thejaswi_puthraya):
Replying to [comment:3 arne]:
> Using 9958.diff solves a different problem than my original patch
comments.diff. With the approach in 9958.diff neither inheriting from
!BaseCommentForm nor inheriting from !CommentForm allows for easy
customization of the fields the form uses.
>
> Please consider that not every projects needs a comment form with the
fields "name", "email", "url" and "comment". Sometimes "name" and
"comment" may be enough and 9958.diff gives no form-class from which I can
inherit to cleanly build my own comment form with less fields than the
original !CommentForm. I feel like overriding !__init!__() and using del
to delete form-fields is not a clean solution.
>
Thank you for providing an insight into your problem.
> Using an approach like in comments.diff one can either subclass
!BaseCommentForm to customize the fields the form has and use all the
existing Spam-protection logic or could use a completly other form
(inheriting form forms.Form) to circumvent the Spam-protection as
thejaswi_puthraya pointed out and the ability to customize the fields.
I have seen a lot of requests in IRC from people who felt that the current
honeypot mechanism provided by the comments was insufficient and/or was
redundant with their home-grown/third-party solution. Hence I segregated
the two forms to remove that redundancy.
Here are my observations regarding your patch:
* I would prefer your patch provided it does not have the honeypot in the
BaseCommentForm because it forces the spam protection on users who don't
require one.
* It still does not remove the pain of say having a form that removes the
email field and I am sure no other patch can remove that pain. It is best
to draw a line somewhere and let the user take a small pain (one-time
effort) to write a custom form.
My personal opinion is that spam protection should be optional. Let me
come up with another patch that tackles mixes both your problem and mine.
Let's leave it to the devels and see what is the best for such a scenario.
--
Ticket URL: <http://code.djangoproject.com/ticket/9958#comment:4>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
