[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread Darren Hague
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,

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread TylerWeir
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:

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread Darren Hague
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 =

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread David Pollak
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

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread Darren Hague
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) }

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread Darren Hague
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,

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-18 Thread Darren Hague
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

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-15 Thread Marius
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

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-15 Thread Viktor Klang
On Sun, Dec 14, 2008 at 10:46 PM, Marius marius.dan...@gmail.com wrote: So LiftConfig would take the role of LiftRules from API perspective meaning that LiftRules could be completely hidden from Lift users but available internally to Lift only ? Since LiftRules would then only expose

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-15 Thread Dano
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

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Marius
On Dec 14, 3:02 am, Jorge Ortiz jorge.or...@gmail.com wrote: Not to beat a dead horse, but... what's the rationale, again, for throwing an exception after boot? Is there a real danger to some or all RulesSeqs being mutable after boot? If some, then those rules should selectively be

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Marius
On Dec 14, 12:10 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun, Dec 14, 2008 at 9:28 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 3:02 am, Jorge Ortiz jorge.or...@gmail.com wrote: Not to beat a dead horse, but... what's the rationale, again, for throwing an exception

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Viktor Klang
On Sun, Dec 14, 2008 at 11:42 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 12:10 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun, Dec 14, 2008 at 9:28 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 3:02 am, Jorge Ortiz jorge.or...@gmail.com wrote: Not to beat a

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Viktor Klang
On Sun, Dec 14, 2008 at 12:54 PM, Marius marius.dan...@gmail.com wrote: On Dec 14, 12:53 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun, Dec 14, 2008 at 11:42 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 12:10 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun,

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Marius
On Dec 14, 12:53 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun, Dec 14, 2008 at 11:42 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 12:10 pm, Viktor Klang viktor.kl...@gmail.com wrote: On Sun, Dec 14, 2008 at 9:28 AM, Marius marius.dan...@gmail.com wrote: On Dec 14,

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Viktor Klang
On Sun, Dec 14, 2008 at 9:28 AM, Marius marius.dan...@gmail.com wrote: On Dec 14, 3:02 am, Jorge Ortiz jorge.or...@gmail.com wrote: Not to beat a dead horse, but... what's the rationale, again, for throwing an exception after boot? Is there a real danger to some or all RulesSeqs being

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Viktor Klang
David, sounds reasonable. So being able to call prepend/append after boot() makes no sense. In the light of htis, it shouldn't be possible to call the prepend/append outside of boot. I suggest my approach described previously. (Injecting an initialization context into boot and use that to

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread David Pollak
On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang viktor.kl...@gmail.comwrote: David, sounds reasonable. So being able to call prepend/append after boot() makes no sense. In the light of htis, it shouldn't be possible to call the prepend/append outside of boot. I suggest my approach

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Viktor Klang
On Sun, Dec 14, 2008 at 4:01 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang viktor.kl...@gmail.comwrote: David, sounds reasonable. So being able to call prepend/append after boot() makes no sense. In the light of htis, it shouldn't

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Marius
So LiftConfig would take the role of LiftRules from API perspective meaning that LiftRules could be completely hidden from Lift users but available internally to Lift only ? Still from maintainability perspective initializing LifRules with a LiftConfig may imply lots of assignments (unless

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

2008-12-14 Thread Dano
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