On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: > It would be really good for us as a team to know what it is you *dont* > get? Is it conceptual? code? If we can understand what is daunting for > newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples.
However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with "<lift:" tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to "expect it to be next" without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like "User with LastName with EmailField with Password..." that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la "cached_?" and sometimes "isCached", sometimes methods use Box[]es for no apparent reason, sometimes you use "object"s and sometimes "val"s and so on. I've stopped thinking about this since I've memorized the most important parts of Lift, but this is something you stumble over as a newbie. I hope that this will be largely corrected in 1.1/2.0. When I started using Lift, I almost immediately went back to the Step "framework" [0] since it was so much easier to understand but still actually useful and powerful. Only after a while did I dare go back to Lift again. [0] http://github.com/alandipert/step > > Cheers, Tim > David Flemström david.flemst...@gmail.com
signature.asc
Description: This is a digitally signed message part.
