[erlang-questions] Thoughts on EHE - the PHP killer
Sat Feb 18 16:13:41 CET 2012
On Sat, Feb 18, 2012 at 3:26 PM, Ulf Wiger <> wrote:
> On 18 Feb 2012, at 13:31, Matti Oinas wrote:
> Biggest problem with enlive is that it is written with clojure. Not that
> clojure isn't great but it still isn't erlang.
> I agree that this is a great way to keep the HTML/CSS side pure, and still
> have lots of power to enhance it with dynamic content.
I was thinking about this: In theory having a watertight
barrier between logic and presentation seems like
a good idea - but is it?
I was looking for a good template language that separates logic from
control so I looked around a bit. I looked at
wordpress (as far as I can see it's just PHP) so is phpBB
there are loads of different styles/skins for this so they must be
doing something right. Then I looked at the tumblr template language -
there are loads of nice templates for this, but this
language was highly structured to follow what I assumed was
the tumblr internal database schemas.
I think I see a pattern here. I have a similar problem with
markup language - I have implemented half a dozen markup
languages but at the end of the day, when I want to write a book I
turn to LaTeX or docbook or an XML markup.
The markup languages and templating languages get you a
long way very quickly. They solve 95% of the problem immediately (or
98% or something) - its the 5% or 2% in the
tail that's the problem. Simple markup languages are useless when you
find you want really beautiful output - then you have to sweat blood.
Same for web-sites - templating is fine until you want to do
something that the template writer had not imagined.
Full Erlang embedded in Html solves my problem - it might
not be pretty - it might not have strict separation of issues
it might not separate logic from control - but it is *very* powerful.
I keep hearing about script-kiddies who can understand
HTML but not "coding" (whatever that is) or people who
can do html but not css so this is not for them. I'm aiming at
and I'm not so worried about
inversion of control or separation of logic and presentation.
This ehe that I mentioned - I just write <?e Erlang ...?>
slap bang in the middle of *anything* - ie HTML, CSS,
No mess no problems easy semantics - but not separation
of control and logic and presentation.
I have been thinking about this for a very very long
time - and 100% separation of issues is incredibly difficult.
Some I'm back to embedded Erlang + parameterised modules
and erlhive thinking ...
> There is an (experimental?) xmerl_sax_parser-based module that is able to
> parse most existing HTML - certainly enough to handle the kind of templates
> one should be able to expect from a professional web designer*. With it, and
> perhaps something like xmerl_xs, it shouldn't be that hard to come up with
> an enliven-inspired lib in Erlang.
> Ulf W
> * I think this is one of the harder problems in the mix: accepting more or
> less malformed HTML. I know yaws has a HTML parser as well (yaws_html), but
> don't know how robust it is.
More information about the erlang-questions