[Lift] Re: **IMPORTANT** Lift ticketing system has moved to Assembla
I noticed that Assembla sends a lot of spam (seems I get an e-mail for everything anyone does in there, including new users registering) These alerts can be turned off under Stream - Change alert settings if anyone has trouble finding it. -- 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: HTTP Reason Phrase
Actually, the reason phrase is not a normal HTTP header, but part of the status line: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Examples: HTTP/1.1 200 OK HTTP/1.1 404 The user with id 8 does not exist The only way of setting this in Java Servlets as far as I know is through HttpServletResponse.setStatus(int, String), which unfortunately is deprecated. A non-deprecated possibility is sendError(int, String), but that goes to the container's default error page (or the one defined in web.xml, I think) so it's not exactly what I would like. Also, I checked that FireBug actually does display the custom reason phrase, but Chrome displays the standard one instead. Erkki L On Feb 7, 1:08 pm, Timothy Perrett timo...@getintheloop.eu wrote: If you want to alter the Reason-Phrase, you can already do that - objects like NotFoundResponse are just helpers on InMemoryResponse... nothing stopping you adding your own helpers that set headers with customised reason codes; this should give you what you what. I haven't managed to find an RFC that lists reason-phrase as anything but a particular header in the HTTP response. Moreover, its not the wrong thing to return a plain text response if the request mime was text/plain... indeed, it would be even less helpful if it returned JSON or such. IMHO, the response type should match what was asked for by the caller - i.e. its an implementation issue not a framework level issue. Tim On 6 Feb 2010, at 21:55, Erkki Lindpere wrote: The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want to give additional machine-readable detail, I'd put it in a response header or in the body as a JSON or XML field or what have you. You can specify custom text there, but you may have to sidestep the usual response classes, depending on which one. The one you gave, not found, can have the message customized though, just do new NotFoundResponse(the message). -Ross On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote: It seems Lift does not support custom HTTP Reason Phrases in responses. I would like to send error messages in the Reason Phrase (along with a vaguely applicable HTTP status code) in a RESTful API I'm providing. My understanding of the HTTP spec is that the reason phrase is meant to be human readable and does not have to contain the recommended messages (i.e. Not Found). But maybe it would not be wise to do this? I'm not actually aware of any API-s that send error messages in the Reason Phrase. -- 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 athttp://groups.google.com/group/liftweb?hl=en
[Lift] Re: HTTP Reason Phrase
Ok. The feature is not really that important for me, just something that would be nice to have. I think some hack could be made with sendError(int, String) and web.xml config, but that would be worse than using the deprecated method. Erkki L On Feb 7, 11:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: I agree Ross... I would be very reluctant to have Lift rely on some deprecated method in the servlet spec - even if it is in servlet 3.0. Cheers, Tim On 7 Feb 2010, at 20:48, Ross Mellgren wrote: Yeah you're very correct. It's unfortunate, but I think since it's deprecated in the container we should probably not add support for it. I can't believe they deprecated it for the reason they did, but there it is. -Ross On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote: Actually, the reason phrase is not a normal HTTP header, but part of the status line: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Examples: HTTP/1.1 200 OK HTTP/1.1 404 The user with id 8 does not exist The only way of setting this in Java Servlets as far as I know is through HttpServletResponse.setStatus(int, String), which unfortunately is deprecated. A non-deprecated possibility is sendError(int, String), but that goes to the container's default error page (or the one defined in web.xml, I think) so it's not exactly what I would like. Also, I checked that FireBug actually does display the custom reason phrase, but Chrome displays the standard one instead. Erkki L On Feb 7, 1:08 pm, Timothy Perrett timo...@getintheloop.eu wrote: If you want to alter the Reason-Phrase, you can already do that - objects like NotFoundResponse are just helpers on InMemoryResponse... nothing stopping you adding your own helpers that set headers with customised reason codes; this should give you what you what. I haven't managed to find an RFC that lists reason-phrase as anything but a particular header in the HTTP response. Moreover, its not the wrong thing to return a plain text response if the request mime was text/plain... indeed, it would be even less helpful if it returned JSON or such. IMHO, the response type should match what was asked for by the caller - i.e. its an implementation issue not a framework level issue. Tim On 6 Feb 2010, at 21:55, Erkki Lindpere wrote: The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want to give additional machine-readable detail, I'd put it in a response header or in the body as a JSON or XML field or what have you. You can specify custom text there, but you may have to sidestep the usual response classes, depending on which one. The one you gave, not found, can have the message customized though, just do new NotFoundResponse(the message). -Ross On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote: It seems Lift does not support custom HTTP Reason Phrases in responses. I would like to send error messages in the Reason Phrase (along with a vaguely applicable HTTP status code) in a RESTful API I'm providing. My understanding of the HTTP spec is that the reason phrase is meant to be human readable and does not have to contain
[Lift] Re: Lift-OpenID should default to openid_identifier for post param name
Ok, I'll do that. BTW. As I'm doing a bit of research how providers support Attribute- Exchange, it seems their behaviour and supported schemas can be quite different (for example, Google ignores optional attributes). So the function might need a parameter from which the openid provider can be determined, to allow customizations for well-known providers. Erkki L On Feb 6, 9:54 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Erkki Lindpere vill...@gmail.com writes: Thanks! I'm now trying to customize the attribute-exchange and noticed that it is embedded in a longish method. I think it would be good if this was extracted to a method (maybe: def reqAttributeExchange: Option[FetchRequest] ?) so that ax info could be modified without digging into the rest of the logic or copy'n'pasting. Specifically, I think these lines could be extracted: // Attribute Exchange example: fetching the 'email' attribute val fetch = FetchRequest.createFetchRequest() fetch.addAttribute(email, // attribute alias http://schema.openid.net/contact/email;, // type URI true); // required I maybe about to look at the openid stuff for a project and will need this functionality as well :-) If you could open a ticket on Assembla (when it's availability has been announced) I'll have a look... /Jeppe -- 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] HTTP Reason Phrase
It seems Lift does not support custom HTTP Reason Phrases in responses. I would like to send error messages in the Reason Phrase (along with a vaguely applicable HTTP status code) in a RESTful API I'm providing. My understanding of the HTTP spec is that the reason phrase is meant to be human readable and does not have to contain the recommended messages (i.e. Not Found). But maybe it would not be wise to do this? I'm not actually aware of any API-s that send error messages in the Reason Phrase. -- 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: HTTP Reason Phrase
The NotFoundResponse (and others) puts the custom message into the request body. That works as well, but to be really lean (mainly for bragging rights :)) I'd like to remove any unnecessary elements from the rest api. Most of the error messages are going to be simple one- line messages (and short sentences). For some errors I might provide a detailed response and it could go into the body, as XML/JSON/... That's inconsistent if the other errors have a plain text message in the body. So I could either go with structured details for all messages or in simple cases use the HTTP headers or status line. A custom header would work, but the status line is standard and also more easily accessed with some client libraries. And last but perhaps not least, for debugging purposes, the HTTP Reason Code should show up better in web developer tools (for example FireBug, Chrome's tools). My web UI also goes through the REST API so it would be nice to read error messages right in the listing in firebug's net panel. So I'm suggesting that perhaps Lift would like to provide only the possibility of changing that value in user code. But I completely understand if it doesn't. Currently it doesn't seem to be supported in Lift's http.provider package and even in javax.servlet the setStatus(int, String) method is deprecated (I'm not sure if sendError(int, String) uses the reason phrase). Erkki L On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote: I think it would be fine to have different text there, probably better than having the standard text if you have refined detail. I don't think it'd be a good idea to conditionalize on the response text in client code - that's always fragile. If you want to give additional machine-readable detail, I'd put it in a response header or in the body as a JSON or XML field or what have you. You can specify custom text there, but you may have to sidestep the usual response classes, depending on which one. The one you gave, not found, can have the message customized though, just do new NotFoundResponse(the message). -Ross On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote: It seems Lift does not support custom HTTP Reason Phrases in responses. I would like to send error messages in the Reason Phrase (along with a vaguely applicable HTTP status code) in a RESTful API I'm providing. My understanding of the HTTP spec is that the reason phrase is meant to be human readable and does not have to contain the recommended messages (i.e. Not Found). But maybe it would not be wise to do this? I'm not actually aware of any API-s that send error messages in the Reason Phrase. -- 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.
[Lift] Re: Lift-OpenID should default to openid_identifier for post param name
Thanks! I'm now trying to customize the attribute-exchange and noticed that it is embedded in a longish method. I think it would be good if this was extracted to a method (maybe: def reqAttributeExchange: Option[FetchRequest] ?) so that ax info could be modified without digging into the rest of the logic or copy'n'pasting. Specifically, I think these lines could be extracted: // Attribute Exchange example: fetching the 'email' attribute val fetch = FetchRequest.createFetchRequest() fetch.addAttribute(email, // attribute alias http://schema.openid.net/contact/email;, // type URI true); // required Erkki L On Feb 2, 1:33 am, David Pollak feeder.of.the.be...@gmail.com wrote: I've changed the code from a val to a def and changed the default value to openid_identifier. If this causes code breakage, folks can change it back to the old value. Thanks for the suggestion. On Sat, Jan 30, 2010 at 7:58 AM, Erkki Lindpere vill...@gmail.com wrote: Hi, I suggest that Lift-OpenID should have openid_identifier as the default post param name instead of openIdUrl. openid_identifier is the one recommended in the OpenID spec. with the idea that user agents may someday special support for that. I think this change would be justified considering Lift's philosophy of providing sensible defaults? (not that it's hard to change, but it took me a while to figure out why /openid/login resulted in not found -- I used a custom form with the standard field names not the one generated by Lift) Erkki -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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] Lift-OpenID should default to openid_identifier for post param name
Hi, I suggest that Lift-OpenID should have openid_identifier as the default post param name instead of openIdUrl. openid_identifier is the one recommended in the OpenID spec. with the idea that user agents may someday special support for that. I think this change would be justified considering Lift's philosophy of providing sensible defaults? (not that it's hard to change, but it took me a while to figure out why /openid/login resulted in not found -- I used a custom form with the standard field names not the one generated by Lift) Erkki -- 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] Lift-base 280_port seems to work
Just reporting my experience for anyone who wants to live on the bleeding edge... for a limited use case (I only use lift-webkit, and probably only a small subset of that), the 280_port seems to be working well enough with a recent Scala 2.8 snapshot (once I applied the fix to a Scala class that was linked to here: http://groups.google.com/group/liftweb/browse_thread/thread/e057a269f8f6a9ca# ) -- 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 naftoli...@gmail.com 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)
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 vill...@gmail.com 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 naftoli...@gmail.com 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)
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 naftoli...@gmail.com 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 Lindperevill...@gmail.com 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 vill...@gmail.com 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 naftoli...@gmail.com 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.
[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 dri...@gmail.com 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 naftoli...@gmail.com 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 Lindperevill...@gmail.com 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 vill...@gmail.com 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 naftoli...@gmail.com 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
[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 david.flemst...@gmail.com wrote: On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples. However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with lift: tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to expect it to be next without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like User with LastName with EmailField with Password... that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la cached_? and sometimes isCached, sometimes methods use Box[]es for no apparent reason, sometimes you use objects and sometimes vals 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
[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 vill...@gmail.com 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 david.flemst...@gmail.com wrote: On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples. However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with lift: tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to expect it to be next without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like User with LastName with EmailField with Password... that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la cached_? and sometimes isCached, sometimes methods use Box[]es for no apparent reason, sometimes you use objects and sometimes vals
[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 hellectro...@gmail.com 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.
[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 timo...@getintheloop.eu 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] Lift is awesome (with reservations)
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] Reserved words in templates/snippets?
I couldn't figure out why my snippet was not being called, then renamed my class (it was named Msg) and it started working. Is Lift possibly resolving lift:msg.blabla to another class called Msg? -- 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] Foreach-like snippet: am I doing it right?
This has probably come up previously, but I couldn't find anything
even though I think a couple of days ago I read about something
similar:
I want to do a snippet that behaves similarly to JSTL-s forEach tag.
Not exactly the same, but the idea is that it gets some list of model
objects, then goes through it element by element and processes the
input NodeSeq for each element. What I came up with is this:
def foreach(in: NodeSeq) = {
val msgs = somehowGetAListOfModelObjects();
msgs.flatMap { msg =
// set the current object (CurrentMessage is a ThreadLocal)
CurrentMessage.set(msg)
// process the contents, with the current object in scope
S.session.get.processSurroundAndInclude(, in)
}
}
And it's called like this:
lift:blabla.foreach
lift:embed what=message.html /
/lift:blabla.foreach
Is there a more correct solution to this?
--
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: Foreach-like snippet: am I doing it right?
Well, I'd prefer to keep different concerns separated. Iterating over
that list is not the only case where I render those objects, that's
why I want the rendering of these objects to be separated into their
own template.
But maybe I'll change my mind. Doing it like you suggested is probably
faster too.
Erkki L
On Dec 23, 8:31 pm, Ross Mellgren dri...@gmail.com wrote:
S.session.get.processSurroundAndInclude has a couple issues, first is
that it seems to be a much larger stick than you need, and the other
reason is that you are using get (which is for Option, I presume you
mean open_!, since S.session is a box) which is not safe -- it will
throw NPE in the case where a session is not available.
I think the more idiomatic way is probably more like
def forEachMsg(in: NodeSeq): NodeSeq = {
val msgs = somehowGetAListOfModelObjects()
msgs.flatMap { msg =
bind(msg, in, field1 - msg.field1, field2 -
msg.field2);
}
}
And then inline at the call side:
lift:blabla.forEachMsg
msg:field1 /
msg:field2 /
/lift:blabla.forEachMsg
Is there something peculiar about your use case where you really want
to do lift:embed and so on?
-Ross
On Dec 23, 2009, at 1:26 PM, Erkki Lindpere wrote:
This has probably come up previously, but I couldn't find anything
even though I think a couple of days ago I read about something
similar:
I want to do a snippet that behaves similarly to JSTL-s forEach tag.
Not exactly the same, but the idea is that it gets some list of model
objects, then goes through it element by element and processes the
input NodeSeq for each element. What I came up with is this:
def foreach(in: NodeSeq) = {
val msgs = somehowGetAListOfModelObjects();
msgs.flatMap { msg =
// set the current object (CurrentMessage is a ThreadLocal)
CurrentMessage.set(msg)
// process the contents, with the current object in scope
S.session.get.processSurroundAndInclude(, in)
}
}
And it's called like this:
lift:blabla.foreach
lift:embed what=message.html /
/lift:blabla.foreach
Is there a more correct solution to this?
--
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.
[Lift] Re: Foreach-like snippet: am I doing it right?
Thanks! I'll try that.
On Dec 23, 8:59 pm, Ross Mellgren dri...@gmail.com wrote:
Well, if that's the case then you could do it something like this:
object MySnippet {
/** Function that binds fields of a single ModelObj */
def bindModelObj(ns: NodeSeq)(model: ModelObj) =
bind(model, ns, field1 - model.field1, field2 -
model.field2)
}
class MySnippet extends DispatchSnippet {
import MySnippet.bindModelObj
val dispatch: DispatchIt = {
case forEach = forEach
case justOne = justOne
}
def forEach(ns: NodeSeq): NodeSeq =
somehowGetAListOfModelObjects().flatMap(bindModelObj(ns) _)
def justOne(ns: NodeSeq): NodeSeq =
bindModelObj(ns)(somehowGetJustOneModelObject())
}
And then in your snippet you can also have reuse (I don't know how
efficient this is):
lift:MySnippet.forEach
model:field1 /
model:field2 /
/lift:MySnippet.forEach
lift:MySnippet.justOne
model:field1 /
model:field2 /
/lift:MySnippet.justOne
If you have the same rendering for each object, you could use
eager_eval and embed:
lift:MySnippet.forEach eager_eval=true
lift:embed what=modelobject /
/lift:MySnippet.forEach
lift:MySnippet.justOne eager_eval=true
lift:embed what=modelobject /
/lift:MySnippet.justOne
-Ross
On Dec 23, 2009, at 1:51 PM, Erkki Lindpere wrote:
Well, I'd prefer to keep different concerns separated. Iterating over
that list is not the only case where I render those objects, that's
why I want the rendering of these objects to be separated into their
own template.
But maybe I'll change my mind. Doing it like you suggested is probably
faster too.
Erkki L
On Dec 23, 8:31 pm, Ross Mellgren dri...@gmail.com wrote:
S.session.get.processSurroundAndInclude has a couple issues, first is
that it seems to be a much larger stick than you need, and the other
reason is that you are using get (which is for Option, I presume
you
mean open_!, since S.session is a box) which is not safe -- it will
throw NPE in the case where a session is not available.
I think the more idiomatic way is probably more like
def forEachMsg(in: NodeSeq): NodeSeq = {
val msgs = somehowGetAListOfModelObjects()
msgs.flatMap { msg =
bind(msg, in, field1 - msg.field1, field2 -
msg.field2);
}
}
And then inline at the call side:
lift:blabla.forEachMsg
msg:field1 /
msg:field2 /
/lift:blabla.forEachMsg
Is there something peculiar about your use case where you really want
to do lift:embed and so on?
-Ross
On Dec 23, 2009, at 1:26 PM, Erkki Lindpere wrote:
This has probably come up previously, but I couldn't find anything
even though I think a couple of days ago I read about something
similar:
I want to do a snippet that behaves similarly to JSTL-s forEach tag.
Not exactly the same, but the idea is that it gets some list of
model
objects, then goes through it element by element and processes the
input NodeSeq for each element. What I came up with is this:
def foreach(in: NodeSeq) = {
val msgs = somehowGetAListOfModelObjects();
msgs.flatMap { msg =
// set the current object (CurrentMessage is a ThreadLocal)
CurrentMessage.set(msg)
// process the contents, with the current object in scope
S.session.get.processSurroundAndInclude(, in)
}
}
And it's called like this:
lift:blabla.foreach
lift:embed what=message.html /
/lift:blabla.foreach
Is there a more correct solution to this?
--
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
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.
