Re: Re: Short Refactoring Tip: let the object do it for you

[Ovid]

That's a very interesting observation. Given what you've written, how would you handle this?

[% IF item.can_receive %]
    <input type="text" name="received" value="[% item.received %]" cla
+ss="input2"/>
[% ELSE; 
       item.received; 
   END %]

In the above case, I am querying whether or not an item can accept a value for given attribute (those are Template Toolkit directives). If so, an input box is presented to the end user, with the current value filled in. If not, they only see the value. As this data can be represented in many other ways (and not just on HTML forms), it doesn't seem to make sense to have the object present HTML code to the end user. I like the idea of moving the conditional logic into the object, but I don't see a clean way of doing that.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

[mvc]

Here we have a classic conflict of design forces:

• Encapsulation
• Seperation of concerns (cohesion)

If you put the UI code in the object, you are encapsulated but your object is now doing its regular work + UI work (low cohesion). If you keep it as is, you get clean seperation of concerns, but break encapsulation.

There are other solutions that could balance these forces better. The balance of forces you want depends on your requirements.

You could, for example, have the template code look like this:

<% item.getReceivedUI("<input ...>") %>

The item object getReceivedUI() will check if receive is possible, if so interpolate the parameter as a TT template with item.received in the stash. If not, it returns item.received. Then you remove the UI code from the item object by delegating the actual interpolation to some strategy object, that may use TT or anything. Thus the item knows not about UI, just about presentation logic. The template is still in charge of the UI. Is this extra work worth it? Depends on your requirements.