And apparently I am still bad at this. Dammit!

please squash it into one commit :-)

Is it really needed? It makes control more complicated, just because there is an error in the annotation…

@dg the + is you can use easily your own macros, which call ->addAttributes() with parameter, which is by default empty array ([]). So this is BC break, my macros stopped working and I have to rewrite them to be getControl() return value aware.

I think it should be consistent and getControl() should always return Html object.

Primary: getControl() returned Html object because it had sense. Returning always Html object is little bit like cargo cult ;-) Creating $wrapper will lead to questions like „why other controls have no wrapper“? Because wrapper is unnecessary. Because returing Html when it has no sense is not unnecessary too.

So I understand @hrach point, but better is say: „Hey, do not rely on that getControl always returns Html, look at DefaultFormRenderer and fix your macros“ than change CheckboxList and support wrong design decision.

As @dg wrote this is of no value. Actual benefit would be if the markup was structured Html object so it can be walked and modified without parsing text to html and back.

It would be useful if I could extract all input[type=checkbox] in CheckboxList and wrap them in something else.

@dg even consistency alone by itself is a pretty good argument. That fact that you wouldn't have to write ifs around every ->getControl() call, that you have to hack around right now, is a benefit that is a result of consistency.

For the same reason we shouldn't have boolean parameters that change result type of method call, and probably not even $need arguments (which, I admit, are sometimes handy).

The wrapper is useless here, the createInputList should have returned the Html object right away.

I agree that it is bad to write ifs around every getControl(). But are you doing it? In which case?