The basic idea is that you design a model, which is a set of object that represents your data in data-centered way - disregard the need for display code.

Then you have a controller, which performs user actions on the model, like adding items, performing calculations, and so forth. It should be pretty thin, and if you find yourself doing too much logic in the controller, that has to do with the contents of the data instead of the contents of the user request, you should probably refactor your model so that it's objects know how to apply this logic to themselves.

Lastly, you have the view, which accept a data model with is view oriented. It cares about display logic only. The controller is responsible for creating objects that are intuitive for the view, from objects that are intuitive to the data model.

I like using the Petal templating system for views, which is similar to HTML::Template, because it's very limited in terms of logic - you have to insert a real object model into it (as objects, or nested data structures), you don't get much more than if-else. It also looks kind of like H::T, because the templates are valid XHTML themselves.

In contrast to H::T it i a bit easier to use simple logic to create more fine grained HTML output, so I've yet to need to create HTML strings in the perl code.

If you are hard enough on yourself, refactoring your objects often, as annoying as that is, and keeping all the view logic simple, but not letting it in the perl code at all, you usually have much more maintainable code. Rereading stuff like Apache::ASP code is something I really don't enjoy, because Perl and HTML are mixed freely.

Another thing you should look at is Maypole - it's purpose is to bring MVC to web programming, and let you build web UIs very easily and quickly. It's new, so it's still under heavy development, but if you don't like it most the discussions about it notes the nice set of alternatives that are available.