Re: [Lift] Re: Lift is awesome (with reservations)
Okay, Erkki, I suppose you should just post all your thoughts to the list. We're eagerly awaiting them! On Wed, Dec 30, 2009 at 6:06 PM, Naftoli Gugenheim wrote: > Okay, I hear what your saying. Personally I think it's partially how you > sell it, but if you think it will supress discussion then I guess we can > just discuss it directly on the list. > What do you say to having, in general, one thread per class being discussed > (that is, assuming people stick to the idea to focus on one class at a > time), and prefixing the subject with [naming] or something like that? > > > - > Jim Barrows wrote: > > Note: I just realized this was gonig to the list, and individual emails as > well. edited the to and cc fields. > > On Wed, Dec 30, 2009 at 2:22 PM, Naftoli Gugenheim >wrote: > > > I'm confused by your reply. > > Firstly, I think I was clear that I'm not going to do anything that you > or > > David disapprove of. So if my idea is not a good one just scratch it! > > In any case I'm confused by what you said. What is "hidden" about a > Google > > Docs document? Whoever wants to participate in the discussion can write > in > > the document. > > > > The first problem is that anyone who might wish to comment hase to know > about it. How often people either not check, not check thoroughly enough > the existing mailing list as it is?So now you want them to read the > mailing list or the wiki to find out about a discussion happening someplace > else? That's going to complicate matters a whole lot. > > The second problem is that you won't be able to get away from the > implication that things are being done behind the communities back. > Pretty > much no matter what you do. Again the problem is human beings. Everybody > is not going to search, and some people are going to feel like that without > a personal invitation to "join the elite working way over here", they have > no opportunity to participate. > > The spreadsheet I created is just a data tracker. I fully expect, and > encourage the discussions to happen on the lists. The limited number of > people who can write to it is to prevent discussions happening away from > the > list, not to limit the discussion itself. That's why it has columns to put > links to discussion on it. > > And if three people, or ten, discuss it there and then run it by everyone > on > > the list, those people will certainly not ignore what others on the list > > have to say. > > Was I unclear in the previous message? Or is my ignorance of Google Docs > at > > play? Or did I misunderstand something? > > > > > There's a huge difference between people working together, coming to the > list and going what's the best way to solve 'X', or we think 'Y' would > better the 'X' because of blah blah, and people working together and coming > to the list and going "Change this!".There's an even bigger difference > when the latter are some sort of "Refactor and Reorganize Lift Committee". > > > Thanks. > > > > - > > Jim Barrows wrote: > > > > On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim < > naftoli...@gmail.com > > >wrote: > > > > > 100%. > > > But that need could be reconciled with my idea in either of two ways: > > > 1. There is discussion taking place, just in the Google Docs file as > > > opposed to the maling list. Anyone who wants can participate. The point > > is > > > that I suspect much of the reason everyone wants better naming but no > one > > is > > > doing anything, is because there's a lot of overhead besides the actual > > act > > > of discussion. I think we need an approach that lets people 'just > > discuss' > > > the names in context, without any extra work like copy pasting into > > > spreadsheets etc. > > > > > > > > > So, you're trying to drive disucssion to some place hidden from the rest > of > > the list (and by list I mean, users and creators of Lift). > > > > > > > > > 2. If that's not satisfactory, then we can summarize the discussion on > > the > > > list or just run the "conclusion" by everyone on the list. This way the > > > discussion itself will remain lighweight and overhead-less, but it will > > > still have to go through public scrutiny on the list before any ticket > is > > > filed. > > > > > > > > > To present the users and creators of Lift with, essentially, a fait > > accompli? > > > > Leave me out of that one. > > > > > > > > > Of course if you still object we're all ears! > > > Thanks. > > > > > > > > > - > > > David Pollak wrote: > > > > > > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim < > naftoli...@gmail.com > > > >wrote: > > > > > > > Does anyone object to this approach? > > > > Any source file that's being reviewed (hopefully one or very few at a > > > time) > > > > should be uploaded to Google Docs as a text document. Discussion can > > > consist > > > > of the built in google chat functionality but mainly by insertin
Re: [Lift] Re: Lift is awesome (with reservations)
Okay, I hear what your saying. Personally I think it's partially how you sell it, but if you think it will supress discussion then I guess we can just discuss it directly on the list. What do you say to having, in general, one thread per class being discussed (that is, assuming people stick to the idea to focus on one class at a time), and prefixing the subject with [naming] or something like that? - Jim Barrows wrote: Note: I just realized this was gonig to the list, and individual emails as well. edited the to and cc fields. On Wed, Dec 30, 2009 at 2:22 PM, Naftoli Gugenheim wrote: > I'm confused by your reply. > Firstly, I think I was clear that I'm not going to do anything that you or > David disapprove of. So if my idea is not a good one just scratch it! > In any case I'm confused by what you said. What is "hidden" about a Google > Docs document? Whoever wants to participate in the discussion can write in > the document. > The first problem is that anyone who might wish to comment hase to know about it. How often people either not check, not check thoroughly enough the existing mailing list as it is?So now you want them to read the mailing list or the wiki to find out about a discussion happening someplace else? That's going to complicate matters a whole lot. The second problem is that you won't be able to get away from the implication that things are being done behind the communities back. Pretty much no matter what you do. Again the problem is human beings. Everybody is not going to search, and some people are going to feel like that without a personal invitation to "join the elite working way over here", they have no opportunity to participate. The spreadsheet I created is just a data tracker. I fully expect, and encourage the discussions to happen on the lists. The limited number of people who can write to it is to prevent discussions happening away from the list, not to limit the discussion itself. That's why it has columns to put links to discussion on it. And if three people, or ten, discuss it there and then run it by everyone on > the list, those people will certainly not ignore what others on the list > have to say. > Was I unclear in the previous message? Or is my ignorance of Google Docs at > play? Or did I misunderstand something? > There's a huge difference between people working together, coming to the list and going what's the best way to solve 'X', or we think 'Y' would better the 'X' because of blah blah, and people working together and coming to the list and going "Change this!".There's an even bigger difference when the latter are some sort of "Refactor and Reorganize Lift Committee". Thanks. > > - > Jim Barrows wrote: > > On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim >wrote: > > > 100%. > > But that need could be reconciled with my idea in either of two ways: > > 1. There is discussion taking place, just in the Google Docs file as > > opposed to the maling list. Anyone who wants can participate. The point > is > > that I suspect much of the reason everyone wants better naming but no one > is > > doing anything, is because there's a lot of overhead besides the actual > act > > of discussion. I think we need an approach that lets people 'just > discuss' > > the names in context, without any extra work like copy pasting into > > spreadsheets etc. > > > > > So, you're trying to drive disucssion to some place hidden from the rest of > the list (and by list I mean, users and creators of Lift). > > > > > 2. If that's not satisfactory, then we can summarize the discussion on > the > > list or just run the "conclusion" by everyone on the list. This way the > > discussion itself will remain lighweight and overhead-less, but it will > > still have to go through public scrutiny on the list before any ticket is > > filed. > > > > > To present the users and creators of Lift with, essentially, a fait > accompli? > > Leave me out of that one. > > > > > Of course if you still object we're all ears! > > Thanks. > > > > > > - > > David Pollak wrote: > > > > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim > >wrote: > > > > > Does anyone object to this approach? > > > Any source file that's being reviewed (hopefully one or very few at a > > time) > > > should be uploaded to Google Docs as a text document. Discussion can > > consist > > > of the built in google chat functionality but mainly by inserting a ((( > > ... > > > ))) section in scaladoc comments and writing your name and thoughts > > there. > > > The advantage to this "poor man's code review" is that there's no > > overhead > > > for someone to join the effort - no arranging things in a spreadsheet > or > > > linking threads. I suspect that may have been an impediment until now. > > > Of course nothing will be merged back from there; it's just a context > for > > > discussion that may lead t
Re: [Lift] Re: Lift is awesome (with reservations)
Note: I just realized this was gonig to the list, and individual emails as well. edited the to and cc fields. On Wed, Dec 30, 2009 at 2:22 PM, Naftoli Gugenheim wrote: > I'm confused by your reply. > Firstly, I think I was clear that I'm not going to do anything that you or > David disapprove of. So if my idea is not a good one just scratch it! > In any case I'm confused by what you said. What is "hidden" about a Google > Docs document? Whoever wants to participate in the discussion can write in > the document. > The first problem is that anyone who might wish to comment hase to know about it. How often people either not check, not check thoroughly enough the existing mailing list as it is?So now you want them to read the mailing list or the wiki to find out about a discussion happening someplace else? That's going to complicate matters a whole lot. The second problem is that you won't be able to get away from the implication that things are being done behind the communities back. Pretty much no matter what you do. Again the problem is human beings. Everybody is not going to search, and some people are going to feel like that without a personal invitation to "join the elite working way over here", they have no opportunity to participate. The spreadsheet I created is just a data tracker. I fully expect, and encourage the discussions to happen on the lists. The limited number of people who can write to it is to prevent discussions happening away from the list, not to limit the discussion itself. That's why it has columns to put links to discussion on it. And if three people, or ten, discuss it there and then run it by everyone on > the list, those people will certainly not ignore what others on the list > have to say. > Was I unclear in the previous message? Or is my ignorance of Google Docs at > play? Or did I misunderstand something? > There's a huge difference between people working together, coming to the list and going what's the best way to solve 'X', or we think 'Y' would better the 'X' because of blah blah, and people working together and coming to the list and going "Change this!".There's an even bigger difference when the latter are some sort of "Refactor and Reorganize Lift Committee". Thanks. > > - > Jim Barrows wrote: > > On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim >wrote: > > > 100%. > > But that need could be reconciled with my idea in either of two ways: > > 1. There is discussion taking place, just in the Google Docs file as > > opposed to the maling list. Anyone who wants can participate. The point > is > > that I suspect much of the reason everyone wants better naming but no one > is > > doing anything, is because there's a lot of overhead besides the actual > act > > of discussion. I think we need an approach that lets people 'just > discuss' > > the names in context, without any extra work like copy pasting into > > spreadsheets etc. > > > > > So, you're trying to drive disucssion to some place hidden from the rest of > the list (and by list I mean, users and creators of Lift). > > > > > 2. If that's not satisfactory, then we can summarize the discussion on > the > > list or just run the "conclusion" by everyone on the list. This way the > > discussion itself will remain lighweight and overhead-less, but it will > > still have to go through public scrutiny on the list before any ticket is > > filed. > > > > > To present the users and creators of Lift with, essentially, a fait > accompli? > > Leave me out of that one. > > > > > Of course if you still object we're all ears! > > Thanks. > > > > > > - > > David Pollak wrote: > > > > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim > >wrote: > > > > > Does anyone object to this approach? > > > Any source file that's being reviewed (hopefully one or very few at a > > time) > > > should be uploaded to Google Docs as a text document. Discussion can > > consist > > > of the built in google chat functionality but mainly by inserting a ((( > > ... > > > ))) section in scaladoc comments and writing your name and thoughts > > there. > > > The advantage to this "poor man's code review" is that there's no > > overhead > > > for someone to join the effort - no arranging things in a spreadsheet > or > > > linking threads. I suspect that may have been an impediment until now. > > > Of course nothing will be merged back from there; it's just a context > for > > > discussion that may lead to tickets. > > > > > > > In general, folks shouldn't open tickets without a discussion on this > list > > and at least a nod from me, Marius, Derek or Tim. There are some > > exceptions > > to this general rule. For example, if there's an actual defect (e.g., > NPE > > de-serializing JSON data structures and you include a reproduceable case) > > or > > if you are me, Marius, Derek or Tim and you're queuing up work for > > yourself. > > > > Why? (1) the curren
Re: [Lift] Re: Lift is awesome (with reservations)
I'm confused by your reply. Firstly, I think I was clear that I'm not going to do anything that you or David disapprove of. So if my idea is not a good one just scratch it! In any case I'm confused by what you said. What is "hidden" about a Google Docs document? Whoever wants to participate in the discussion can write in the document. And if three people, or ten, discuss it there and then run it by everyone on the list, those people will certainly not ignore what others on the list have to say. Was I unclear in the previous message? Or is my ignorance of Google Docs at play? Or did I misunderstand something? Thanks. - Jim Barrows wrote: On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim wrote: > 100%. > But that need could be reconciled with my idea in either of two ways: > 1. There is discussion taking place, just in the Google Docs file as > opposed to the maling list. Anyone who wants can participate. The point is > that I suspect much of the reason everyone wants better naming but no one is > doing anything, is because there's a lot of overhead besides the actual act > of discussion. I think we need an approach that lets people 'just discuss' > the names in context, without any extra work like copy pasting into > spreadsheets etc. > So, you're trying to drive disucssion to some place hidden from the rest of the list (and by list I mean, users and creators of Lift). > 2. If that's not satisfactory, then we can summarize the discussion on the > list or just run the "conclusion" by everyone on the list. This way the > discussion itself will remain lighweight and overhead-less, but it will > still have to go through public scrutiny on the list before any ticket is > filed. > To present the users and creators of Lift with, essentially, a fait accompli? Leave me out of that one. > Of course if you still object we're all ears! > Thanks. > > > - > David Pollak wrote: > > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim >wrote: > > > Does anyone object to this approach? > > Any source file that's being reviewed (hopefully one or very few at a > time) > > should be uploaded to Google Docs as a text document. Discussion can > consist > > of the built in google chat functionality but mainly by inserting a ((( > ... > > ))) section in scaladoc comments and writing your name and thoughts > there. > > The advantage to this "poor man's code review" is that there's no > overhead > > for someone to join the effort - no arranging things in a spreadsheet or > > linking threads. I suspect that may have been an impediment until now. > > Of course nothing will be merged back from there; it's just a context for > > discussion that may lead to tickets. > > > > In general, folks shouldn't open tickets without a discussion on this list > and at least a nod from me, Marius, Derek or Tim. There are some > exceptions > to this general rule. For example, if there's an actual defect (e.g., NPE > de-serializing JSON data structures and you include a reproduceable case) > or > if you are me, Marius, Derek or Tim and you're queuing up work for > yourself. > > Why? (1) the current ticketing system does not allow for good discussion > of > things and the whole community is not involved (2) one person's "defect" is > another person's feature so having a discussion to keep things oriented > towards where Lift is going is a lot better on list and (3) some tickets > like "write more documentation" serve no purpose because there's no person > attached to the work and those kinds of tickets just clutter the ticketing > system which doesn't have good filtering or prioritization tools as it is. > > > > > > > > - > > Erkki Lindpere wrote: > > > > I just noticed that GitHub also lets you comment on *commits*, but not > > files :( > > > > But Google Docs or whatever you end up deciding on works for me. > > > > On Dec 29, 11:42 pm, Ross Mellgren wrote: > > > We have a code review board (reviewboard.liftweb.net), but it's pretty > > > geared towards changes. I don't know if it can be configured or used > > > or what-have-you for reviewing the current state of code. > > > > > > -Ross > > > > > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > > > > > Another option would be to use a specialized code review tool, though > > > > someone would have to host it. There's one thing that may not fit > > > > about these, though: usually they are for reviewing *changes* and not > > > > existing code. I don't know what the good ones are, but some > otherwise > > > > commercial products are free for Open Source projects (all of these > > > > list Git support as well): > > > > > > > SmartBear CodeCollaborator / CodeReviewer > > > >http://smartbear.com/codecollab.php > > > >http://smartbear.com/codecollab-buy.php<-- about open source > > > > licensing > > > > > > > Atlassian Crucible > > > >http://www.atlassian.com/software
[Lift] Re: Lift is awesome (with reservations)
David, I actually really appreciate what you and others have done with Lift and please don't take all I've said as criticism. When I said that I realized I have to view Lift through FP goggles instead of OO ones, I'm not saying that is bad, but that it was unusual for me (and probably lots of web developers coming from Java, PHP etc.). I do realize that inventing new concepts is a core value of Lift and maybe I was expecting too much Java- or Scalaish conventions where some of the things might come from the other influences you listed or be good inventions in their own regard. But I am quite certain that there are some simple things that can be done to make the code easier to look at: moving things into separate packages and moving some functions out of the classes where they don't conceptually belong, if separation of concerns is at all a goal. Those things were behind some of my thoughts that Lift could follow more OO conventions, but I guess that isn't really about OO, but modularity. I do not mean deep hierarchies or abstract factories or GOF patterns when I say OO, but mostly separation of concerns, and a bit less importantly, encapsulation. Then again, I might have a different idea from you about what Lift's concerns are. For concrete examples, I don't think any Atom stuff belongs directly under the general HTTP package... that Req doesn't really need a fixHtml function, it could easily be somewhere else that has more to do with HTML and less with requests generally. Some of these changes could probably be made even while retaining backwards compatibility (through a separate compatibility layer and/or deprecated old methods delegating to the new ones). I think it would be easier after a version of Lift has moved to Scala 2.8 where package objects are available. Now this may be just my opinion, but I think when different concepts are lumped together into large flat packages or large classes -- it makes things harder to understand and use, not easier. If you don't share that thought and wouldn't accept those kind of changes to Lift, I will not do the review. However I was asked to name specific things I find hard to understand but I don't want to go half way and just name a couple of things I happened upon: I'm either going to go through most of lift-webkit and write down my opinion of how to categorize things better in it or I'll not go through any of it. If I did go through it, I could help with documentation while doing so. About documentation: I agree that it doesn't suck, but I think there should at least be a better index to it. Maybe a simple wiki page or two full of categorized links would do. Erkki L -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim wrote: > 100%. > But that need could be reconciled with my idea in either of two ways: > 1. There is discussion taking place, just in the Google Docs file as > opposed to the maling list. Anyone who wants can participate. The point is > that I suspect much of the reason everyone wants better naming but no one is > doing anything, is because there's a lot of overhead besides the actual act > of discussion. I think we need an approach that lets people 'just discuss' > the names in context, without any extra work like copy pasting into > spreadsheets etc. > So, you're trying to drive disucssion to some place hidden from the rest of the list (and by list I mean, users and creators of Lift). > 2. If that's not satisfactory, then we can summarize the discussion on the > list or just run the "conclusion" by everyone on the list. This way the > discussion itself will remain lighweight and overhead-less, but it will > still have to go through public scrutiny on the list before any ticket is > filed. > To present the users and creators of Lift with, essentially, a fait accompli? Leave me out of that one. > Of course if you still object we're all ears! > Thanks. > > > - > David Pollak wrote: > > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim >wrote: > > > Does anyone object to this approach? > > Any source file that's being reviewed (hopefully one or very few at a > time) > > should be uploaded to Google Docs as a text document. Discussion can > consist > > of the built in google chat functionality but mainly by inserting a ((( > ... > > ))) section in scaladoc comments and writing your name and thoughts > there. > > The advantage to this "poor man's code review" is that there's no > overhead > > for someone to join the effort - no arranging things in a spreadsheet or > > linking threads. I suspect that may have been an impediment until now. > > Of course nothing will be merged back from there; it's just a context for > > discussion that may lead to tickets. > > > > In general, folks shouldn't open tickets without a discussion on this list > and at least a nod from me, Marius, Derek or Tim. There are some > exceptions > to this general rule. For example, if there's an actual defect (e.g., NPE > de-serializing JSON data structures and you include a reproduceable case) > or > if you are me, Marius, Derek or Tim and you're queuing up work for > yourself. > > Why? (1) the current ticketing system does not allow for good discussion > of > things and the whole community is not involved (2) one person's "defect" is > another person's feature so having a discussion to keep things oriented > towards where Lift is going is a lot better on list and (3) some tickets > like "write more documentation" serve no purpose because there's no person > attached to the work and those kinds of tickets just clutter the ticketing > system which doesn't have good filtering or prioritization tools as it is. > > > > > > > > - > > Erkki Lindpere wrote: > > > > I just noticed that GitHub also lets you comment on *commits*, but not > > files :( > > > > But Google Docs or whatever you end up deciding on works for me. > > > > On Dec 29, 11:42 pm, Ross Mellgren wrote: > > > We have a code review board (reviewboard.liftweb.net), but it's pretty > > > geared towards changes. I don't know if it can be configured or used > > > or what-have-you for reviewing the current state of code. > > > > > > -Ross > > > > > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > > > > > Another option would be to use a specialized code review tool, though > > > > someone would have to host it. There's one thing that may not fit > > > > about these, though: usually they are for reviewing *changes* and not > > > > existing code. I don't know what the good ones are, but some > otherwise > > > > commercial products are free for Open Source projects (all of these > > > > list Git support as well): > > > > > > > SmartBear CodeCollaborator / CodeReviewer > > > >http://smartbear.com/codecollab.php > > > >http://smartbear.com/codecollab-buy.php<-- about open source > > > > licensing > > > > > > > Atlassian Crucible > > > >http://www.atlassian.com/software/crucible/ > > > > > > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > > > > <-- about open source licensing > > > > > > > I know there are some open source ones as well, personally I've only > > > > used Crucible once and an open source tool a long time ago (don't > > > > remember which one). > > > > > > > Or how about writing a simple code review app in lift as an example > > > > project :) > > > > > > > Erkki L > > > > > > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > > > >> Neat, thanks! > > > >> Where to post it is a very, very good question. I would suggest not > > > >> to invest much in a particular medium before you help us > > > >> crystalli
Re: [Lift] Re: Lift is awesome (with reservations)
100%. But that need could be reconciled with my idea in either of two ways: 1. There is discussion taking place, just in the Google Docs file as opposed to the maling list. Anyone who wants can participate. The point is that I suspect much of the reason everyone wants better naming but no one is doing anything, is because there's a lot of overhead besides the actual act of discussion. I think we need an approach that lets people 'just discuss' the names in context, without any extra work like copy pasting into spreadsheets etc. 2. If that's not satisfactory, then we can summarize the discussion on the list or just run the "conclusion" by everyone on the list. This way the discussion itself will remain lighweight and overhead-less, but it will still have to go through public scrutiny on the list before any ticket is filed. Of course if you still object we're all ears! Thanks. - David Pollak wrote: On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim wrote: > Does anyone object to this approach? > Any source file that's being reviewed (hopefully one or very few at a time) > should be uploaded to Google Docs as a text document. Discussion can consist > of the built in google chat functionality but mainly by inserting a ((( ... > ))) section in scaladoc comments and writing your name and thoughts there. > The advantage to this "poor man's code review" is that there's no overhead > for someone to join the effort - no arranging things in a spreadsheet or > linking threads. I suspect that may have been an impediment until now. > Of course nothing will be merged back from there; it's just a context for > discussion that may lead to tickets. > In general, folks shouldn't open tickets without a discussion on this list and at least a nod from me, Marius, Derek or Tim. There are some exceptions to this general rule. For example, if there's an actual defect (e.g., NPE de-serializing JSON data structures and you include a reproduceable case) or if you are me, Marius, Derek or Tim and you're queuing up work for yourself. Why? (1) the current ticketing system does not allow for good discussion of things and the whole community is not involved (2) one person's "defect" is another person's feature so having a discussion to keep things oriented towards where Lift is going is a lot better on list and (3) some tickets like "write more documentation" serve no purpose because there's no person attached to the work and those kinds of tickets just clutter the ticketing system which doesn't have good filtering or prioritization tools as it is. > > > - > Erkki Lindpere wrote: > > I just noticed that GitHub also lets you comment on *commits*, but not > files :( > > But Google Docs or whatever you end up deciding on works for me. > > On Dec 29, 11:42 pm, Ross Mellgren wrote: > > We have a code review board (reviewboard.liftweb.net), but it's pretty > > geared towards changes. I don't know if it can be configured or used > > or what-have-you for reviewing the current state of code. > > > > -Ross > > > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > > > Another option would be to use a specialized code review tool, though > > > someone would have to host it. There's one thing that may not fit > > > about these, though: usually they are for reviewing *changes* and not > > > existing code. I don't know what the good ones are, but some otherwise > > > commercial products are free for Open Source projects (all of these > > > list Git support as well): > > > > > SmartBear CodeCollaborator / CodeReviewer > > >http://smartbear.com/codecollab.php > > >http://smartbear.com/codecollab-buy.php<-- about open source > > > licensing > > > > > Atlassian Crucible > > >http://www.atlassian.com/software/crucible/ > > > > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > > > <-- about open source licensing > > > > > I know there are some open source ones as well, personally I've only > > > used Crucible once and an open source tool a long time ago (don't > > > remember which one). > > > > > Or how about writing a simple code review app in lift as an example > > > project :) > > > > > Erkki L > > > > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > > >> Neat, thanks! > > >> Where to post it is a very, very good question. I would suggest not > > >> to invest much in a particular medium before you help us > > >> crystallize a good answer! > > >> (Attention all interested in the naming progess: I think we made > > >> good progress in terms of guidelines, and I think the next step is > > >> to discuss this question!) > > >> Originally the idea was to keep an organized Google Docs > > >> spreadsheet. I am not sure how sustainable the approach is though, > > >> because the amount of overhead may weigh it down too much. I am > > >> curious if that is part of why not much progress has been made. > > >> Jim, if you're reading this (I hope y
Re: [Lift] Re: Lift is awesome (with reservations)
On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim wrote: > Does anyone object to this approach? > Any source file that's being reviewed (hopefully one or very few at a time) > should be uploaded to Google Docs as a text document. Discussion can consist > of the built in google chat functionality but mainly by inserting a ((( ... > ))) section in scaladoc comments and writing your name and thoughts there. > The advantage to this "poor man's code review" is that there's no overhead > for someone to join the effort - no arranging things in a spreadsheet or > linking threads. I suspect that may have been an impediment until now. > Of course nothing will be merged back from there; it's just a context for > discussion that may lead to tickets. > In general, folks shouldn't open tickets without a discussion on this list and at least a nod from me, Marius, Derek or Tim. There are some exceptions to this general rule. For example, if there's an actual defect (e.g., NPE de-serializing JSON data structures and you include a reproduceable case) or if you are me, Marius, Derek or Tim and you're queuing up work for yourself. Why? (1) the current ticketing system does not allow for good discussion of things and the whole community is not involved (2) one person's "defect" is another person's feature so having a discussion to keep things oriented towards where Lift is going is a lot better on list and (3) some tickets like "write more documentation" serve no purpose because there's no person attached to the work and those kinds of tickets just clutter the ticketing system which doesn't have good filtering or prioritization tools as it is. > > > - > Erkki Lindpere wrote: > > I just noticed that GitHub also lets you comment on *commits*, but not > files :( > > But Google Docs or whatever you end up deciding on works for me. > > On Dec 29, 11:42 pm, Ross Mellgren wrote: > > We have a code review board (reviewboard.liftweb.net), but it's pretty > > geared towards changes. I don't know if it can be configured or used > > or what-have-you for reviewing the current state of code. > > > > -Ross > > > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > > > Another option would be to use a specialized code review tool, though > > > someone would have to host it. There's one thing that may not fit > > > about these, though: usually they are for reviewing *changes* and not > > > existing code. I don't know what the good ones are, but some otherwise > > > commercial products are free for Open Source projects (all of these > > > list Git support as well): > > > > > SmartBear CodeCollaborator / CodeReviewer > > >http://smartbear.com/codecollab.php > > >http://smartbear.com/codecollab-buy.php<-- about open source > > > licensing > > > > > Atlassian Crucible > > >http://www.atlassian.com/software/crucible/ > > > > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > > > <-- about open source licensing > > > > > I know there are some open source ones as well, personally I've only > > > used Crucible once and an open source tool a long time ago (don't > > > remember which one). > > > > > Or how about writing a simple code review app in lift as an example > > > project :) > > > > > Erkki L > > > > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > > >> Neat, thanks! > > >> Where to post it is a very, very good question. I would suggest not > > >> to invest much in a particular medium before you help us > > >> crystallize a good answer! > > >> (Attention all interested in the naming progess: I think we made > > >> good progress in terms of guidelines, and I think the next step is > > >> to discuss this question!) > > >> Originally the idea was to keep an organized Google Docs > > >> spreadsheet. I am not sure how sustainable the approach is though, > > >> because the amount of overhead may weigh it down too much. I am > > >> curious if that is part of why not much progress has been made. > > >> Jim, if you're reading this (I hope you are!) can you comment? > > >> The problem with just filing tickets is that everyone has different > > >> ideas, so discussion may be necessary to arrive at a consensus. At > > >> least posting it here first means if someone objects he will have a > > >> chance to voice his objection. > > >> One idea is one discusson thread, in the main Lift list, per Lift > > >> class. If everyone focuses on one or a few classes at a time it > > >> won't clog the list too much. > > >> Another idea of mine is to put the lift source file on Google Docs > > >> as a text document, and people can contribute to the discussion by > > >> writing inside the scaladoc comments. Nothing will get merged > > >> directly back to git; it's just a very lightweight way of > > >> discussing. E.g.: > > >> /** > > >> X Xx xxx Xxx > > >> Erkki: why is xxx xx xxx > > >> nafg: well, xxx and xxx > > >> erkki: okay, but ... > > >> */ > > >> def someFoo ... >
Re: [Lift] Re: Lift is awesome (with reservations)
Does anyone object to this approach? Any source file that's being reviewed (hopefully one or very few at a time) should be uploaded to Google Docs as a text document. Discussion can consist of the built in google chat functionality but mainly by inserting a ((( ... ))) section in scaladoc comments and writing your name and thoughts there. The advantage to this "poor man's code review" is that there's no overhead for someone to join the effort - no arranging things in a spreadsheet or linking threads. I suspect that may have been an impediment until now. Of course nothing will be merged back from there; it's just a context for discussion that may lead to tickets. - Erkki Lindpere wrote: I just noticed that GitHub also lets you comment on *commits*, but not files :( But Google Docs or whatever you end up deciding on works for me. On Dec 29, 11:42 pm, Ross Mellgren wrote: > We have a code review board (reviewboard.liftweb.net), but it's pretty > geared towards changes. I don't know if it can be configured or used > or what-have-you for reviewing the current state of code. > > -Ross > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > Another option would be to use a specialized code review tool, though > > someone would have to host it. There's one thing that may not fit > > about these, though: usually they are for reviewing *changes* and not > > existing code. I don't know what the good ones are, but some otherwise > > commercial products are free for Open Source projects (all of these > > list Git support as well): > > > SmartBear CodeCollaborator / CodeReviewer > >http://smartbear.com/codecollab.php > >http://smartbear.com/codecollab-buy.php<-- about open source > > licensing > > > Atlassian Crucible > >http://www.atlassian.com/software/crucible/ > >http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > > <-- about open source licensing > > > I know there are some open source ones as well, personally I've only > > used Crucible once and an open source tool a long time ago (don't > > remember which one). > > > Or how about writing a simple code review app in lift as an example > > project :) > > > Erkki L > > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > >> Neat, thanks! > >> Where to post it is a very, very good question. I would suggest not > >> to invest much in a particular medium before you help us > >> crystallize a good answer! > >> (Attention all interested in the naming progess: I think we made > >> good progress in terms of guidelines, and I think the next step is > >> to discuss this question!) > >> Originally the idea was to keep an organized Google Docs > >> spreadsheet. I am not sure how sustainable the approach is though, > >> because the amount of overhead may weigh it down too much. I am > >> curious if that is part of why not much progress has been made. > >> Jim, if you're reading this (I hope you are!) can you comment? > >> The problem with just filing tickets is that everyone has different > >> ideas, so discussion may be necessary to arrive at a consensus. At > >> least posting it here first means if someone objects he will have a > >> chance to voice his objection. > >> One idea is one discusson thread, in the main Lift list, per Lift > >> class. If everyone focuses on one or a few classes at a time it > >> won't clog the list too much. > >> Another idea of mine is to put the lift source file on Google Docs > >> as a text document, and people can contribute to the discussion by > >> writing inside the scaladoc comments. Nothing will get merged > >> directly back to git; it's just a very lightweight way of > >> discussing. E.g.: > >> /** > >> X Xx xxx Xxx > >> Erkki: why is xxx xx xxx > >> nafg: well, xxx and xxx > >> erkki: okay, but ... > >> */ > >> def someFoo ... > > >> What do you think? Very out of the box but it means very little > >> copy-pasting work: the only overhead is uploading a source file; > >> the rest is pure discussion in an inherently organized context. > >> The disadvantage compared to threads on the list is that it won't > >> get as much automatic public scrutiny, but whoever wants can have > >> Google Docs email them any edits. > >> Thoughts, everyone? > >> Thanks. > > >> - > > >> Erkki Lindpere wrote: > > >> Hmm... actually seems like it will be a long document, I've already > >> got several suggestions with 10 minutes of looking. Maybe I'll do a > >> complete code review for the lift-webkit module if I have time / feel > >> like it. Where should I post it? There doesn't seem to be a separate > >> developers list. > > >> Erkki L > > >> On Dec 29, 7:58 pm, Erkki Lindpere wrote: > > >>> Ok, I'll collect some specific issues I have with the API over a bit > >>> longer period of usage and post them as an issue in GitHub? Or here? > > >>> Erkki L > > >>> On Dec 28, 4:40 am, Naftol
[Lift] Re: Lift is awesome (with reservations)
I just noticed that GitHub also lets you comment on *commits*, but not files :( But Google Docs or whatever you end up deciding on works for me. On Dec 29, 11:42 pm, Ross Mellgren wrote: > We have a code review board (reviewboard.liftweb.net), but it's pretty > geared towards changes. I don't know if it can be configured or used > or what-have-you for reviewing the current state of code. > > -Ross > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > > > Another option would be to use a specialized code review tool, though > > someone would have to host it. There's one thing that may not fit > > about these, though: usually they are for reviewing *changes* and not > > existing code. I don't know what the good ones are, but some otherwise > > commercial products are free for Open Source projects (all of these > > list Git support as well): > > > SmartBear CodeCollaborator / CodeReviewer > >http://smartbear.com/codecollab.php > >http://smartbear.com/codecollab-buy.php<-- about open source > > licensing > > > Atlassian Crucible > >http://www.atlassian.com/software/crucible/ > >http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > > <-- about open source licensing > > > I know there are some open source ones as well, personally I've only > > used Crucible once and an open source tool a long time ago (don't > > remember which one). > > > Or how about writing a simple code review app in lift as an example > > project :) > > > Erkki L > > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > >> Neat, thanks! > >> Where to post it is a very, very good question. I would suggest not > >> to invest much in a particular medium before you help us > >> crystallize a good answer! > >> (Attention all interested in the naming progess: I think we made > >> good progress in terms of guidelines, and I think the next step is > >> to discuss this question!) > >> Originally the idea was to keep an organized Google Docs > >> spreadsheet. I am not sure how sustainable the approach is though, > >> because the amount of overhead may weigh it down too much. I am > >> curious if that is part of why not much progress has been made. > >> Jim, if you're reading this (I hope you are!) can you comment? > >> The problem with just filing tickets is that everyone has different > >> ideas, so discussion may be necessary to arrive at a consensus. At > >> least posting it here first means if someone objects he will have a > >> chance to voice his objection. > >> One idea is one discusson thread, in the main Lift list, per Lift > >> class. If everyone focuses on one or a few classes at a time it > >> won't clog the list too much. > >> Another idea of mine is to put the lift source file on Google Docs > >> as a text document, and people can contribute to the discussion by > >> writing inside the scaladoc comments. Nothing will get merged > >> directly back to git; it's just a very lightweight way of > >> discussing. E.g.: > >> /** > >> X Xx xxx Xxx > >> Erkki: why is xxx xx xxx > >> nafg: well, xxx and xxx > >> erkki: okay, but ... > >> */ > >> def someFoo ... > > >> What do you think? Very out of the box but it means very little > >> copy-pasting work: the only overhead is uploading a source file; > >> the rest is pure discussion in an inherently organized context. > >> The disadvantage compared to threads on the list is that it won't > >> get as much automatic public scrutiny, but whoever wants can have > >> Google Docs email them any edits. > >> Thoughts, everyone? > >> Thanks. > > >> - > > >> Erkki Lindpere wrote: > > >> Hmm... actually seems like it will be a long document, I've already > >> got several suggestions with 10 minutes of looking. Maybe I'll do a > >> complete code review for the lift-webkit module if I have time / feel > >> like it. Where should I post it? There doesn't seem to be a separate > >> developers list. > > >> Erkki L > > >> On Dec 29, 7:58 pm, Erkki Lindpere wrote: > > >>> Ok, I'll collect some specific issues I have with the API over a bit > >>> longer period of usage and post them as an issue in GitHub? Or here? > > >>> Erkki L > > >>> On Dec 28, 4:40 am, Naftoli Gugenheim wrote: > > > * 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? > > >> -- > > >> You received this message because you are subscribed to the Google > >> Groups "Lift" group. > >> To post to this group, send email t
Re: [Lift] Re: Lift is awesome (with reservations)
We have a code review board (reviewboard.liftweb.net), but it's pretty geared towards changes. I don't know if it can be configured or used or what-have-you for reviewing the current state of code. -Ross On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > Another option would be to use a specialized code review tool, though > someone would have to host it. There's one thing that may not fit > about these, though: usually they are for reviewing *changes* and not > existing code. I don't know what the good ones are, but some otherwise > commercial products are free for Open Source projects (all of these > list Git support as well): > > SmartBear CodeCollaborator / CodeReviewer > http://smartbear.com/codecollab.php > http://smartbear.com/codecollab-buy.php <-- about open source > licensing > > Atlassian Crucible > http://www.atlassian.com/software/crucible/ > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > <-- about open source licensing > > I know there are some open source ones as well, personally I've only > used Crucible once and an open source tool a long time ago (don't > remember which one). > > Or how about writing a simple code review app in lift as an example > project :) > > Erkki L > > On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: >> Neat, thanks! >> Where to post it is a very, very good question. I would suggest not >> to invest much in a particular medium before you help us >> crystallize a good answer! >> (Attention all interested in the naming progess: I think we made >> good progress in terms of guidelines, and I think the next step is >> to discuss this question!) >> Originally the idea was to keep an organized Google Docs >> spreadsheet. I am not sure how sustainable the approach is though, >> because the amount of overhead may weigh it down too much. I am >> curious if that is part of why not much progress has been made. >> Jim, if you're reading this (I hope you are!) can you comment? >> The problem with just filing tickets is that everyone has different >> ideas, so discussion may be necessary to arrive at a consensus. At >> least posting it here first means if someone objects he will have a >> chance to voice his objection. >> One idea is one discusson thread, in the main Lift list, per Lift >> class. If everyone focuses on one or a few classes at a time it >> won't clog the list too much. >> Another idea of mine is to put the lift source file on Google Docs >> as a text document, and people can contribute to the discussion by >> writing inside the scaladoc comments. Nothing will get merged >> directly back to git; it's just a very lightweight way of >> discussing. E.g.: >> /** >> X Xx xxx Xxx >> Erkki: why is xxx xx xxx >> nafg: well, xxx and xxx >> erkki: okay, but ... >> */ >> def someFoo ... >> >> What do you think? Very out of the box but it means very little >> copy-pasting work: the only overhead is uploading a source file; >> the rest is pure discussion in an inherently organized context. >> The disadvantage compared to threads on the list is that it won't >> get as much automatic public scrutiny, but whoever wants can have >> Google Docs email them any edits. >> Thoughts, everyone? >> Thanks. >> >> - >> >> Erkki Lindpere wrote: >> >> Hmm... actually seems like it will be a long document, I've already >> got several suggestions with 10 minutes of looking. Maybe I'll do a >> complete code review for the lift-webkit module if I have time / feel >> like it. Where should I post it? There doesn't seem to be a separate >> developers list. >> >> Erkki L >> >> On Dec 29, 7:58 pm, Erkki Lindpere wrote: >> >>> Ok, I'll collect some specific issues I have with the API over a bit >>> longer period of usage and post them as an issue in GitHub? Or here? >> >>> Erkki L >> >>> On Dec 28, 4:40 am, Naftoli Gugenheim wrote: >> > * 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? >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com >> . >> For more options, visit this group >> athttp://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
[Lift] Re: Lift is awesome (with reservations)
Another option would be to use a specialized code review tool, though someone would have to host it. There's one thing that may not fit about these, though: usually they are for reviewing *changes* and not existing code. I don't know what the good ones are, but some otherwise commercial products are free for Open Source projects (all of these list Git support as well): SmartBear CodeCollaborator / CodeReviewer http://smartbear.com/codecollab.php http://smartbear.com/codecollab-buy.php <-- about open source licensing Atlassian Crucible http://www.atlassian.com/software/crucible/ http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source <-- about open source licensing I know there are some open source ones as well, personally I've only used Crucible once and an open source tool a long time ago (don't remember which one). Or how about writing a simple code review app in lift as an example project :) Erkki L On Dec 29, 9:31 pm, Naftoli Gugenheim wrote: > Neat, thanks! > Where to post it is a very, very good question. I would suggest not to invest > much in a particular medium before you help us crystallize a good answer! > (Attention all interested in the naming progess: I think we made good > progress in terms of guidelines, and I think the next step is to discuss this > question!) > Originally the idea was to keep an organized Google Docs spreadsheet. I am > not sure how sustainable the approach is though, because the amount of > overhead may weigh it down too much. I am curious if that is part of why not > much progress has been made. Jim, if you're reading this (I hope you are!) > can you comment? > The problem with just filing tickets is that everyone has different ideas, so > discussion may be necessary to arrive at a consensus. At least posting it > here first means if someone objects he will have a chance to voice his > objection. > One idea is one discusson thread, in the main Lift list, per Lift class. If > everyone focuses on one or a few classes at a time it won't clog the list too > much. > Another idea of mine is to put the lift source file on Google Docs as a text > document, and people can contribute to the discussion by writing inside the > scaladoc comments. Nothing will get merged directly back to git; it's just a > very lightweight way of discussing. E.g.: > /** > X Xx xxx Xxx > Erkki: why is xxx xx xxx > nafg: well, xxx and xxx > erkki: okay, but ... > */ > def someFoo ... > > What do you think? Very out of the box but it means very little copy-pasting > work: the only overhead is uploading a source file; the rest is pure > discussion in an inherently organized context. > The disadvantage compared to threads on the list is that it won't get as much > automatic public scrutiny, but whoever wants can have Google Docs email them > any edits. > Thoughts, everyone? > Thanks. > > - > > Erkki Lindpere wrote: > > Hmm... actually seems like it will be a long document, I've already > got several suggestions with 10 minutes of looking. Maybe I'll do a > complete code review for the lift-webkit module if I have time / feel > like it. Where should I post it? There doesn't seem to be a separate > developers list. > > Erkki L > > On Dec 29, 7:58 pm, Erkki Lindpere wrote: > > > Ok, I'll collect some specific issues I have with the API over a bit > > longer period of usage and post them as an issue in GitHub? Or here? > > > Erkki L > > > On Dec 28, 4:40 am, Naftoli Gugenheim wrote: > > > > > * 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? > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
Neat, thanks! Where to post it is a very, very good question. I would suggest not to invest much in a particular medium before you help us crystallize a good answer! (Attention all interested in the naming progess: I think we made good progress in terms of guidelines, and I think the next step is to discuss this question!) Originally the idea was to keep an organized Google Docs spreadsheet. I am not sure how sustainable the approach is though, because the amount of overhead may weigh it down too much. I am curious if that is part of why not much progress has been made. Jim, if you're reading this (I hope you are!) can you comment? The problem with just filing tickets is that everyone has different ideas, so discussion may be necessary to arrive at a consensus. At least posting it here first means if someone objects he will have a chance to voice his objection. One idea is one discusson thread, in the main Lift list, per Lift class. If everyone focuses on one or a few classes at a time it won't clog the list too much. Another idea of mine is to put the lift source file on Google Docs as a text document, and people can contribute to the discussion by writing inside the scaladoc comments. Nothing will get merged directly back to git; it's just a very lightweight way of discussing. E.g.: /** X Xx xxx Xxx Erkki: why is xxx xx xxx nafg: well, xxx and xxx erkki: okay, but ... */ def someFoo ... What do you think? Very out of the box but it means very little copy-pasting work: the only overhead is uploading a source file; the rest is pure discussion in an inherently organized context. The disadvantage compared to threads on the list is that it won't get as much automatic public scrutiny, but whoever wants can have Google Docs email them any edits. Thoughts, everyone? Thanks. - Erkki Lindpere wrote: Hmm... actually seems like it will be a long document, I've already got several suggestions with 10 minutes of looking. Maybe I'll do a complete code review for the lift-webkit module if I have time / feel like it. Where should I post it? There doesn't seem to be a separate developers list. Erkki L On Dec 29, 7:58 pm, Erkki Lindpere wrote: > Ok, I'll collect some specific issues I have with the API over a bit > longer period of usage and post them as an issue in GitHub? Or here? > > Erkki L > > On Dec 28, 4:40 am, Naftoli Gugenheim wrote: > > > > * 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? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
Erkki, We use this same list for developer discussions as well. So, yes, this is where you are free to provide suggestion. Cheers, Indrajit On 29/12/09 11:56 PM, Erkki Lindpere wrote: > Hmm... actually seems like it will be a long document, I've already > got several suggestions with 10 minutes of looking. Maybe I'll do a > complete code review for the lift-webkit module if I have time / feel > like it. Where should I post it? There doesn't seem to be a separate > developers list. > > Erkki L > > On Dec 29, 7:58 pm, Erkki Lindpere wrote: >> Ok, I'll collect some specific issues I have with the API over a bit >> longer period of usage and post them as an issue in GitHub? Or here? >> >> Erkki L >> >> On Dec 28, 4:40 am, Naftoli Gugenheim wrote: >> * 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? > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Hmm... actually seems like it will be a long document, I've already got several suggestions with 10 minutes of looking. Maybe I'll do a complete code review for the lift-webkit module if I have time / feel like it. Where should I post it? There doesn't seem to be a separate developers list. Erkki L On Dec 29, 7:58 pm, Erkki Lindpere wrote: > Ok, I'll collect some specific issues I have with the API over a bit > longer period of usage and post them as an issue in GitHub? Or here? > > Erkki L > > On Dec 28, 4:40 am, Naftoli Gugenheim wrote: > > > > * 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? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Ok, I'll collect some specific issues I have with the API over a bit longer period of usage and post them as an issue in GitHub? Or here? Erkki L On Dec 28, 4:40 am, Naftoli Gugenheim wrote: > > * 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? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
If there's a better way you'd like to be able to do things -- something you'd like to see in Lift -- please share it with us, in a specific manner. Thanks! On Sun, Dec 27, 2009 at 10:49 PM, David Flemström wrote: > On Monday 28 December 2009 03:54:24 Naftoli Gugenheim wrote: > > Which is why they are called "Proto"User and CRUDify. If you need > something > > more custom, it's really not hard to build it. > > It seems that this is the point that I simply haven't forced myself to > understand yet. If this really is the case, then I'll just have to get used > to > it... I like the concept of "evolving" code meaning that I can write one > user > model, and expand on that model later without having to rewrite everything > form scratch. > > Anyways, thank you for your thought-through comments. I'll try to do some > code > reconnaissance later to see if I can find something else to nag about :-) > > David Flemström > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
On Monday 28 December 2009 03:54:24 Naftoli Gugenheim wrote: > Which is why they are called "Proto"User and CRUDify. If you need something > more custom, it's really not hard to build it. It seems that this is the point that I simply haven't forced myself to understand yet. If this really is the case, then I'll just have to get used to it... I like the concept of "evolving" code meaning that I can write one user model, and expand on that model later without having to rewrite everything form scratch. Anyways, thank you for your thought-through comments. I'll try to do some code reconnaissance later to see if I can find something else to nag about :-) David Flemström signature.asc Description: This is a digitally signed message part.
Re: [Lift] Re: Lift is awesome (with reservations)
On Sat, Dec 26, 2009 at 8:47 PM, David Flemström
wrote:
> On Saturday 26 December 2009 15:30:34 Marius wrote:
> > So I believe it is much more constructive for ALL of us to ask
> > concrete questions, described concrete problems and let's see how we
> > can fix it. Many things though may be subjective and leading to
> > endless discussions without substance.
> OK, then, concrete cases it is. I will try to transform the problems I
> mentioned before into concrete scenarios. Hopefully, this will shed some
> more
> light on what I mean.
>
> - I want a user system where each user registers with an user name and a
> password, nothing else (not First Name, Last Name, E-mail etc; there
> shouldn't
> be any entries for them in the DB either). For this, I would prefer to use
> pre-existing utility classes in the Lift framework so that I don't have to
> start from scratch (by extending LongKeyedMetaMapper etc), because, oh I
> don't
> know, I don't want to code the whole user session management and password
> exchange process by hand (even though it might not be too difficult; it's
> reinventing the wheel nonetheless). How do I proceed?
>
It's really not very hard to code this from scratch. ProtoUser doesn't do
much session management, and password management is handled by using a
MappedPassword field. Just create a mapper class with whatever data you
like, put in its singleton a SessionVar referencing the current user, and
build whatever screens you like however you would build any screen.
> - I'd like to use ProtoUser, but need to change the labels for some of the
> fields in the registration form because I want to localize the site. Please
> remember that ProtoUser uses "S.??", which makes it impossible to add
> translations and/or change the default wordings from the outside. How do I
> proceed with the least amount of hacks (like by writing
> field.displayName.replace("First Name", S.?("...")) + overriding the
> correct
> functions with slightly changed versions of their original code)?
>
I agree that ProtoUser could use some refactoring so that it's split into
independently reusable parts. I would say to file a ticket with specific
suggestions, after discussing them on the list.
> - I'd like to take a mapped object that I have, and CRUDify it (hint,
> hint).
> In my mapped object (e.g. an user), I have some fields that should always
> appear (e.g. basic contact information), some that should appear only to
> administrators (e.g. email addresses), and some that should be read-only to
> normal users and editable by administrators and specific users but not
> appear
> to unregistered users (e.g. user profile images). Columns that should be
> invisible should not be rendered in the CRUDify "list" with contents like
> "permission denied"; their rendered columns should rather not appear at
> all.
> How do I proceed with the least amount of hacks?
>
I'm not too familiar with CRUDify. Instead I wrote some classes in
net.liftweb.mapper.view and net.liftweb.mapper.util.BindPlus to help you
build pages from scratch more easily.
> - I'd like to use CRUDify again, but I need to use external templates
> (inside
> of HTML files) for the "list", "edit", etc... pages, since I need to change
> these templates after the application was compiled (or for some similar
> reason, like that view/model code should be separate). How do I proceed?
>
Did you search? I'm not sure offhand but I know it's been discussed. Not to
imply there's something wrong with asking, just telling you that it's there.
I think you have to subclass it and override the relevant members.
> - Same situation like the above (need to control the CRUDify templates from
> the outside), but I want to use a different HTML snippet depending on which
> field is being rendered (I don't want to use an uniform table for the view,
> but
> maybe one where some fields are stacked over another, or arranged in a
> different
> constellation). Like this:
> =
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =
> The ""s etc above are of course template-specific view code that
> mustn't be
> in the logic code.
> How do I do this with the least amount of hacks?
>
> These are of course scenarios that are fabricated but I've experienced
> similar
> ones that I've had problems with before; I don't know if there's some kind
> of
> solution to them that I've just missed (after some through looking, I gave
> up
> on most of them and just wrote everything form scratch by copy-pasting Lift
> source code). It all boils down to there being very specialized "starter"
> classes like ProtoUser and CRUDify, that cannot be used for anything but
> very
> small test sites in practice since they aren't extensible.
>
Which is why they are called "Proto"User and CRUDify. If you need something
more custom, it's really not hard to build it.
>
> >
> > Br's,
> > Marius
>
> PS. It may be that
Re: [Lift] Re: Lift is awesome (with reservations)
On Fri, Dec 25, 2009 at 7:32 PM, David Flemström wrote: > A propos: > On Sat, Dec 26, 2009 at 1:19 AM, Erkki Lindpere wrote: > > * 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. > Please see: > http://www.codecommit.com/scala-style-guide.pdf > ...which is the product of a recent discussion on scala-u...@epfl I > believe. > > Hmm.. He says names with underscore are *heavily* discouraged! Oh, well... :) > David Flemström > david.flemst...@gmail.com > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
On Fri, Dec 25, 2009 at 7:19 PM, Erkki Lindpere 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 > 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 > > " 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 al
Re: [Lift] Re: Lift is awesome (with reservations)
On Fri, Dec 25, 2009 at 4:55 PM, David Flemström 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 " 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 > > david.flemst...@gmail.com > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
On Dec 27, 4:24 pm, David Flemström wrote:
> On Sun, Dec 27, 2009 at 9:30 AM, Marius wrote:
> > In \liftweb\lift-examples\hellolift\src\main\scala\com\hellolift\model
> > \User.scala ... one of the Lift examples
>
> > There is something like:
>
> > object User extends User with MetaMegaProtoUser[User] {
> > override def dbTableName = "users"
> > override def screenWrap = Full( > at="content">
> > ) // LiftNote: 6
> > override def signupFields = firstName :: lastName :: email ::
> > locale :: timezone :: password :: blogtitle :: Nil
> > override val skipEmailValidation = true // LiftNote: 4
>
> > override val basePath: List[String] = "user_mgt" :: "usr" :: Nil
> > }
>
> > Have you tried setting the signupField list to use only the override
> > def signupFields = firstName :: password :: Nil ?
>
> This will only change what appears when the user registers. There will
> still be columns in the database for the fields you left out, and
> there will be entries for them on the user's settings page (last time
> I checked; I will check again).
>
>
>
> >> - I'd like to use ProtoUser, but need to change the labels for some of the
> >> fields in the registration form because I want to localize the site. Please
> >> remember that ProtoUser uses "S.??", which makes it impossible to add
> >> translations and/or change the default wordings from the outside. How do I
> >> proceed with the least amount of hacks (like by writing
> >> field.displayName.replace("First Name", S.?("...")) + overriding the
> >> correct
> >> functions with slightly changed versions of their original code)?
>
> > Why it makes it impossible? You can take lift-core.properties file and
> > put it in your WEB-INF/classes/i18n. Another approach is to tell Lift
> > from where it should take the core resource bundle. Thus in your boot
> > youcan say:
>
> > LiftRules.liftCoreResourceName = "my_bundles"
>
> > this is currently set to "i18n.lift-core"
>
> I did not know this, and it wasn't possible AFAIK last I tried (6
> months ago), so thank you for the information. This deserves more
> documentation, and I'd be happy to help out if I can.
IMHO contributions on documentation is always welcomed.
> Something that would be useful would be a tool that lists all of the
> available translation strings inside of LiftCore so that you don't
> have to search the source code for them. Also, why is something like
> "First Name" used for the translation key
I think this is a bug as the key looks invalid:
def firstNameDisplayName = ??("First Name")
>, and why is there a method
> called S.? and S.?? in the first place if the resource system can be
> unified anyways?
S.? is about user defined strings
S.?? is about strings used internally by Lift when generating markup
mostly. Thus we allow users to intenationalize Lift's strings
I don't think they should not be unified. Some Lift applications would
never use Lift's internal strings (if they don't use Mapper etc.) so
in such cases the user only needs to define the application specific
bundles.
>
> Hoping to hear other responses to the issues I mentioned, as well.
I hope so too :)
>
> David Flemström
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
On Sun, Dec 27, 2009 at 9:30 AM, Marius wrote:
> In \liftweb\lift-examples\hellolift\src\main\scala\com\hellolift\model
> \User.scala ... one of the Lift examples
>
> There is something like:
>
> object User extends User with MetaMegaProtoUser[User] {
> override def dbTableName = "users"
> override def screenWrap = Full( at="content">
> ) // LiftNote: 6
> override def signupFields = firstName :: lastName :: email ::
> locale :: timezone :: password :: blogtitle :: Nil
> override val skipEmailValidation = true // LiftNote: 4
>
> override val basePath: List[String] = "user_mgt" :: "usr" :: Nil
> }
>
> Have you tried setting the signupField list to use only the override
> def signupFields = firstName :: password :: Nil ?
This will only change what appears when the user registers. There will
still be columns in the database for the fields you left out, and
there will be entries for them on the user's settings page (last time
I checked; I will check again).
>> - I'd like to use ProtoUser, but need to change the labels for some of the
>> fields in the registration form because I want to localize the site. Please
>> remember that ProtoUser uses "S.??", which makes it impossible to add
>> translations and/or change the default wordings from the outside. How do I
>> proceed with the least amount of hacks (like by writing
>> field.displayName.replace("First Name", S.?("...")) + overriding the correct
>> functions with slightly changed versions of their original code)?
>
> Why it makes it impossible? You can take lift-core.properties file and
> put it in your WEB-INF/classes/i18n. Another approach is to tell Lift
> from where it should take the core resource bundle. Thus in your boot
> youcan say:
>
> LiftRules.liftCoreResourceName = "my_bundles"
>
> this is currently set to "i18n.lift-core"
I did not know this, and it wasn't possible AFAIK last I tried (6
months ago), so thank you for the information. This deserves more
documentation, and I'd be happy to help out if I can.
Something that would be useful would be a tool that lists all of the
available translation strings inside of LiftCore so that you don't
have to search the source code for them. Also, why is something like
"First Name" used for the translation key, and why is there a method
called S.? and S.?? in the first place if the resource system can be
unified anyways?
Hoping to hear other responses to the issues I mentioned, as well.
David Flemström
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
OK so most of your problems are around Mapper which is just a portion
of Lift. Please see my notes inline but other people more Mapper
knowlegeable then myself will likely reply. Hopefully their feedback
will be materialize on Lift Wiki.
Br's,
Marius
On Dec 27, 3:47 am, David Flemström wrote:
> On Saturday 26 December 2009 15:30:34 Marius wrote:> So I believe it is much
> more constructive for ALL of us to ask
> > concrete questions, described concrete problems and let's see how we
> > can fix it. Many things though may be subjective and leading to
> > endless discussions without substance.
>
> OK, then, concrete cases it is. I will try to transform the problems I
> mentioned before into concrete scenarios. Hopefully, this will shed some more
> light on what I mean.
>
> - I want a user system where each user registers with an user name and a
> password, nothing else (not First Name, Last Name, E-mail etc; there shouldn't
> be any entries for them in the DB either). For this, I would prefer to use
> pre-existing utility classes in the Lift framework so that I don't have to
> start from scratch (by extending LongKeyedMetaMapper etc), because, oh I don't
> know, I don't want to code the whole user session management and password
> exchange process by hand (even though it might not be too difficult; it's
> reinventing the wheel nonetheless). How do I proceed?
In \liftweb\lift-examples\hellolift\src\main\scala\com\hellolift\model
\User.scala ... one of the Lift examples
There is something like:
object User extends User with MetaMegaProtoUser[User] {
override def dbTableName = "users"
override def screenWrap = Full(
) // LiftNote: 6
override def signupFields = firstName :: lastName :: email ::
locale :: timezone :: password :: blogtitle :: Nil
override val skipEmailValidation = true // LiftNote: 4
override val basePath: List[String] = "user_mgt" :: "usr" :: Nil
}
Have you tried setting the signupField list to use only the override
def signupFields = firstName :: password :: Nil ?
>
> - I'd like to use ProtoUser, but need to change the labels for some of the
> fields in the registration form because I want to localize the site. Please
> remember that ProtoUser uses "S.??", which makes it impossible to add
> translations and/or change the default wordings from the outside. How do I
> proceed with the least amount of hacks (like by writing
> field.displayName.replace("First Name", S.?("...")) + overriding the correct
> functions with slightly changed versions of their original code)?
Why it makes it impossible? You can take lift-core.properties file and
put it in your WEB-INF/classes/i18n. Another approach is to tell Lift
from where it should take the core resource bundle. Thus in your boot
youcan say:
LiftRules.liftCoreResourceName = "my_bundles"
this is currently set to "i18n.lift-core"
>
> - I'd like to take a mapped object that I have, and CRUDify it (hint, hint).
> In my mapped object (e.g. an user), I have some fields that should always
> appear (e.g. basic contact information), some that should appear only to
> administrators (e.g. email addresses), and some that should be read-only to
> normal users and editable by administrators and specific users but not appear
> to unregistered users (e.g. user profile images). Columns that should be
> invisible should not be rendered in the CRUDify "list" with contents like
> "permission denied"; their rendered columns should rather not appear at all.
> How do I proceed with the least amount of hacks?
>
> - I'd like to use CRUDify again, but I need to use external templates (inside
> of HTML files) for the "list", "edit", etc... pages, since I need to change
> these templates after the application was compiled (or for some similar
> reason, like that view/model code should be separate). How do I proceed?
>
> - Same situation like the above (need to control the CRUDify templates from
> the outside), but I want to use a different HTML snippet depending on which
> field is being rendered (I don't want to use an uniform table for the view,
> but
> maybe one where some fields are stacked over another, or arranged in a
> different
> constellation). Like this:
> =
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =
> The ""s etc above are of course template-specific view code that mustn't
> be
> in the logic code.
> How do I do this with the least amount of hacks?
Unfortunately I cannot help you with CRUDify since I didn't use it but
I'm sure others will.
>
> These are of course scenarios that are fabricated but I've experienced similar
> ones that I've had problems with before; I don't know if there's some kind of
> solution to them that I've just missed (after some through looking, I gave up
> on most of them and just wrote everything form scratch by copy-pasting Lift
> source code). It all boils down to there being
Re: [Lift] Re: Lift is awesome (with reservations)
On Saturday 26 December 2009 15:30:34 Marius wrote:
> So I believe it is much more constructive for ALL of us to ask
> concrete questions, described concrete problems and let's see how we
> can fix it. Many things though may be subjective and leading to
> endless discussions without substance.
OK, then, concrete cases it is. I will try to transform the problems I
mentioned before into concrete scenarios. Hopefully, this will shed some more
light on what I mean.
- I want a user system where each user registers with an user name and a
password, nothing else (not First Name, Last Name, E-mail etc; there shouldn't
be any entries for them in the DB either). For this, I would prefer to use
pre-existing utility classes in the Lift framework so that I don't have to
start from scratch (by extending LongKeyedMetaMapper etc), because, oh I don't
know, I don't want to code the whole user session management and password
exchange process by hand (even though it might not be too difficult; it's
reinventing the wheel nonetheless). How do I proceed?
- I'd like to use ProtoUser, but need to change the labels for some of the
fields in the registration form because I want to localize the site. Please
remember that ProtoUser uses "S.??", which makes it impossible to add
translations and/or change the default wordings from the outside. How do I
proceed with the least amount of hacks (like by writing
field.displayName.replace("First Name", S.?("...")) + overriding the correct
functions with slightly changed versions of their original code)?
- I'd like to take a mapped object that I have, and CRUDify it (hint, hint).
In my mapped object (e.g. an user), I have some fields that should always
appear (e.g. basic contact information), some that should appear only to
administrators (e.g. email addresses), and some that should be read-only to
normal users and editable by administrators and specific users but not appear
to unregistered users (e.g. user profile images). Columns that should be
invisible should not be rendered in the CRUDify "list" with contents like
"permission denied"; their rendered columns should rather not appear at all.
How do I proceed with the least amount of hacks?
- I'd like to use CRUDify again, but I need to use external templates (inside
of HTML files) for the "list", "edit", etc... pages, since I need to change
these templates after the application was compiled (or for some similar
reason, like that view/model code should be separate). How do I proceed?
- Same situation like the above (need to control the CRUDify templates from
the outside), but I want to use a different HTML snippet depending on which
field is being rendered (I don't want to use an uniform table for the view, but
maybe one where some fields are stacked over another, or arranged in a
different
constellation). Like this:
=
=
The ""s etc above are of course template-specific view code that mustn't be
in the logic code.
How do I do this with the least amount of hacks?
These are of course scenarios that are fabricated but I've experienced similar
ones that I've had problems with before; I don't know if there's some kind of
solution to them that I've just missed (after some through looking, I gave up
on most of them and just wrote everything form scratch by copy-pasting Lift
source code). It all boils down to there being very specialized "starter"
classes like ProtoUser and CRUDify, that cannot be used for anything but very
small test sites in practice since they aren't extensible.
>
> Br's,
> Marius
PS. It may be that a lot of the quirks of Lift are explained in the Lift book,
and I think that that's a good start. That doesn't make them any more
intuitive, however. You can make any man (almost) into a rocket scientist by
using education, but that doesn't make rockets any easier to understand.
David Flemström
signature.asc
Description: This is a digitally signed message part.
[Lift] Re: Lift is awesome (with reservations)
Great stuff. Could you please describe "more complex scenarios" ? I mean let's start from some step-by-step use-case/workflow definitions that you're looking for and we'll try to provide different approaches, and potentially put them on the wiki for future reference. Br's, Marius On Dec 26, 6:27 pm, greekscala wrote: > Hello, > > It would be great to see some more bind examples in more > complex scenarios and how different snippets can work > together. How to build fragments and replace fragments > for ajax. I think the people that do a lot with lift have some > patterns for this. Are there any Idioms out. > > This is my problem area. > > with best regards > > On 26 Dez., 15:30, Marius wrote: > > > While I admit that there is not yet enough documentation material or > > at least probably not in a single place I disagree with some > > complaints. The Lift book for example describes in quite detail that > > request processing lifecycle, disspath functions, rendering pipeline, > > LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction > > and many others etc. Sure new things came up in the mean time and > > we're trying to document them as time permits in many cases. > > > About the Lift structure being too messy, what do you actually mean? > > AFAIK historically, people (a many newbies) asserted the contrary that > > they really liked the Lift concepts, the ease of use and understand > > how it works. For naming conventions there was a project opened and > > even discussed on this public list about renaming API's but AFAIK > > there was not a whole lot of feedback on this list so unless I'm > > wrong, the decision was to do ad-hoc renaming as we work on various > > things. This may mean deprecation of old names so there will be a > > smooth transition to "better" names. > > > So I believe it is much more constructive for ALL of us to ask > > concrete questions, described concrete problems and let's see how we > > can fix it. Many things though may be subjective and leading to > > endless discussions without substance. > > > Br's, > > Marius > > > On Dec 26, 2:51 am, Erkki Lindpere wrote: > > > > I think the best things I think you could do to help newbies is > > > document in a well-structured way: > > > > * all the conventions over configuration rules > > > * what classes to use for the basic stuff (what is S for and how it > > > should be used, all the things you can do with LiftRules, etc.) > > > * more advanced uses of bind(...) in snippets > > > * better docs for the Lift tags. > > > > On Dec 25, 9:09 pm, 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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Hello, It would be great to see some more bind examples in more complex scenarios and how different snippets can work together. How to build fragments and replace fragments for ajax. I think the people that do a lot with lift have some patterns for this. Are there any Idioms out. This is my problem area. with best regards On 26 Dez., 15:30, Marius wrote: > While I admit that there is not yet enough documentation material or > at least probably not in a single place I disagree with some > complaints. The Lift book for example describes in quite detail that > request processing lifecycle, disspath functions, rendering pipeline, > LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction > and many others etc. Sure new things came up in the mean time and > we're trying to document them as time permits in many cases. > > About the Lift structure being too messy, what do you actually mean? > AFAIK historically, people (a many newbies) asserted the contrary that > they really liked the Lift concepts, the ease of use and understand > how it works. For naming conventions there was a project opened and > even discussed on this public list about renaming API's but AFAIK > there was not a whole lot of feedback on this list so unless I'm > wrong, the decision was to do ad-hoc renaming as we work on various > things. This may mean deprecation of old names so there will be a > smooth transition to "better" names. > > So I believe it is much more constructive for ALL of us to ask > concrete questions, described concrete problems and let's see how we > can fix it. Many things though may be subjective and leading to > endless discussions without substance. > > Br's, > Marius > > On Dec 26, 2:51 am, Erkki Lindpere wrote: > > > I think the best things I think you could do to help newbies is > > document in a well-structured way: > > > * all the conventions over configuration rules > > * what classes to use for the basic stuff (what is S for and how it > > should be used, all the things you can do with LiftRules, etc.) > > * more advanced uses of bind(...) in snippets > > * better docs for the Lift tags. > > > On Dec 25, 9:09 pm, 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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
While I admit that there is not yet enough documentation material or at least probably not in a single place I disagree with some complaints. The Lift book for example describes in quite detail that request processing lifecycle, disspath functions, rendering pipeline, LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction and many others etc. Sure new things came up in the mean time and we're trying to document them as time permits in many cases. About the Lift structure being too messy, what do you actually mean? AFAIK historically, people (a many newbies) asserted the contrary that they really liked the Lift concepts, the ease of use and understand how it works. For naming conventions there was a project opened and even discussed on this public list about renaming API's but AFAIK there was not a whole lot of feedback on this list so unless I'm wrong, the decision was to do ad-hoc renaming as we work on various things. This may mean deprecation of old names so there will be a smooth transition to "better" names. So I believe it is much more constructive for ALL of us to ask concrete questions, described concrete problems and let's see how we can fix it. Many things though may be subjective and leading to endless discussions without substance. Br's, Marius On Dec 26, 2:51 am, Erkki Lindpere wrote: > I think the best things I think you could do to help newbies is > document in a well-structured way: > > * all the conventions over configuration rules > * what classes to use for the basic stuff (what is S for and how it > should be used, all the things you can do with LiftRules, etc.) > * more advanced uses of bind(...) in snippets > * better docs for the Lift tags. > > On Dec 25, 9:09 pm, 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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
I think the best things I think you could do to help newbies is document in a well-structured way: * all the conventions over configuration rules * what classes to use for the basic stuff (what is S for and how it should be used, all the things you can do with LiftRules, etc.) * more advanced uses of bind(...) in snippets * better docs for the Lift tags. On Dec 25, 9:09 pm, 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. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Well, I'm not sure if I completely get it yet or if I can summarize well enough, but: I should look at Lift through more functional programming goggles, some things in it don't make a lot of sense when looked through OO goggles. >From looking through some of the docs, examples and sources, I have a basic understanding now about how the requests are served: what rules can be defined in LiftRules during the Boot process and by what conventions templates, snippets and other stuff are looked up. I don't know how to summarize it though. Erkki L On Dec 25, 4:51 pm, greekscala wrote: > Hello, > > I would like to hear more about, how you "get" lift. I am new to lift > too and trying to get a better and clearer viewpoint. > > Maybe it can help others to. If you can summarize it in a few > sentences. > This would be really great. > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift is awesome (with reservations)
A propos: On Sat, Dec 26, 2009 at 1:19 AM, Erkki Lindpere wrote: > * 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. Please see: http://www.codecommit.com/scala-style-guide.pdf ...which is the product of a recent discussion on scala-u...@epfl I believe. David Flemström david.flemst...@gmail.com -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
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 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 > 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 > > " > 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, > > so
[Lift] Re: Lift is awesome (with reservations)
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 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 > " 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 powerfu
Re: [Lift] Re: Lift is awesome (with reservations)
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 "http://github.com/alandipert/step > > Cheers, Tim > David Flemström david.flemst...@gmail.com signature.asc Description: This is a digitally signed message part.
[Lift] Re: Lift is awesome (with reservations)
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. Cheers, Tim On Dec 25, 2:51 pm, greekscala wrote: > Hello, > > I would like to hear more about, how you "get" lift. I am new to lift > too and trying to get a better and clearer viewpoint. > > Maybe it can help others to. If you can summarize it in a few > sentences. > This would be really great. > > with best regards > > On 25 Dez., 01:05, Erkki Lindpere wrote: > > > > > It took me a long time to "get" lift. For about a year I looked at > > examples from time to time and tried out some basic stuff, but it just > > didn't click. I found the structure to be too messy. I still do > > actually. It seems that the documentation is also not well structured > > enough for getting started and I had to look at examples and Lift's > > source to understand how things work (thanks for putting sources in > > the Maven repo BTW, I wish everyone would do that). > > > After experimenting with Lift for about two days I think I get the > > basic idea and I've come to a better understanding about lift's > > structure by looking at the sources, I can now ignore the parts I > > don't like (Mapper being one, I use JPA instead) and use the parts > > that I do. > > > The way the X(HT)ML processing, type-safe JavaScript/jQuery, Ajax and > > Comet work is just brilliant! > > > PS. I'm working (on my spare time for now) on an Ajax & Comet heavy > > application that will hopefully also have a lot of runtime > > customization ability through OSGi. I haven't gotten to the OSGi part > > yet, because there's the hurdle of OSGifying all the jars I use and I > > want to get a good understanding of Lift before I start making things > > dynamic. But do you have any recommendations for OSGi framework/web > > container combinations to use with Lift? I have tried SpringSource > > dmServer (with the SpringSource tooling), but I don't like it much... > > Maybe plain Equinox + Jetty with the ScalaModules library would be a > > good combo? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Hello, I would like to hear more about, how you "get" lift. I am new to lift too and trying to get a better and clearer viewpoint. Maybe it can help others to. If you can summarize it in a few sentences. This would be really great. with best regards On 25 Dez., 01:05, Erkki Lindpere wrote: > It took me a long time to "get" lift. For about a year I looked at > examples from time to time and tried out some basic stuff, but it just > didn't click. I found the structure to be too messy. I still do > actually. It seems that the documentation is also not well structured > enough for getting started and I had to look at examples and Lift's > source to understand how things work (thanks for putting sources in > the Maven repo BTW, I wish everyone would do that). > > After experimenting with Lift for about two days I think I get the > basic idea and I've come to a better understanding about lift's > structure by looking at the sources, I can now ignore the parts I > don't like (Mapper being one, I use JPA instead) and use the parts > that I do. > > The way the X(HT)ML processing, type-safe JavaScript/jQuery, Ajax and > Comet work is just brilliant! > > PS. I'm working (on my spare time for now) on an Ajax & Comet heavy > application that will hopefully also have a lot of runtime > customization ability through OSGi. I haven't gotten to the OSGi part > yet, because there's the hurdle of OSGifying all the jars I use and I > want to get a good understanding of Lift before I start making things > dynamic. But do you have any recommendations for OSGi framework/web > container combinations to use with Lift? I have tried SpringSource > dmServer (with the SpringSource tooling), but I don't like it much... > Maybe plain Equinox + Jetty with the ScalaModules library would be a > good combo? -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
