- If I'm already going to commit some time to learn a templating language, why dont I just spend that same amount of time learning the little bit of haskell I need to make the template work? If thats too much to ask, I can just spit out HTML, and have the programmer put in the dynamic parts for me. Both of these scenarios seem to be a more efficient use of time.

- Who is the target audience? If its a big organization where there are multiple designers and multiple devs, then your approach may work just fine. If its the single developer, then something like what David suggested would work even better. If its a small team (which may or may not include a full-time designer), then something like what I suggested would work best. For a web framework for haskell, I would guess that the latter two are much more likely.

- Embedding a real programming language in a template already gives you power to do what ever you need to do. What if you need to implement some logic that the template language doesnt support? In those cases, you're usually out of luck and have to move that logic into a controller, where it doesnt really belong (assuming its actual display logic, not business logic).

- It's really just a matter of taste. Any web framework thats worth using should be flexible in its support of view technologies, but come with one thats a sensible default.

On 4/5/07, Joel Reymont <joelr1@gmail.com> wrote:

Do you see anything wrong with the approach I suggested, though?

On Apr 5, 2007, at 6:16 PM, Maurice Codik wrote:

> That's not necesarily true. Templates where there is mostly markup,
> but let you embed code into them using special tags (ex, <% code %
> >) are extremely popular and work fairly well. They also keep the
> template language simple because there is already a full-powered
> programming language thats embedded into it. Good examples of this
> method are ERB templates in Rails, JSPs, Perl Mason templates, etc.

--
http://wagerlabs.com/