On Fri, Dec 25, 2009 at 7:19 PM, 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. > This does bother me a bit, although it used to a lot more. :) It's interesting to know where it comes from! In any case, while the less the better, I think it's okay for a web framework to have some of its own conventions. > * 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. > MetaMegaProtoUser translation: ProtoUser = Prototypical User model: it's really sample code but it's provided in the main mapper package because many sites would do just fine with it, IIUC. MegaProtoUser = adds a lot of functionality to ProtoUser. Meta = mix this trait into the meta singleton object that Mapper classes use. If you don't want to use this class doesn't mean you can't use the rest of Mapper. > * Some exceptions seem to just get eaten and I have no idea where > things went wrong > Lift is not a super-mature 10-year old framework that is claims to be perfect. That said, some things may seem to be imperfections when they are actually meant to be that way. In addition bugs are constantly being fixed. If you are having trouble with something please share it with the list. Response times are generally very short. > * 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. > Again, I think there is a willingness to do something about this but we need your feedback. How would you categorize the concerns that S and LiftRules address? How would you like to see that categorization reflected in the API? > > * 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 :) > Every release is "post" the previous release. :) Which concepts were invented? For no reason? > 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. > Examples? > > 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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- 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.
