This patch changes the captcha persistence widget from a check box to radio buttons, which should make it easier to understand that setting.
I'll add a screenshot in follow up.

Concerning source code, this change will also make it easier to add additional types of captcha persistence in the future, if needed.

Comments

soxofaan’s picture

StatusFileSize
new34.43 KB

screenshot of what patch does

robloach’s picture

I think I like the checkbox design more. Radio buttons are usually used when there are more than two options available. Although I could be wrong here as I'm no designer.

soxofaan’s picture

I think I like the checkbox design more. Radio buttons are usually used when there are more than two options available.

From the viewpoint of the programmer a checkbox is indeed the natural choice. But with radio buttons you can better present the options to the administrator.
In the checkbox design the whole explanation is in the description string, which has to be read carefully. Without that description, it is not obvious what the option does.
In the radio buttons design the options are directly related to the widget elements, which is easier to parse. There is no description needed anymore.

Another advantage is that it is easier to add an option like "Always add a captcha, except after preview" in the future.

soxofaan’s picture

See http://drupal.org/node/169758 for a usage scenario where the current checkbox design fails to communicate its meaning clearly.

robloach’s picture

I really don't mind what design is chosen. It's completely up to you guys and wundo. The thing I do mind is all those ugly defines in the code ;-) .

dman’s picture

OK, seeing that it's not just a case of my own confusion/preference , I'll say "why not". I've found that radios are appropriate for slightly complex cases, so I'l vote for this.
+1
... But yes, the DEFINEs are maybe overkill ;-)

.dan

soxofaan’s picture

The thing I do mind is all those ugly defines in the code

But yes, the DEFINEs are maybe overkill

But what is the alternative? Hardcoded values are error prone and bad coding style.
Moreover, I don't think the defines are ugly, they make the code more readable. "CAPTCHA_PERSISTENCE_SKIP_ONCE_SUCCESSFUL" is has a more obvious meaning than "1".

soxofaan’s picture

StatusFileSize
new3.04 KB

updated patch:
against captcha.module version 1.42.2.27
use of "CAPTCHA" instead of "captcha"

dman’s picture

Status: Needs review » Reviewed & tested by the community

OK, yeah.
I had nothing serious about the DEFINEs - just a big fix for a small problem. I agree they are sorta-best-practice.
Just do it.

soxofaan’s picture

StatusFileSize
new4.23 KB

New version of patch, which adds an option to make persistence global (not per form) as suggested by http://drupal.org/node/175912

the persistence widget now looks like:

CAPTCHA persistence:

  • Always add a CAPTCHA.
  • Omit CAPTCHA for a form once the user has successfully answered a CAPTCHA for that form.
  • Omit CAPTCHA for all forms once the user has successfully answered a CAPTCHA.

Define if CAPTCHAs should be omitted during the rest of a session once the user successfully answers a CAPTCHA.

robloach’s picture

I like the look of this one now.

soxofaan’s picture

StatusFileSize
new5.37 KB

New version of patch with addition of solution for the cache+persistence bug (as suggested in http://drupal.org/node/175909#comment-306165)

robloach’s picture

Title: cleaner 'captcha persistence' widget » Cleaner 'captcha persistence' widget
Status: Reviewed & tested by the community » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)