Scala/Lift demo

[Ivan]

Live demo: http://honey-net.eu:8001/
Sources: https://code.google.com/p/mech-tuura-lift/source/browse/src/
Comments: http://honey-net.eu/mech/tuura-lift.html

[Andrey Mokhov]

> The directory structure is imposed by Maven (Java build tool)
> so don't blame me for the annoying amount of sub-directories.

The amount of sub-directories is indeed annoying -- 4 useful files in
~20 directories? I hope there is a workaround for this.

I find the method of generating the html pages, in particular,
implementation of listProblems, to be very clear and convenient. As
in .NET implementation, XML processing seems more natural to me than
generation of a complete HTML page in HappStack.

By the way, is it possible to get rid of some pre-generated stuff in
the resultant HTML pages, i.e. comments "/* <![CDATA[ */ " etc. Also,
built-in CSS looks ugly to me; it should be placed into a
separate .css file.

[Arseniy Alekseyev]

> The amount of sub-directories is indeed annoying

Indeed so. And fighting the Maven's "convention over configuration"
attitude is quite painful, so it may be better to just accept it.

> comments "/* <![CDATA[ */ " etc

Those comments are added not only to annoy people, but also for
compatibility with css- and javascript-unaware browsers, so it is a
good thing (twice! :P).
Also, I don't think using an external CSS file can be a problem in
such a praised web-framework as Lift.

> XML processing seems more natural to me than
> generation of a complete HTML page in HappStack.

I didn't expect to hear that from a known advocate of simplicity. :)
I find dynamic xml processing, which is basically writing something in
a mix of two languages, unnecessarily complex and unelegant.

However, let's think for now that the HTML templating is a good thing.

Now, the bad thing about the Lift's implementation (shared by the
Heist templating system for Haskell, which seems to be its clone) is
its inability to check the templates in compile-time.

When (or rather if, because the compiler does not force you to)
implementing the "listProblems" function, one has to keep the template
before his eyes, or else he will suffer. What happens when the
designer decides to change <p> to <span>? What happens when the
programmer decides to remove some of the fields? Nothing good for
sure.

This is in contrast to .NET's HTML templating mechanism, where the
dynamic HTML controls are instantiated as generated fields of the
class corresponding to the enclosing template and all access to them
is checked in compile-time. Splash did not use it, doing all the
dynamic stuff with C# snippets, which are obviously checked in
compile-time too.

[Ivan V. Polyakov]

> I didn't expect to hear that from a known advocate of simplicity. :)
> I find dynamic xml processing, which is basically writing something in
> a mix of two languages, unnecessarily complex and unelegant.

I strongly disagree with this notion that XML processing involves
using two languages to achieve the same goal. I believe that there are
two very distinct goals -- defining the layout of the page and filling
it with data -- and it is only fitting that they are achieved using
different means. Actually, I believe that a solution involving HTML
generation (literally printing it out, or using a library, doesn't
really matter) is exactly the case of mixing two languages together to
forcibly solve two easily separable goals in the same place.

Imagine we asked Ashur to make a template for us. Ashur obviously
doesn't know neither Haskell nor Scala and I don't think he would care
to learn them, so the best he can do to help is to produce a static
HTML layout. Now to put his design into a template-less HTML generator
based solution you would have to somehow hack it to pieces, copy-paste
them to your code and make sure that your language's HTML generator
produces exactly the same content. To do this you obviously need to
have a good idea of the overall HTML structure. Is this what you call
elegant? And what if he decides to update it some day?

On the other hand, using a template-based solution, the HTML designer
only needs to say "Hey, programmers, put the data here.". He doesn't
even need to bother with learning the template tags, just a simple
placeholder data and a comment would do. The programmer can then
replace the placeholder data with the correct template tags and then
in the actual code that handles the data he only needs to put the data
where he is told to. No messing around with raw HTML whatsoever,
neither in the code, nor in the programmer's mind. And the template
with data tags already in place can be edited at any time without
breaking anything.

