[Lift] Re: Where to start
You may also wish to have a look at ESME, an Apache Incubator project which expands on Skittr in a number of ways. There is OpenID sign-on, search (via Lucene/Compass), a DSL for filtering routing messages, an HTTP-based API, and much more. Check out http://blog.esme.us and http://incubator.apache.org/esme for more details. Source code links are here: http://incubator.apache.org/esme/community/contribute.html Cheers, Darren On Apr 8, 6:10 am, David Bernard david.bernard...@gmail.com wrote: samples and demo code are available in the lift source under sites (bad name) directoryhttp://github.com/dpp/liftweb/tree/c096b784c3fb43900ea0b2b10ad71df34f... /davidB On Tue, Apr 7, 2009 at 22:29, Erkki Lindpere vill...@gmail.com wrote: I really want to try Lift out, but I find the documentation a bit lacking (and on the other hand the getting started guide is too verbose IMHO). My preferred method is to take a look at the source of an example application that is more complex than hello world (even better if more complex than the hellolift archetype as well) and then I'll read some docs on the side. Is there such an example app? skittr-example? Regards, Erkki Lindpere --~--~-~--~~~---~--~~ 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: Proposed URL Shortening widget
ESME is an open-source Enterprise-focussed microblogging system written in Scala on Lift. Please see http://blog.esme.us/ for more details, and http://incubator.apache.org/esme to get to the source code etc. Cheers, Darren (ESME Tech Lead) On Apr 5, 2:36 am, Chad Skinner chadwskin...@gmail.com wrote: We do it in ESME. It's 1 class (the model) and 1 object. What is ESME? --~--~-~--~~~---~--~~ 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: [ANN] Lift 1.0 is released
Stability at last! :-) Seriously, well done to all the committers and all the great people on this group that help newbies like me build awesome Lift-based apps. Major thanks to David, without whom ESME would be merely a poor clone of Skittr with some SAP stuff on top. Cheers! Darren --~--~-~--~~~---~--~~ 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
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
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] 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: *** 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
liftweb+unsubscr
