What happens if I create my framework around a class template with header and footer and later I need to program web services with it? I need to create more classes for each particular problem and so on in the framework. It is possible that these classes don´t fit the need of every particular
On Fri, May 9, 2014 at 5:39 AM, Alberto G. Corona
In the other side, a basic set of combinators can fit any problem. So inheritance can become bad magic. While composability gives freedom.
Right. And good types give power. Haskell shows you can have both.
I can alternatively do it using classes. I define a class:
class Template where header:: Widget () body :: Widget a footer :: Widget ()
That might work for a single template, but as you note, it's to inflexible to use for many kinds of template. If I were going to do this (and I'm probably not), it'd be more like: class Template a where render :: String -- generate a static string of bytes -- provide instances of Monad, Monoid, and whatever else you -- think might be handy as well. instance Template Blaze.Html where render = renderHtml That's all part of the framework. Then your template system should swallow your EDSL, and produce something like: data MyPage = MyPage Template Template Template instance Template MyPage where render (MyPage head foot body) = ... (or maybe it should use a record, or a tuple, or something else). This isn't that much difference from something like Blaze. Except that the templates being datatypes instead of functions means you can make them instances of other typeclasses. I built one Cheetah template system where the templates generated config files (we had hundreds of the silly things), and made them a subclass of a FilePath type as well. So you could not only get them to provide the contents of a file, but you could get them to tell you the name of the file the content went into.
It seems cumbresome, rigid and redundant to me, like many OO code..
What "header" means in that class? it includes also the html <header> tag or it is simply some common html for all pages at the beginning? It is
Yes, but if you change it so that your typeclass just handles the thing common to all templates (rendering), and your template data types have the elements specific to them, it becomes less so. The question is does doing it this way buy you anything, and is that enough to justify the extra mechanisms involved? probable that this class definition is not appropriate for all pages. neither the combinator version. but with an EDSL I can create page template variants faster for my particular problem. The class no longer has "header", the data type does. And it means what the data type needs it to.
But this is not IMHO the right base design assumption for a (Haskell) web framework. It may be for some particular problem.
That may well be the case, even if you get the architecture closer to what Cheetah is doing. That's what I'm trying to find out. Thanks, Mike