Stronger how? It is just a pseudo-html document tree being manipulated in scala. I'm not sure how it can become stronger or weaker.
>For the TAL stuff, it looks like logic is directly placed in an attribute.
It is placed wherever you want it. Using a TAL loop attribute is no different than doing the same thing in lift. The only difference is that lift doesn't show doing that in the docs, so people tend not to do it.
>Again, the difference comes in how the templates are "split" and placed in the app
I still don't understand what you mean. We literally took our lift templates and used them in heist just doing a search and replace s/lift://g. We just had to change the scala code "snippets" to be haskell code "splices".
>I'm still interested to hear an analysis if you are up for giving it
Lift assumes too much, and if you go outside those assumptions you are basically stranded. Combined with just being an immature framework where there's things missing/incomplete, and an outright hostile community, it makes things pretty difficult. Form handling was the biggest sticking point, especially when you want to have forms that aren't protected by their CSRF tokens and need to work with cookies disabled. It becomes a case of "well, we don't want to support that so just do it yourself from scratch".
Play we had tons of issues with the weird scala templates they use. It would barf frequently on what appeared to be perfectly valid syntax. Combined with the "developing with play is super fast!" sales pitch, while being slower to recompile than lift was, we didn't bother spending much more time on it.
I should have made clearer that I am reading on those template engines right off. That is, I hadn't really heard of them till you mentioned them. Asking for more was simply on the lines of "if you have other examples right off."
Regarding TAL. Looking at it, it did not look like it fed in the markup of the current tag to anything to process it. That is likely just my misreading of the wiki page.
Regarding Heist. This could again just be my hasty reading, I think. I saw it said it was the same idea as the Lift templates. But then it jumped straight into the bind and apply tags. With the latest lift templates, there are no custom tags. Nor are there custom attributes.
Also, I'm highly curious on the upsides of the Haskell framework you are using.
>That is likely just my misreading of the wiki page.
I would say the fault there lies 100% on the docs, not you. The docs are heavily focused on using the attributes that are provided out of the box, rather than on how to write your own.
>But then it jumped straight into the bind and apply tags
That's the equivalent of lift:surround. There's nothing special about those tags, they are just part of the set of default splices that you can use.
>With the latest lift templates, there are no custom tags. Nor are there custom attributes.
What are there instead? The docs still appear to be talking about lift:stuff tags and attributes. There aren't really custom tags or attributes in heist either, unless you want there to be. You are really just binding some haskell code to a tag or attribute. That tag could be a real html tag (like the splice included by default that is bound to the html tag, which consolidates multiple head tags into one). Or it could be a any tag you make up, like we bind a splice to the <user> tag which replaces the contents with the user data.
>Also, I'm highly curious on the upsides of the Haskell framework you are using.
Shockingly enough considering how haskell is known for slow compile times, faster compilation is one of the upsides. Mainly we used snap because it gives us the same thing we liked about lift (templates), but with no assumptions about how things have to work, a more helpful community, and a better language.
I think this does highlight the major problem with lift, which is just scattered documentation. The "designer friendly" templates push all of the lift:foo stuff into class names in the template.
That is funny to hear that haskell compiles faster. Seems scala is really becoming the language known for the slow compilation nowdays. I think there is some form of irony to that. (Though, I had not actually heard haskell was slow. I just know it doesn't target the jvm, which is where I've been living for a long time.)
>The "designer friendly" templates push all of the lift:foo stuff into class names in the template.
Oh, I realize you can do that also, I just didn't recognize that there's any difference. <lift:foo> and <div class="lift:foo"> are identical right? Heist lets you do both too.
>That is funny to hear that haskell compiles faster.
Not in the general case, but specifically with snap. I'm not sure what magic they have going on in their dynamic loader, but it is much faster than the one yesod uses for example (another haskell framework).
The difference is pretty much strictly whether it can validate and generally display correctly. I seem to recall browsers were less than good about the tags, whereas just having the classes works great to bang away at a template, and then use it.
Cool to see that Heist is effectively the Lift templating system. I suppose I shouldn't be surprised to see some movement in that direction. I do still for more templating like this in the jvm, though. I'll have to look into TAL more when I get the chance.
Of course, right now I'm having to use GWT for a project. Don't know why, but I loath UiBinder. And, well, most of GWT at the moment. :(
Stronger how? It is just a pseudo-html document tree being manipulated in scala. I'm not sure how it can become stronger or weaker.
>For the TAL stuff, it looks like logic is directly placed in an attribute.
It is placed wherever you want it. Using a TAL loop attribute is no different than doing the same thing in lift. The only difference is that lift doesn't show doing that in the docs, so people tend not to do it.
>Again, the difference comes in how the templates are "split" and placed in the app
I still don't understand what you mean. We literally took our lift templates and used them in heist just doing a search and replace s/lift://g. We just had to change the scala code "snippets" to be haskell code "splices".
>I'm still interested to hear an analysis if you are up for giving it
Lift assumes too much, and if you go outside those assumptions you are basically stranded. Combined with just being an immature framework where there's things missing/incomplete, and an outright hostile community, it makes things pretty difficult. Form handling was the biggest sticking point, especially when you want to have forms that aren't protected by their CSRF tokens and need to work with cookies disabled. It becomes a case of "well, we don't want to support that so just do it yourself from scratch".
Play we had tons of issues with the weird scala templates they use. It would barf frequently on what appeared to be perfectly valid syntax. Combined with the "developing with play is super fast!" sales pitch, while being slower to recompile than lift was, we didn't bother spending much more time on it.