Skip to content
This repository

Media type is disabled when disabled="false" #1188

Closed
wants to merge 9 commits into from

8 participants

Benjamin Pick elinw Rouven Weßling Michael Babker Alonzo Turner Louis Landry Andrew Eddie AmyStephen
Benjamin Pick

#1151 introduced unwanted behaviour: any value present with key "disabled" is interpreted as true (also 'false').

elinw
elinw commented May 07, 2012

In other fields we would also allow the equivalent of disabled='disabled' to mean true.

Benjamin Pick
Rouven Weßling
Collaborator

Since disabled is a very common argument we should consider moving it to JFormField (like the check for required). This could save some duplicate code and make sure the fields behave the same.

AmyStephen

Understand the inconsistency and the reason this must be patched.

However, I don't think it's a good practice to treat 'true' as a literal.

IMO, it would be best to make certain the Boolean true and false values work properly (or change it to '0' and '1', or something).

Benjamin Pick
Rouven Weßling
Collaborator

Yep, that's how I imagined it :)

Now we'd only need to change the fields to use $this->disabled.

Next release will be 12.1 but this pull probably won't make it before 12.2.

Michael Babker
Owner
mbabker commented May 07, 2012

Looking back across the other field types, I obviously didn't check to make sure I was consistent with the code used in other field types. That said, I only thought to add the disabled option to the media field after having a case where I needed to disable the select/clear buttons in a non-edit type view (and outputting the data in other ways just didn't suit my needs). The behavior should be consistent across all fields for sure, and all fields should be allowed to be disabled if need be (just my opinion on the last part).

Benjamin Pick
Michael Babker
Owner
mbabker commented May 07, 2012
elinw
elinw commented May 07, 2012

Don't get me started with the check boxes :P.

I didn't really mean that other fields handled disabled differently I meant that in general when we have an attribute like that it works that way (like required)

    // Set the required and validation options.
    $this->required = ($required == 'true' || $required == 'required' || $required == '1');

Theory would say any value means Boolean true, but as pointed out semantically having something="false" and something="0" mean true is just terrible. It's good usability practice to make those mean false and to let disabled="disabled" mean true because it lets users use the format that they are used to or want to use i.e. disabled="disabled" is proper XHTML.

In fact, I would point out, as an example in calendar we have
if ((string) $this->element['disabled'] == 'true')
{
$attributes['disabled'] = 'disabled';
}

Benjamin is right that there are important differences in how disabled and readonly are handled during processing (this this relates again to the specification for handling of check boxes).

The disadvantage of putting it in JFormField is that the attribute is not relevant for all field types according to the W3C standards which is why we don't have it for checkboxes.

I ask because there's a related issue which is people think that readonly as an attribute is protection from change but in fact readonly is NOT and I think it would be good/educational to note this in the docblocks. Again theoretically everyone knows better, practically this is not the case.

http://www.w3.org/TR/html4/interact/forms.html#h-17.12.1

Explains what the difference between readonly and disabled means and should probably be referenced in any docblock.

Also useful
http://www.w3.org/TR/css3-selectors/#enableddisabled
http://www.w3.org/TR/html4/interact/forms.html#h-17.2.1
Good discussion
http://kreotekdev.wordpress.com/2007/11/08/disabled-vs-readonly-form-fields/

Benjamin Pick

The disadvantage of putting it in JFormField is that the attribute is not relevant for all field types according to the W3C standards which is why we don't have it for checkboxes.

I don't agree. Even if the attribute is parsed at JFormField, it doesn't have to be used in every field. I'd even go further and say: the fact that "disabled/read-only" doesn't always translate into a html attribute with this name (e.g. media), doesn't hinder us to use disable/read-only in every field. It should only "behave as if" (semantically).

Read-only: The user may not modify the value, but it is submitted.
Disabled: The user may not modify the value, and it musn't be submitted.

And for the media-element type of input I'd prefer to show disabled (greyed-out) buttons, as in "normally you can modify, but you can't here/at the moment".

elinw
elinw commented May 15, 2012

I'm just saying it is a disadvantage not that we shouldn't do it. Just like we need to document that checkboxes require special handling we need to document that they don't have a disabled state and that unchecked is handled differently than e.g a blank text field because documenting will reduce user confusion. If desired, we can even decide to handle user error by having disabled="true" implement the correct behavior (which is to say act like the field does now)l to short circuit what might be a common error.
Also we need to document what required means for the media field in order to reduce confusion.

Overall I think it's a good idea to encourage use of disabled rather than readonly whenever it is appropriate and will work since it's not susceptible to Firebug.
Also btw I have an old old tracker item http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=22954 in the cms tracker about editorarea not being able to be disabled and now I'm thinking we might want to decide what to there.

indenting 5e4328f
Rouven Weßling
Collaborator

This doesn't merge cleanly. @benjaminpick could you please fix it? Thanks.

