[Haskell-cafe] Re: [web-devel] A light-weight web framework

S. Alexander Jacobson alex at alexjacobson.com
Mon Apr 9 17:11:41 EDT 2007


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 <maurice.codik at gmail.com> 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 <joelr1 at 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/
>> >
>> >
>> >
>> >
>> >
>> >
>> 
>> 
>> --
>> http://blog.mauricecodik.com
>> _______________________________________________
>> web-devel mailing list
>> web-devel at 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"
>


More information about the Haskell-Cafe mailing list