3 ms·

There's nothing unique about lift's template system though, you can get something like that in many languages, potentially while also using a good framework.

taeric 14y ago
I have not seen another templating system that compares. What other framework has it such that the templates are html. Not "html like" but actual html? Honestly, I think for me the big win with them is actually the inversion of how the template is done. Instead of writing some template that specifies how it is manipulated, you write a template and then directly manipulate it in the framework. (That make sense?) In essence, it seems that it is automating the typical first task on getting some html from a designer. This is great, because often the template can be redone and then all of the modifications the programmer was going to make to them is just part of the framework. As noted by TylerE above, I can see how this might not be a factor. I personally loved it.
- papsosouid 14y ago
  http://en.wikipedia.org/wiki/Template_Attribute_Language http://en.wikipedia.org/wiki/Template_Attribute_Language is the most widespread example. We ended up switching to haskell and using heist, which is the same type of deal. The "view first" thing was certainly very irritating, but minor overall compared to other weaknesses in the framework.
  - taeric 14y ago
    Any better examples? Neither of those appear to have the same strengths I was referring to. (Not to say they are crap. Just not the same.) Though, similar to TylerE, I'm curious to hear what you think are the other weaknesses? Similarly, how do you feel it compares with its peers? (A peer being a JVM targeted framework.)
    - papsosouid 14y ago
      I don't know what you are referring to. What strengths? They are html templates. If you are going to restrict "peers" to jvm frameworks then I really can't offer you anything. I haven't used any other jvm frameworks, I tried the two scala options (lift and play) and ran screaming.
      - taeric 14y ago
        First, apologies for taking so long to respond. I almost just edited my other post. (For some reason the "reply" link wasn't coming up.) Regardless. I see that the Heist language looks like early Lift templates. They got stronger with time. For the TAL stuff, it looks like logic is directly placed in an attribute. Probably both would be a far cry better than the stuff I have become accustomed to, however, Lift still seems stronger. Again, the difference comes in how the templates are "split" and placed in the app. The lift way just requires judicious useage of class names. Moving past that, though, I'm still interested to hear an analysis if you are up for giving it. While I'm most likely to only understand what I called "peer" comparisons, I'm interested in all. Edit: Further apologies in that I am likely not going to be able to respond for a while at this point. So, thanks for the discourse!
        papsosouid 14y ago
        >They got stronger with time 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.

taeric 14y ago

I have not seen another templating system that compares. What other framework has it such that the templates are html. Not "html like" but actual html? Honestly, I think for me the big win with them is actually the inversion of how the template is done. Instead of writing some template that specifies how it is manipulated, you write a template and then directly manipulate it in the framework. (That make sense?) In essence, it seems that it is automating the typical first task on getting some html from a designer. This is great, because often the template can be redone and then all of the modifications the programmer was going to make to them is just part of the framework. As noted by TylerE above, I can see how this might not be a factor. I personally loved it.

papsosouid 14y ago
http://en.wikipedia.org/wiki/Template_Attribute_Language http://en.wikipedia.org/wiki/Template_Attribute_Language is the most widespread example. We ended up switching to haskell and using heist, which is the same type of deal. The "view first" thing was certainly very irritating, but minor overall compared to other weaknesses in the framework.
- taeric 14y ago
  Any better examples? Neither of those appear to have the same strengths I was referring to. (Not to say they are crap. Just not the same.) Though, similar to TylerE, I'm curious to hear what you think are the other weaknesses? Similarly, how do you feel it compares with its peers? (A peer being a JVM targeted framework.)
  - papsosouid 14y ago
    I don't know what you are referring to. What strengths? They are html templates. If you are going to restrict "peers" to jvm frameworks then I really can't offer you anything. I haven't used any other jvm frameworks, I tried the two scala options (lift and play) and ran screaming.
    - taeric 14y ago
      First, apologies for taking so long to respond. I almost just edited my other post. (For some reason the "reply" link wasn't coming up.) Regardless. I see that the Heist language looks like early Lift templates. They got stronger with time. For the TAL stuff, it looks like logic is directly placed in an attribute. Probably both would be a far cry better than the stuff I have become accustomed to, however, Lift still seems stronger. Again, the difference comes in how the templates are "split" and placed in the app. The lift way just requires judicious useage of class names. Moving past that, though, I'm still interested to hear an analysis if you are up for giving it. While I'm most likely to only understand what I called "peer" comparisons, I'm interested in all. Edit: Further apologies in that I am likely not going to be able to respond for a while at this point. So, thanks for the discourse!
      - papsosouid 14y ago
        >They got stronger with time 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.