A colleague of mine showed me the seaside framework and although I haven't used it the whole way of doing things looks really nice. I think I need to understand smalltalk syntax a bit better to really get what's going on though!

I say over-engineered because as far as I can see you are using double-dispatch where there is only a single dimension of variability. EditMode is the one dimension while HtmlHelper is not (is that right…HtmlHelper is only ever one type (class)?).

The method name looks like it is trying to do 2 things, maybe it should be taking in a field representation object i.e. HtmlHelper.renderField(field) {
field.renderOn(this);
}

field could be an editable or readonly field which is polymorphic. Yes the decision on which type of field that must be created still needs to be decided, in a factory maybe, (much as the boolean check) but at least the solution is general and not as specific as the proposed solution.

I personally like the http://www.seaside.st frameworks way of using a canvas and 'brushes' to display html, javascript etc.

Field>>renderOn: htmlCanvas
^htmlCanvas textInput
value: textInputExample;
callback: [ :value | textInputExample := value ];
beReadOnly.

EditableField>>renderOn: htmlCanvas
^ (super renderOn: htmlCanvas) beEditable.

EditableField would extend Field and the type of object (EditableField component or a readonly field component) would receive the polymorphic call to render itself on a canvas, in this case htmlCanvas.

I know what your post is trying to say but the benefit of going into double dispatch is harder to follow, albeit for the more explicit naming used which helps the user understand what is tryign to be achieved. Isn't simply easier to have a more descriptive intention revealing method or a more 'complete' object that encapsulates the model and can render itself.

Good post…cheers

Your method interface became more expressive because you refactored the code to have a single purpose (RenderFieldWith) and a single purpose is more easily expressed.

So, by focusing on expressability you were able to back into a very old design principle for methods.

Thank you for submitting this cool story – Trackback from DotNetShoutout…

HtmlHelper.DropDownOrReadOnly(true)

then we can just call the right method directly:

HtmlHelper.ReadOnly()

rather than fussing with an EditMode.

On the other hand, if we're not passing a constant then the type of the passed variable doesn't matter:

HtmlHelper.DropDownOrReadOnly(editMode)

Here it doesn't matter whether editMode is a boolean or an EditMode instance.

The big problem with boolean parameters is that the sense of the parameter is unclear — what does "true" mean? If I set editMode to "true" does that mean I *can* edit, or I *cannot* edit? If we can encode this information as high up the call chain as possible it makes things clearer. If we make our editMode property hold an EditMode instance then in the logic that handles changing the mode we can assign EditMode.ReadOnly or EditMode.DropDown as appropriate. There is now no danger of disagreement over what "true" means — this information is directly encoded into a behaviour choice at the point that the selection is made.

if(someBoolean) o.DoThis();
else o.DoThat();

or, more confusing yet…
HtmlHelper.DropDownOrReadOnly(isReadOnly ? EditMode.ReadOnly : EditMode.Editable);

I get what your saying, I believe in it ( see http://csharptest.net/?p=198 ). It's just worth saying that in NO WAY should you force the logic to the client, rather the goal is to eliminate the condition all together. Provided the caller knows which type of control he is creating, the approach above works very well. When the caller is deriving whether or not the control is read-only by some data (say an access check) the solution gets more troublesome.