I mostly agree with what David said and I'll add this: * I think _? and _! in methods come from Ruby, but they don't fit the naming conventions in Java/Scala (I think Scala should mostly follow Java conventions with some exceptions). This is a really minor point though.
* object User extends User with MetaMegaProtoUser[User]. ProtoUser should just go away, the namings are ridiculous and it mixes HTML with persistence. Luckily one can just ignore the whole mapper module. * Some exceptions seem to just get eaten and I have no idea where things went wrong * I haven't taken a closer look at Box yet, but I understand that they are like Option, but have a third possibility of capturing an exceptional situation. Is this really better than using Exceptions? While Java's checked exceptions may have proven to be a failure, I don't think it's necessary. * there are several classes that have lots of methods in them that don't all belong together. For example: S, LiftRules, I'm sure there's more. Some packages have too many classes as well. I think there should be a cleaner separation of concerns. * I find Lift to be generally concept-heavy and invents new concepts instead of reusing well-known ones. You have to know much to use it effectively. I do not think Lift in it's current form is usable for "average" developers. Maybe that isn't the goal, but this makes me think there should be a post-Lift framework that takes all the good things, makes it better structured and documented and generally more usable by "normal" people :) Disclaimer: a lot of this might come from the fact that I'm not very used to functional programming. Even as I've used Scala almost daily for a year and a half (and even a little bit at my day job) I find Lift's programming style foreign at times. I would really prefer a more OO solution in quite a few places where Lift solves things in a functional way. Erkki L On Dec 25, 11:55 pm, David Flemström <[email protected]> wrote: > 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 > [email protected] > > signature.asc > < 1KViewDownload -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
