|Perl: the Markov chain saw|
Here we have a classic conflict of design forces:
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.
In reply to Re: Re: Re: Short Refactoring Tip: let the object do it for you