> Now, the bad thing about the Lift's implementation (shared by the
> Heist templating system for Haskell, which seems to be its clone) is
> its inability to check the templates in compile-time.

And with this I strongly agree :) This should be done in a safer way.
However I think this is not such a bad issue because it can be solved
using straightforward unit tests. E.g. in Lift if data binding doesn't
match the template tags in any way (either trying to binding to a
missing tag or failing to bind to one of the tags) it will throw a
scary exception which can be easily detected in tests.

[Ivan V. Polyakov]

> Indeed so. And fighting the Maven's "convention over configuration"
> attitude is quite painful, so it may be better to just accept it.

Maven is a really weird tool. Everything about it is truly disgusting,
except that the damn thing works well :)

[Arseniy Alekseyev]

> I strongly disagree with this notion that XML processing involves using two languages to achieve the same goal.

I think you are making the XML templating sound simpler than it is.
First, the tasks of design and data binding are not independent a
single bit! The designer and the programmer must share a single notion
of view, including information about the type of displayed data.
Second, in the workflow you described the HTML coming from the
designer must still be somehow changed to become a real data-bound
one, so no huge improvement here (with tools like blaze-from-html one
can change the page into code with similar effort).

The only point I agree on - there are more designers who know HTML
than those who know Haskell. :)
This is an overwhelmingly major point, however that complicates things
for developer, not simplifies.

> Maven is a really weird tool. Everything about it is truly disgusting,
> except that the damn thing works well :)

LOL! Very true indeed!

[Ivan]

> I think you are making the XML templating sound simpler than it is.
> First, the tasks of design and data binding are not independent a
> single bit! The designer and the programmer must share a single notion
> of view, including information about the type of displayed data.

Really, not a single bit? Now you are making things sound more
complicated than they are. How many bits do the site's header, menus,
logos, icons and fonts share with the problem statements? :) And AJAX
shenanigans aside, how many practical ways of displaying data using
HTML are there? A table with one column, a form and a table with two
columns? :)

Of course some interaction between the designer and the programmer is
helpful, but I think the dependencies between them are minimised using
the template approach.

> Second, in the workflow you described the HTML coming from the
> designer must still be somehow changed to become a real data-bound
> one, so no huge improvement here (with tools like blaze-from-html one
> can change the page into code with similar effort).

Well, a very simple example of filling a table with values. Using
templates you only need to modify one table row. With HTML generator,
you need to print out the "HTML before the table", something inside
the table and "the rest of the HTML". I don't know, maybe
algorithmically it is comparable effort, but practically seems not at
all so to me.

[Arseniy Alekseyev]

> header, menus, logos, icons, fonts
Most of those should be defined in some kind of master page and not
contribute to the problem in question, namely the display of dynamic
data.

> how many practical ways of displaying data using
> HTML are there? A table with one column, a form and a table with two
> columns? :)

The designer may want different algorithmic things, like:
* Determine the cell background colour based on its sequence number in
some fancy way.
* Print the date/time in a specific format.
* Print a number using English words. :)
* Layout items coming from a list in a grid view, two (the next day
it's three) per row.
Each of these customisations is purely design-related, however none of
those is easily expressible with the xml data binding and almost
surely each one would require some code changes.

> Well, a very simple example of filling a table with values. Using
> templates you only need to modify one table row. With HTML generator,
> you need to print out the "HTML before the table", something inside
> the table and "the rest of the HTML".

I guess you meant two modifications: one in the table header,
specifying the handler to perform the iteration, and another in a
table row, specifying the value to print.

With HTML generator you'd do roughly the same, except you'd add code
instead of some cryptic bind handles. You can see it done in the .NET
solution with C# snippets. The fact that it uses an HTML template is
not relevant. Imagine for a minute that the surrounding HTML is a code
too. :)

[Ivan]

