After getting 'WontFix' for #416 I decided to describe the problem with a bit more details. Hopefully, this will impress core developers.
There is no core mechanism to set one or several values of an array. All you can do is override entire array. Here's an example (TSomeWidget):
public $htmlOptions = array('class' => 'some', 'style' => 'width: 100px');
<? $this->beginWidget('TSomeWidget', array('htmlOptions' => array(...))) ?>
Notice the place I marked with '…'. There you need to repeat all widget-defined
array values to add some attribute to the widget. Of course, this is all about
convenience. Just comparing Prado's XML approach with YII's PHP.
Isn't it possible to implement some mechanism so we could override magic methods
using behaviors? For example, dot-format could be something like:
<? $this->beginWidget('TSomeWidget', array('htmlOptions.class' => 'new_class')) ?>
In this situation existing array values would be preserved. If you care about
performance, the following might be an alternative (thought it's complicated):
<? $this->beginWidget('TSomeWidget', array('prop:htmlOptions.class' => 'new_one')) ?>
Where 'prop:' would invoke/autoload a behavior named 'prop' responding for assigning
sub-property values. Prop might also be a method autoloading matching behavior.
In fact, this is not a matter of XML/PHP-based approach but an implementation itself.
Prado allows dotted property assignment while YII doesn't. This will definitely save
developers from writing tons of dummy lines of code such as:
$htmlOptions = $this->htmlOptions; if (!empty($this->class)) $htmlOptions['class'] = $this->class; if (!empty($this->style)) $htmlOptions['style'] = $this->style; $labelOptions = $this->htmlOptions; if (!empty($this->class)) $labelOptions['class'] = $this->class; if (!empty($this->style)) $labelOptions['style'] = $this->style; $inputOptions = $this->htmlOptions; if (!empty($this->class)) $inputOptions['class'] = $this->class; if (!empty($this->style)) $inputOptions['style'] = $this->style;
Also, with YII developers could use shared classes for complex properties.
At this very moment any property being an object cannot be configured without
tweaking around every property like this.