That is why I prefer JSON and XSLT as template languages. The client side developer can't use them to do business logic and they are both idiomatically closer to the world in which the client side developer lives. Once we get the auto-conversion to XML/JSON working in HAppS, life gets really simple. The server app functions produce haskell datastructures. The framework auto-converts them into XML with a an XSLT PI or JSON with a script source. Then the clientside devloper gets to manipulate the data in very standard client languages. Right now, you can largely do the same thing, but you have to write the XML representations of your data structures manually. -Alex- On Thu, 5 Apr 2007, Ricardo Herrmann wrote:

The maintenance nightmare happens when someone uses the embedded language to specify business logic, and that's entirely the web-{developer,designer}'s fault. Thus, the problem is not that these languages shouldn't be powerful enough.

IMHO, a safe approach would be simply not allowing I/O inside templates (hey, sounds familiar ;-)

On 4/5/07, Maurice Codik wrote:

...

A few things, some of which I sort of mentioned in my previous email:

- 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.

Maurice

On 4/5/07, Joel Reymont wrote:

...

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

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

...

...

) are extremely popular and work fairly well. They also keep the template language simple because there is already a full-powered

That's not necesarily true. Templates where there is mostly markup, but let you embed code into them using special tags (ex, <% code % programming language thats embedded into it. Good examples of this method are ERB templates in Rails, JSPs, Perl Mason templates, etc.

-- http://wagerlabs.com/

-- http://blog.mauricecodik.com _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-- Ricardo Guimar�es Herrmann "Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp" "Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"