Eh... sorry, ignore the point about Box in the previous message. I looked it up while posting but forgot to delete that paragraph. I do understand where it may be useful in some cases.
On Dec 26, 2:19 am, Erkki Lindpere <[email protected]> wrote: > 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.