added some commits July 24, 2012
Benjamin Pick
added some commits July 24, 2012
forgot getter f008c7c
another mc d9676ed
Alonzo Turner

Thanks Elin! I had opened the Issue #1543 discussion because I believed there was an issue with the multiple attribute not being set properly. It turned out, however, that the issue was that the values used in the xml element attribute had to be either the literal string "true" or "multiple". It did not respond to Boolean values as in multiple="1". The approach used here would correct that issue (if you apply it to multiple as well). But it still references specific strings like "readonly", "disabled", or "multiple" (if it applied). I would rather see something like this:

$this->readonly = ( ! ((bool) $readonly ) || $readonly == "false");

The only string referenced is "false". This way setting the attribute to "false" or zero would indeed register the property as false. But, any other non empty value would register as boolean true. I understand the HTML element must be set to readonly="readonly" ( or multiple="multiple" ), but I feel the attribute of the xml file should be any boolean value.

Though not every element will use each of these attributes, I think that if it is applicable to more than one field type, then it should be included in the JFormField so as not to duplicate code across additional subclasses.

Okay, that's my two cents.

Louis Landry

I like the implementation as it stands today in this pull request. I'd like to get comments from another maintainer before merging it though. @eddieajau, @realityking what do you think? I went ahead and marked it for merging into 12.3 pending a second opinion.

@benjaminpick are you able to rebase this and squash the 9 commits down to one? It seems a bit much to have 9 commits for a total change of 26 lines of code. I understand why it ended up that way, but would be much cleaner IMO if we could get that squashed.

Andrew Eddie
Owner

Looks good to me.

Benjamin Pick
Benjamin Pick benjaminpick referenced this pull request from a commit in benjaminpick/joomla-platform October 10, 2012
Close #1188: Consistent use of XML values for fields 'readonly' and '…
…disabled'
2255646
Louis Landry LouisLandry closed this October 10, 2012
Louis Landry

Closing in favor of #1592

Diana Neculai dianaprajescu referenced this pull request from a commit October 20, 2012
Commit has since been removed from the repository and is no longer available.
Diana Neculai dianaprajescu referenced this pull request from a commit October 20, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 9 unique commits by 1 author.

May 04, 2012
change type to string 37586ae
May 07, 2012
Implement disabled variable as realityking proposes 037463a
fix codestyle 432d32c
forget to rename variable e5d8521
Jun 06, 2012
indenting 5e4328f
Jul 24, 2012
merge upstream 1bfe2d4
add readonly attribute dac516c
forgot getter f008c7c
another mc d9676ed
This page is out of date. Refresh to see the latest.

Showing 1 changed file with 25 additions and 1 deletion. Show diff stats Hide diff stats

  1. 26  libraries/joomla/form/field.php
26  libraries/joomla/form/field.php
@@ -141,6 +141,24 @@
141 141
 	protected $required = false;
142 142
 
143 143
 	/**
  144
+	 * The disabled state for the form field.  If true then there must not be a possibility
  145
+	 * to change the pre-selected value, and the value must not be submitted by the browser.
  146
+	 *
  147
+	 * @var    boolean
  148
+	 * @since  12.2
  149
+	 */
  150
+	protected $disabled = false;
  151
+
  152
+	/**
  153
+	 * The readonly state for the form field.  If true then there must not be a possibility
  154
+	 * to change the pre-selected value, and the value must submitted by the browser.
  155
+	 *
  156
+	 * @var    boolean
  157
+	 * @since  12.2
  158
+	 */
  159
+	protected $readonly = false;
  160
+
  161
+	/**
144 162
 	 * The form field type.
145 163
 	 *
146 164
 	 * @var    string
@@ -240,6 +258,8 @@ public function __get($name)
240 258
 			case 'multiple':
241 259
 			case 'name':
242 260
 			case 'required':
  261
+			case 'disabled':
  262
+			case 'readonly':
243 263
 			case 'type':
244 264
 			case 'validate':
245 265
 			case 'value':
@@ -324,9 +344,13 @@ public function setup(SimpleXMLElement $element, $value, $group = null)
324 344
 		$multiple = (string) $element['multiple'];
325 345
 		$name = (string) $element['name'];
326 346
 		$required = (string) $element['required'];
  347
+		$disabled = (string) $element['disabled'];
  348
+		$readonly = (string) $element['readonly'];
327 349
 
328  
-		// Set the required and validation options.
  350
+		// Set the required, disabled and validation options.
329 351
 		$this->required = ($required == 'true' || $required == 'required' || $required == '1');
  352
+		$this->disabled = ($disabled == 'true' || $disabled == 'disabled' || $disabled == '1');
  353
+		$this->readonly = ($readonly == 'true' || $readonly == 'readonly' || $readonly == '1');
330 354
 		$this->validate = (string) $element['validate'];
331 355
 
332 356
 		// Add the required class if the field is required.
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.