The differences between Field extra widgets and Hidden Field Widgets should be explained on the main project page. If the features can be combined into one module, then the other one should be deprecated. Here is some more information from IRC:

(01:26:52 PM) pounard: colan1> actually DamZ's module doesn't do the same as hidden_field
(01:26:57 PM) pounard: I was reading both code
(01:28:24 PM) pounard: colan1> if you use DamZ's hidden field, you don't have the  but nothing instead, it's actually totally different
(01:28:42 PM) pounard: the input type hidden can be used for many purposes (such as JS value modification)
(01:29:00 PM) pounard: so it's actually not doing it better, he's doing something different
(01:30:11 PM) colan: pounard: interesting, thanks.  i just don't want editors to see pure token fields that are set up to always use defaults.
(01:30:46 PM) pounard: colan1> then for this usage, DamZ's module seems better because the input type=hidden will make the value being in HTML code
(01:30:48 PM) pounard: it's unsafe
(01:32:05 PM) colan: pounard: unsafe?
(01:32:22 PM) pounard: colan1> the user can modify a input type=hidden value, and it's legal
(01:32:37 PM) pounard: so someone with firebug for example will be able to modify the value
(01:32:47 PM) colan: pounard: oh yeah, right.
(01:33:01 PM) pounard: so it will alter the database
(01:34:16 PM) neclimdul: well more importantly, javascript can alter it
(01:34:59 PM) pounard: yes, that's why in fact the hidden_field is a legit module, you could use it in order to alter it with JS
(01:35:08 PM) pounard: but it doesn't protect it
(01:35:30 PM) ***neclimdul nods
(01:36:07 PM) neclimdul: though, you can actually protect hidden fields with #value. could maybe be feature request :)
(01:37:43 PM) pounard: neclimdul> or set them #disabled :)
(01:38:23 PM) neclimdul: i hadn't heard of that one but sounds like it might work if it doesn't cause the browser not to post it or something
(01:38:50 PM) neclimdul: also #access depending on what you're trying to do
(01:39:29 PM) pounard: neclimdul> I think -but I'm not sure- that FAPI protects a #disabled field (does not care about the posted value)
(01:39:33 PM) pounard: but I might be wrong there
(01:39:53 PM) pounard: so you have the field displayed, but not modifiable, and if the users cheat with firebug or something, FAPI don't care about it
(01:40:08 PM) pounard: #access will hide the field completely and not display it in the form
(01:40:24 PM) neclimdul: pounard: it was a problem in the past that disabled checkboxes where weird because of how fapi and browsers interacted. i wouldn't be suprised if that's fixed
(01:40:47 PM) pounard: I hope it has been fixed :)
(01:41:46 PM) neclimdul: when we where doing the module page redesign in 5 it caused modules being depended on to randomly get disabled :)
(01:41:48 PM) pounard: FAPI bugs in general can lead to severly absurd behaviors, hopefully it's generally stable :)
(01:41:52 PM) neclimdul: so that was a /long/ time ago
(01:41:58 PM) pounard: indeed ):

Comments

derhasi’s picture

derhasi commented

I currently looked into the source code of both modules.

It seems, that "Field extra widgets" does properly implement the "Read only" field but I couldn't figure out, why the "Hidden" widget simply returns an empty array.

"Hidden Field Widgets" does well on the "Hidden" and "Server value" fields, as for now there are some Issues with multiple values I'm currently working on (#1504366: Multiple value fieldset shown for multi value widgets). The "Item" Widget of that module simply does not implement yet.