Apache ESME source is now fixed & building cleanly again - thanks to
David for this.
Cheers,
Darren
On Dec 18, 10:48 pm, Darren Hague 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
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"
wrote:
> Darren,
>
> Any LiftRules.append
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.appen
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 wrote:
>
> A bit better, thanks - that fixed the *D
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
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 wrote:
> Dano (or David),
>
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,
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 ha
I'm not at my computer right now, but can't you either use github to
show you the diff? or just do a diff using your local git repo?
Cheers, Tim
Sent from my iPhone
On 15 Dec 2008, at 08:08, Marius wrote:
>
> Sorry Dan ... There were too many changes in LiftRules. You should be
> able to d
On Sun, Dec 14, 2008 at 10:46 PM, Marius 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 immutable data, I'd see no
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
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 wrote:
> All,
>
> I committed a bunch of changes inLiftRules. In a previous thread
> Jorge suggested the abstr
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 LiftRu
On Sun, Dec 14, 2008 at 4:01 PM, David Pollak wrote:
>
>
> On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang wrote:
>
>> 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/app
On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang wrote:
> 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.
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 config
Folks,
I have not had a single instance of wanting to change global application
behavior at runtime. I cannot think of use case for such a feature.
On the other hand, the idea that your program behavior is stable from the
first HTTP request on makes a lot of sense to me. It means tests work
bec
On Sun, Dec 14, 2008 at 12:54 PM, Marius wrote:
>
>
>
> On Dec 14, 12:53 pm, "Viktor Klang" wrote:
> > On Sun, Dec 14, 2008 at 11:42 AM, Marius
> wrote:
> >
> > > On Dec 14, 12:10 pm, "Viktor Klang" wrote:
> > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius
> wrote:
> >
> > > > > On Dec 14, 3:02
On Dec 14, 12:53 pm, "Viktor Klang" wrote:
> On Sun, Dec 14, 2008 at 11:42 AM, Marius wrote:
>
> > On Dec 14, 12:10 pm, "Viktor Klang" wrote:
> > > On Sun, Dec 14, 2008 at 9:28 AM, Marius wrote:
>
> > > > On Dec 14, 3:02 am, "Jorge Ortiz" wrote:
> > > > > Not to beat a dead horse, but... wh
On Sun, Dec 14, 2008 at 11:42 AM, Marius wrote:
>
>
>
> On Dec 14, 12:10 pm, "Viktor Klang" wrote:
> > On Sun, Dec 14, 2008 at 9:28 AM, Marius wrote:
> >
> > > On Dec 14, 3:02 am, "Jorge Ortiz" wrote:
> > > > Not to beat a dead horse, but... what's the rationale, again, for
> > > throwing
> >
On Dec 14, 12:10 pm, "Viktor Klang" wrote:
> On Sun, Dec 14, 2008 at 9:28 AM, Marius wrote:
>
> > On Dec 14, 3:02 am, "Jorge Ortiz" 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
On Sun, Dec 14, 2008 at 9:28 AM, Marius wrote:
>
>
>
> On Dec 14, 3:02 am, "Jorge Ortiz" 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, the
On Dec 14, 3:02 am, "Jorge Ortiz" 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
> protected. Even if they'
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
protected. Even if they're all dangerous, there are better (i.e., type safe)
24 matches
Mail list logo
