Came across an interesting observation...
May want to check this before 1.0GC release!
When adding a field declared as "READ ONLY", in the back-end/client side it's not officially HTML Read Only, rather DISABLED?
See code excerpt from
comprofiler.class.php:
[code:1]
function getFieldEntry( ... )
....
if($oReadOnly > 0) {
$pReadOnly=" disabled=\"disabled\" ";
....
[/code:1]
Uh... this should be "readonly", not disabled.
OK OK, so what's so bad about disabled vs. readonly?
In short, READONLY has the ability to be "successful", thus can be seen in GET/POST/REQUEST. Setting values to "READONLY" in CB RC2, or DISABLED, will never make it into the database!
more on Successful controls
17.13.2 Successful controls
A successful control is "valid" for submission. Every successful control has its control name paired with its current value as part of the submitted form data set. A successful control must be defined within a FORM element and must have a control name.
more on Read Only
www.w3.org/TR/html4/interact/forms.html#adef-readonly
readonly
When set for a form control, this boolean attribute prohibits changes to the control.
The readonly attribute specifies whether the control may be modified by the user.
When set, the readonly attribute has the following effects on an element:
- Read-only elements receive focus but cannot be modified by the user.
- Read-only elements are included in tabbing navigation.
- Read-only elements may be successful.
The following elements support the readonly attribute: INPUT and TEXTAREA.
BEAT... please put me in my place or help me to understand.
I was so confused when my data started dropping out (err..not getting imported, all to find it wasn't in REQUEST scope)
Post edited by: moneybagsxp, at: 2006/05/10 01:28