On Fri, Dec 25, 2009 at 4: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
>

This is something that there is a desire to address but the committers don't
seem to have enough time available to compile a comprehensive list of
specifics. The more specifics you can share and we can discuss, the better.
And the more that can get addressed before the upcoming release, the better.

- The documentation is unstructured
>

Again, please help us address this by pointing out specifics.


> - 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.
>

A graphical flowchart is a great idea. Can the GitHub wiki display pictures?
Otherwise it would have to go into the PDF book.

 - 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.
>

See
http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html
-
I'm not saying you don't have a point but read the above for context.


>  - 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.
>

It would be great if there was a more reusable component for representing
users but the "Proto" in the name means that it's just a prototypical
approach. I wonder if it technically belongs in the examples or
archetypes...

 - 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.
>

I hope so too. Please open a discussion on any such set of inconsistencies,
and if there's no objection file tickets.

 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]
>

--

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.


Reply via email to