non-YiiBooster fields with YiiBooster prepends

I don’t like the idea of rewriting my entire application’s view to use new Bootstrap 3, so my Yii apps remain on Bootstrap 2, served by YiiBooster extension. The biggest problem, I find in it is that its controls have prepends somehow “built-in”.

Both field and its prepend is rendered with one line of code. So, when you want to replace any YiiBooster’s control with for example own widget / library, you always remove one line, but looses both field and prepend.

I found ugly and nasty workaround for this.

It is as ugly as simply recreating all the CSS classes, that are used to build prepend and its surroundings, and adding your own field in either pure HTML / CHtml method or anything else.

So, for example:

<div class="control-group">
    <div class="controls">
        <div class="input-prepend">
            <span style="width: 215px; text-align: left" class="add-on">
        <label for="Users_name">Board types</label>
        </span>
            <?php echo CHtml::dropDownList(
                'Boards[type]',
                $committee,
                $committees['boards']['names'],
                array(
                    'style'=>'width: 650px',
                    'readonly'=>'readonly'
                )
            ); ?>
        </div>
    </div>
</div>

Here we have a dropdown, generated with CHtml::dropDownList(), that looks exactly the same, as all other YiiBooster’s fields around it.

And it is part of the same form (Boards model in this example), so it submits data along with other fields.

I used this piece of code, because original YiiBooster’s dropdown list (TbForm::dropDownListRow()) can’t be feed with other kind of data than the one provided by model. I wanted a dropdown list, that will contain simple associative array contents, that are in no relation with model, but must be processed together with model.

I’m pretty sure, there are some better ways of doing this. This is a nasty, ugly workaround, right! :] But — hey, it works!

BTW: Let me remind you about common pitfall, in which I mostly fall.

Browser won’t sent data from disabled field (<input disabled /> or <input disabled="disabled"/>). If you want to forbid user from direct editing of any field, set it to be read only instead (<input readonly/> or <input readonly="readonly"/>).

In visual and logic layer you’ll get the same effect (user unable to manually change field’s value), but value from that field will be transfered to the server.