> * Determine the cell background colour based on its sequence number in
> some fancy way.
> * Print the date/time in a specific format.
> * Print a number using English words. :)
> * Layout items coming from a list in a grid view, two (the next day
> it's three) per row.

None of this can be achieved using plain HTML so that's a weird
argument. But if you really wanted I think you could embed the
decoration logic into the template using JavaScript (which the
designer is quite likely to know) and keep the data binding very
simple. Also you could use something like this:

<data:number style="use-fucking-english-please"/>

In the worst case (as in someone trying to prove that templates
suck ;) ) you could fall back to HTML generation, but I think that
most typical data binding cases can be easily resolved via templates.

[Arseniy Alekseyev]

> None of this can be achieved using plain HTML so that's a weird argument.

I'm sorry... What? This was my whole point! :)
Dynamic data is not expressible in HTML at all (neither fancy, nor
simple)! However it does not stop you from trying by changing HTML
into a kind of rudimentary programming language, succeeding in simple
cases all right, but having trouble with more complex ones.

> <data:number style="use-fucking-english-please"/>

Which forces the programmer to work on the allegedly independent
design task, trying to figure out, among other things, the differences
between the normal English and the fucking one.

Or were you suggesting that there is no way of generating a static
page achieving those needs? (javascript reference hinted that) That's
obviously not true and the said generation is trivial in a normal
programming language.

By the way, I already agreed that the
designer-does-not-know-how-to-program argument may outweigh all the
ugly things about programming in HTML templates. However, I don't see
any other reason to use them. Are you saying that there is some?

[Ivan V. Polyakov]

> By the way, I already agreed that the
> designer-does-not-know-how-to-program argument may outweigh all the
> ugly things about programming in HTML templates. However, I don't see
> any other reason to use them. Are you saying that there is some?

Beauty lies in the eyes of the beholder, and I see the template
solution as much more elegant. Those things that you call ugly don't
really bother me (the contract between the programmer and the designer
can be set up using a small amount of discussion and common sense) and
even ignoring the "designer should not program" argument I would have
chosen the template solution.

In short, my reason is that in most practical cases using templates
gives a cleaner separation of data presentation and data generation,
and if you *really* have to something tricky you can always fall back
to HTML generation. However I believe that the template interface
should be kept as simple as "put data here", trying to implement any
sort of programming-like interface using the template tags reminds me
of xslt transform which I think is idiotic.

[Andrey Mokhov]

> I didn't expect to hear that from a known advocate of simplicity. :)
> I find dynamic xml processing, which is basically writing something in
> a mix of two languages, unnecessarily complex and unelegant.

You want to pretend that you do not mix two languages by doing
everything in Haskell? That's exactly opposite! You *maximise* mixing
of HTML and Haskell by trying to print out a complete HTML document
from a Haskell program. Use of templates *minimises* this mix: you
only generate those parts of HTML that have to be pulled out of the
database; everything else is written in the "native" web language.

> By the way, I already agreed that the
> designer-does-not-know-how-to-program argument

Why offend designers? :-) I would better put it as the designer-does-
not-want-to-program. Why would a web-designer bother learning where
from and how the data is coming to the web page? This is not his area
-- he designs a layout, picks a colour scheme, and gives a css file +
an HTML template to us. His mission is over -- coding is just
*perhaps* not fun for him.

> Which forces the programmer to work on the allegedly independent
> design task, trying to figure out, among other things, the differences
> between the normal English and the fucking one.

Oh, that's just nonsense for this project. I'm sure there won't be any
problems in understanding what a designer means: we are going to have,
what, 3 pages and, uhm, 4 different types of data fields? :D Is this a
programmer-does-not-know-how-to-read-templates argument? Perhaps, it
is valid for larger projects, but not for this one.

> Beauty lies in the eyes of the beholder, and I see the template
> solution as much more elegant.

+1

I'm sure a holy war can be started on any design decision admitting
more that one solution, however, I see no point in putting too much
effort in this one -- it will take more time than just implementing
the front-end using any selected approach. So, let's just vote to come
out of this metastable state as soon as possible. I see no major
consequences behind any choice.

I vote for templates. Also, I vote for Haskell, because I'd like to
learn it :-) Can we have both?

[Ivan Poliakov]

