[Lift] Re: Websites and apps that are using Lift?
You can add my Lift app - http://nofouls.com On Dec 17, 11:05 pm, Daniel Cer daniel@gmail.com wrote: Does anyone here have any public Lift powered webapps? If so, would you mind sharing the URL and what other support components you are using (e.g. which servlet container Tomcat, Jetty; database; etc.) I just wanted to add that small personal projects are fine. Also, it would be great to hear about anything people are in the process of building. -Dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] LiftRules.logAndReturnExceptionToBrowser doesnt alway work
I was redirecting to an error page using LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper to close a EntityManager and an error occurs when closing the entity manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to redirect to my error page. Can anyone think of a work around? // Output a simple error to the user. Link the error message to the screen via the current datetime LiftRules.logAndReturnExceptionToBrowser = { RedirectResponse(/error); } // Set up a LoanWrapper to automatically close a EntityManager if its open S.addAround(List( new LoanWrapper { def apply[T] (f : = T): T = { try { f } finally { EM.closeEM // close if open } } })) } --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
A bit better, thanks - that fixed the *Dispatch calls. Now it's just the following lines causing a problem: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.prependRewrite { case RewriteRequest(ParsePath(user :: user :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, index), Map(uid - user)) case RewriteRequest(ParsePath(tag :: tag :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, tag), Map(tag - tag)) case RewriteRequest(ParsePath(conversation :: cid :: Nil, , _, _), _, _) = RewriteResponse(List(user_view, conversation), Map(cid - cid)) case RewriteRequest(ParsePath(search :: term :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, search), Map(term - term)) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) Cheers, Darren On Dec 18, 9:52 pm, TylerWeir tyler.w...@gmail.com wrote: Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Darren, Any LiftRules.append* or LiftRules.prepend* becomes LiftRules.*.append or LiftRules.*.prepend e.g.: LiftRules.prependTemplate(User.templates) - LiftRules.template.prepend(User.templates) On Thu, Dec 18, 2008 at 2:39 PM, Darren Hague dha...@fortybeans.com wrote: A bit better, thanks - that fixed the *Dispatch calls. Now it's just the following lines causing a problem: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.prependRewrite { case RewriteRequest(ParsePath(user :: user :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, index), Map(uid - user)) case RewriteRequest(ParsePath(tag :: tag :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, tag), Map(tag - tag)) case RewriteRequest(ParsePath(conversation :: cid :: Nil, , _, _), _, _) = RewriteResponse(List(user_view, conversation), Map(cid - cid)) case RewriteRequest(ParsePath(search :: term :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, search), Map(term - term)) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) Cheers, Darren On Dec 18, 9:52 pm, TylerWeir tyler.w...@gmail.com wrote: Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Caught the rewrite one too, leaving: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) appendView - viewDispatch.append almost worked, except that the case line failed to compile. - Darren On Dec 18, 10:39 pm, Darren Hague dha...@fortybeans.com wrote: A bit better, thanks - that fixed the *Dispatch calls. Now it's just the following lines causing a problem: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.prependRewrite { case RewriteRequest(ParsePath(user :: user :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, index), Map(uid - user)) case RewriteRequest(ParsePath(tag :: tag :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, tag), Map(tag - tag)) case RewriteRequest(ParsePath(conversation :: cid :: Nil, , _, _), _, _) = RewriteResponse(List(user_view, conversation), Map(cid - cid)) case RewriteRequest(ParsePath(search :: term :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, search), Map(term - term)) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) Cheers, Darren On Dec 18, 9:52 pm, TylerWeir tyler.w...@gmail.com wrote: Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Github pages
http://github.com/blog/272-github-pages --j --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
David, error: value template is not a member of object net.liftweb.http.LiftRules I removed net/liftweb from my Maven repo about an hour ago, so I'm pretty sure I'm up to date with the latest build. Cheers, Darren On Dec 18, 10:42 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Darren, Any LiftRules.append* or LiftRules.prepend* becomes LiftRules.*.append or LiftRules.*.prepend e.g.: LiftRules.prependTemplate(User.templates) - LiftRules.template.prepend(User.templates) On Thu, Dec 18, 2008 at 2:39 PM, Darren Hague dha...@fortybeans.com wrote: A bit better, thanks - that fixed the *Dispatch calls. Now it's just the following lines causing a problem: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.prependRewrite { case RewriteRequest(ParsePath(user :: user :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, index), Map(uid - user)) case RewriteRequest(ParsePath(tag :: tag :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, tag), Map(tag - tag)) case RewriteRequest(ParsePath(conversation :: cid :: Nil, , _, _), _, _) = RewriteResponse(List(user_view, conversation), Map(cid - cid)) case RewriteRequest(ParsePath(search :: term :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, search), Map(term - term)) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) Cheers, Darren On Dec 18, 9:52 pm, TylerWeir tyler.w...@gmail.com wrote: Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius -- Lift, the simply functional web frameworkhttp://liftweb.net Collaborative Task Managementhttp://much4.us Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: Github pages
Very interesting On Thu, Dec 18, 2008 at 4:45 PM, Jorge Ortiz jorge.or...@gmail.com wrote: http://github.com/blog/272-github-pages --j --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
Apache ESME source is now fixed building cleanly again - thanks to David for this. Cheers, Darren On Dec 18, 10:48 pm, Darren Hague dha...@fortybeans.com wrote: David, error: value template is not a member of object net.liftweb.http.LiftRules I removed net/liftweb from my Maven repo about an hour ago, so I'm pretty sure I'm up to date with the latest build. Cheers, Darren On Dec 18, 10:42 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Darren, Any LiftRules.append* or LiftRules.prepend* becomes LiftRules.*.append or LiftRules.*.prepend e.g.: LiftRules.prependTemplate(User.templates) - LiftRules.template.prepend(User.templates) On Thu, Dec 18, 2008 at 2:39 PM, Darren Hague dha...@fortybeans.com wrote: A bit better, thanks - that fixed the *Dispatch calls. Now it's just the following lines causing a problem: LiftRules.prependTemplate(User.templates) LiftRules.appendStatelessDispatch { case r @ Req(api :: send_msg :: Nil, , PostRequest) if r.param(token).isDefined = () = RestAPI.sendMsgWithToken(r) } LiftRules.prependRewrite { case RewriteRequest(ParsePath(user :: user :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, index), Map(uid - user)) case RewriteRequest(ParsePath(tag :: tag :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, tag), Map(tag - tag)) case RewriteRequest(ParsePath(conversation :: cid :: Nil, , _, _), _, _) = RewriteResponse(List(user_view, conversation), Map(cid - cid)) case RewriteRequest(ParsePath(search :: term :: Nil,, _,_), _, _) = RewriteResponse( List(user_view, search), Map(term - term)) } LiftRules.appendViewDispatch { case user_view :: _ = UserView } LiftRules.appendEarly(makeUtf8) Cheers, Darren On Dec 18, 9:52 pm, TylerWeir tyler.w...@gmail.com wrote: Hey Darren, Something like this: // Old and busted LiftRules.prependDispatch(RestAPI.dispatch) // New hotness LiftRules.dispatch.prepend(RestAPI.dispatch) Lather, rinse and repeat for dispatch, rewrite, etc Better, or worse? Ty On Dec 18, 4:47 pm, Darren Hague dha...@fortybeans.com wrote: Dano (or David), Care to share what your changes were? I'm facing the same problem right now with ESME - lots of LiftRules.append* and LiftRules.prepend* in Boot.scala which will not compile any more - even Googling LiftRules RulesSeq returns no results at all... :-( Cheers, Darren On Dec 15, 7:08 pm, Dano dan_ole...@yahoo.com wrote: Marius, David was able to help me out. In the future, I will have to dig myself out of the situation. For those Lift developers that are not 'committers' it is harder to know how to proceed. Perhaps in the future, the breaking changes should include a little more detail on which signatures have been changed and how they can be transformed. In any case, I am happy there is this group to ask for help! Thanks. Dan On Dec 15, 12:08 am, Marius marius.dan...@gmail.com wrote: Sorry Dan ... There were too many changes in LiftRules. You should be able to determine real quick what changed in LiftRules since the variables naming is more or less the same. If you can not fix your code can you please copy-paste it here ? ... in this way I may be able to help. Br's, Marius On Dec 15, 1:55 am, Dano dan_ole...@yahoo.com wrote: Marius, Is there someway you can communicate what the 'from' and 'to' changes are so that I can have a chance at being able to fix my now broken code? Dan On Dec 13, 12:31 pm, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes inLiftRules. In a previous thread Jorge suggested the abstraction ofLiftRulesvariables. Lists of functions are now abstracted by RulesSeq trait, which contains prepend and append functions. Note that if you're calling prepend/append functions after boot they will throw an exception. If there are compelling reasons not to do this please let us know. This is just a mechanism to enforce the use of these functions on startup. Br's, Marius -- Lift, the simply functional web frameworkhttp://liftweb.net Collaborative Task Managementhttp://much4.us Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to
[Lift] Re: LiftRules.logAndReturnExceptionToBrowser doesnt alway work
I'd put a try/finally around the EM.closeEM call so that it does not impact the stuff that's being rendered to the browser. Don't let the exception in the finally block propogate. On Thu, Dec 18, 2008 at 1:58 PM, Oliver ola...@gmail.com wrote: I was redirecting to an error page using LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper to close a EntityManager and an error occurs when closing the entity manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to redirect to my error page. Can anyone think of a work around? // Output a simple error to the user. Link the error message to the screen via the current datetime LiftRules.logAndReturnExceptionToBrowser = { RedirectResponse(/error); } // Set up a LoanWrapper to automatically close a EntityManager if its open S.addAround(List( new LoanWrapper { def apply[T] (f : = T): T = { try { f } finally { EM.closeEM // close if open } } })) } -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: Websites and apps that are using Lift?
Matt, Do you mind if I list your name next to nofouls.com? It would just be your name, Matt Hopkins, and not your e-mail address or anything like that. -Dan On Thu, Dec 18, 2008 at 6:53 AM, Matt Hopkins jomyfriendatw...@gmail.comwrote: You can add my Lift app - http://nofouls.com On Dec 17, 11:05 pm, Daniel Cer daniel@gmail.com wrote: Does anyone here have any public Lift powered webapps? If so, would you mind sharing the URL and what other support components you are using (e.g. which servlet container Tomcat, Jetty; database; etc.) I just wanted to add that small personal projects are fine. Also, it would be great to hear about anything people are in the process of building. -Dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: LiftRules.logAndReturnExceptionToBrowser doesnt alway work
I started on that path, and thought I could redirect with something like Full(span some html that redirects to the error page... /span).asInstanceOf[T] It feels like a big hack, even if I could get it working and I was a little worried about creating a redirection loop. I've created a static html error page and call it from web.xml for now - it'll have to do for now. On Fri, Dec 19, 2008 at 11:09 AM, David Pollak feeder.of.the.be...@gmail.com wrote: I'd put a try/finally around the EM.closeEM call so that it does not impact the stuff that's being rendered to the browser. Don't let the exception in the finally block propogate. On Thu, Dec 18, 2008 at 1:58 PM, Oliver ola...@gmail.com wrote: I was redirecting to an error page using LiftRules.logAndReturnExceptionToBrowser, but when I use a LoanWrapper to close a EntityManager and an error occurs when closing the entity manager, LiftRules.logAndReturnExceptionToBrowser doesn't appear to redirect to my error page. Can anyone think of a work around? // Output a simple error to the user. Link the error message to the screen via the current datetime LiftRules.logAndReturnExceptionToBrowser = { RedirectResponse(/error); } // Set up a LoanWrapper to automatically close a EntityManager if its open S.addAround(List( new LoanWrapper { def apply[T] (f : = T): T = { try { f } finally { EM.closeEM // close if open } } })) } -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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 -~--~~~~--~~--~--~---