> The amount of sub-directories is indeed annoying -- 4 useful files in
> ~20 directories? I hope there is a workaround for this.

The workaround would be not to use Maven - which is quite possible :)
One of the nice features of Maven is that it can create a project
template for you using a "project archetype". Those "archetypes" are
published in the central repository so if you would like to start
writing, say, a Workcraft plug-in you could just ask Maven to create a
"Workcraft plug-in" template for you, then it would create the class
stubs and download all the dependencies. In this case I used this
feature to get a Lift website template, but if you don't need that you
can use Scala's own build tool which is much simpler.

> I find the method of generating the html pages, in particular,
> implementation of listProblems, to be very clear and convenient. As
> in .NET implementation, XML processing seems more natural to me than
> generation of a complete HTML page in HappStack.

I like that too - an important implication of this approach is that the
templates are valid XHTML files (as opposed to those with inline code)
which means that you could edit those templates with a GUI HTML/CSS
editor. And of course it is easier to use external templates than to
stick the whole HTML into the program source. But AFAIK HappStack has
something similar, it doesn't actually force you to generate raw HTML.

> By the way, is it possible to get rid of some pre-generated stuff in
> the resultant HTML pages, i.e. comments "/*<![CDATA[ */ " etc. Also,
> built-in CSS looks ugly to me; it should be placed into a
> separate .css file.

Yes, that stuff is defined in the overall template file:
http://code.google.com/p/mech-tuura-lift/source/browse/src/main/webapp/templates-hidden/default.html

This file is applied by <lift:surround> operation and of course can be
replaced or thrown out altogether.

[Andrey Mokhov]

The previous message was automatically marked as spam for some
reason :D I've just noticed that and unmarked it, so it appears out of
order.

[Ivan V. Polyakov]

> You want to pretend that you do not mix two languages by doing
> everything in Haskell? That's exactly opposite! You *maximise* mixing
> of HTML and Haskell by trying to print out a complete HTML document
> from a Haskell program. Use of templates *minimises* this mix: you
> only generate those parts of HTML that have to be pulled out of the
> database; everything else is written in the "native" web language.

I think what Aresniy means is that by using templates you are
effectively introducing some sort of callbacks to the backing
programming language. Then if you want to achieve a complicated data
layout you have to make those template tags more complex, which means
that you could eventually be writing a wrapper around the backing
programming language to make is usable from HTML. If that is the case,
why not move all the logic to the programming language to avoid these
callbacks altogether.

I agree that complicating the templates this way is a bad idea, but my
argument is that you don't have to make them complicated. As long as
you keep the template tags dead simple this approach is clean and
efficient. As soon as you are starting to build a programming language
from those tags you are doing something wrong.

[Arseniy Alekseyev]

> Why would a web-designer bother learning where
> from and how the data is coming to the web page?

Indeed, why? o_O
I don't see why and who suggested that. He only needs to specify how
to handle that data.
By accepting a task of designing a dynamic HTML page, the designer
already agrees to program its behaviour, be it in a human language, in
a somehow-extended html, or in some other programming language, so he
definitely wants to program, he just doesn't know that. :)

> I vote for templates. Also, I vote for Haskell, because I'd like to
> learn it :-) Can we have both?

I think we can. I will post a review of options I know of to the Haskell thread.

[Ulan Degenbaev]

I think there is misunderstanding of term "generated html". It is not like, we are printing out the html using printf("<body>%s</body>"), which would indeed be an ugly mix of two languages. :)

Haskell's combinator library provides a primitive function for each html tag. We combine those function to define the layout in a declarative way. For example, consider the following html document:

<html>

<body>

<p>Hello World</p>

</body>

</html>

In haskell it would look like

html $

  body $

    p "Hello World"

Any other html document can be expressed similarly. You can think of it as "html without redundant brackets and closing tags". :)

The designer doesn't have to learn Haskell, only the gluing syntax ($, $ do), which is easy.

If we agree not to put advanced logic into layout files, then we can separate data generation from data presentation.