[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] 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] 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
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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
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 immutable data, I'd see no problem
exposing it if there is value in exposing it.
But keeping it private is a very viable strategy.
Still from maintainability perspective initializing LifRules with a
LiftConfig may imply lots of assignments (unless LiftRules will
reference a LiftConfig in which case LiftRules code needs to change to
use LiftConfig) or when we'd want to expose some new stuff we'd have
to add it in two different places LiftConfig toexpose it to users and
LiftRules so that Lift code to use that.
Yes, there'd be quite a few assignments, but with a nifty unit test you
could secure that everything is used properly.
Cheers,
Viktor
Otherwise not a bad idea ...
Br's,
Marius
On Dec 14, 5:21 pm, Viktor Klang viktor.kl...@gmail.com wrote:
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.com
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. (Injecting an
initialization
context into boot and use that to configure LiftRules, then we don't
expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the
webapp etc.
I have no idea what this means or how to translate it into code. Can
you
give me an example of code that injects an initialization context into
boot?
class Boot
{
def boot(val lc: LiftConfig) =
{
add all configuration to LiftConfig
}
}
and then in the code that lookups, creates and calls Boot.boot (haven't
got
access to the repository on this machine)
just add/modify the code in the bootstrap loader:
{
val boot = ...//Lookup and create Boot instance
val lc = LiftConfig() //(1)
boot.boot(lc) //(2)
LiftRules.init(lc) //(3)
}
(1) : Must create LiftConfig (this object is the placeholder of the
configuration=
(2) : Pass it into the boot-call
(3) : Initialize LiftRules with the configuration prepared by the
boot-call
result:
No need to expose mutability in LiftRules (since we discovered that
changing
stuff while the webserver was up and running had few applications at
best)
More clear now?
Remeber that this is only a friendly suggestion to an issue brought up by
someone else in this thread.
If such suggestions are superflous, please just tell me so and I'll keep
my
trap shut.
Cheers,
Viktor
Input?
Cheers,
Viktor
On Sun, Dec 14, 2008 at 3:41 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
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
because the tests don't have to worry about the behavior of the
program
changing. The same n steps will lead to the same result.
If anyone can come up with a use case for globally changing program
behavior during program execution, I'm all ears, but barring that,
once the
boot phase is over, the stuff in LiftRules should be frozen.
Thanks,
David
On Sun, Dec 14, 2008 at 3:54 AM, 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, 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 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)
ways of protecting RulesSeqs from mutation than just
throwing
an
exception.
This was actually DPP's suggestion. I'm not sure why would
someone
mutate them after boot but I'm totally opened if there is a
strong
case for allowing that. I do not have strong feelings about
this
so
changing it would be trivial. Still I kind of like
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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
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 protected. Even if they're all dangerous, there are better (i.e., type safe) ways of protecting RulesSeqs from mutation than just throwing an exception. This was actually DPP's suggestion. I'm not sure why would someone mutate them after boot but I'm totally opened if there is a strong case for allowing that. I do not have strong feelings about this so changing it would be trivial. Still I kind of like it this way. What other ways of protecting mutations after boot are you referring? ... something like ignore it and do nothing? Nit-pick: why is 'toList' (which just returns 'rules') defined as private[http] when 'rules' itself is public? Why would you use toList in the lift app code? ...RulesSeq is mainly about adding user functions to lift. If rules itself is public doesn't necessary mean that it should not have its private logic. Also, if RulesSeq are always made up of either Functions or PartialFunctions, maybe we should enforce that at a type level, and the helper methods on Seqs of PFs that now exist in the NamedPF object can be put in the RulesSeq object. But what would be the benefit? .. except that it would simplify a bit how Lift calls these PF's? ... to me distinguishing between functions and partial functions here by using Either or even using different RulesSeq traits would not bring much benefits ... but I hope I'm wrong. --j On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes in LiftRules. In a previous thread Jorge suggested the abstraction of LiftRules variables. 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
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 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) ways of protecting RulesSeqs from mutation than just throwing an exception. This was actually DPP's suggestion. I'm not sure why would someone mutate them after boot but I'm totally opened if there is a strong case for allowing that. I do not have strong feelings about this so changing it would be trivial. Still I kind of like it this way. What other ways of protecting mutations after boot are you referring? ... something like ignore it and do nothing? Hmm, how about locking them by havign a paralell lazy val? val somePf : RuleSeq = Nil; lazy val runtimeSomePf = somePf.toList Then prepending/appending on the somePf AFTER runtimeSomePf has been dereferenced won't make a difference. (runtimeSomePf would be used by Lift internally if that isn't clear enough :) ) Still we'd allow useless strong references on those lists. Or another, perhaps more suitable suggestion: make boot() have an InitializationContext parameter that's only available in the scope of boot, and then the problem should disappear? How would the problem disappear? ... I mean after boot people would still be able to add their functions (from API perspective) and they would be surprised that their functions are not called and yet lift just allowed them to do that. Cheers, Viktor Nit-pick: why is 'toList' (which just returns 'rules') defined as private[http] when 'rules' itself is public? Why would you use toList in the lift app code? ...RulesSeq is mainly about adding user functions to lift. If rules itself is public doesn't necessary mean that it should not have its private logic. Also, if RulesSeq are always made up of either Functions or PartialFunctions, maybe we should enforce that at a type level, and the helper methods on Seqs of PFs that now exist in the NamedPF object can be put in the RulesSeq object. But what would be the benefit? .. except that it would simplify a bit how Lift calls these PF's? ... to me distinguishing between functions and partial functions here by using Either or even using different RulesSeq traits would not bring much benefits ... but I hope I'm wrong. --j On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes in LiftRules. In a previous thread Jorge suggested the abstraction of LiftRules variables. 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 -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ 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
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 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)
ways of protecting RulesSeqs from mutation than just throwing an
exception.
This was actually DPP's suggestion. I'm not sure why would someone
mutate them after boot but I'm totally opened if there is a strong
case for allowing that. I do not have strong feelings about this so
changing it would be trivial. Still I kind of like it this way. What
other ways of protecting mutations after boot are you referring? ...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only have non-append/prependable stuff in LiftRules?
But really, what is it a problem that lift is reconfigurable during runtime?
I thought that was kind of cool?
Cheers,
Viktor
Cheers,
Viktor
Nit-pick: why is 'toList' (which just returns 'rules') defined as
private[http] when 'rules' itself is public?
Why would you use toList in the lift app code? ...RulesSeq is mainly
about adding user functions to lift. If rules itself is public
doesn't necessary mean that it should not have its private logic.
Also, if RulesSeq are always made up of either Functions or
PartialFunctions, maybe we should enforce that at a type level, and
the
helper methods on Seqs of PFs that now exist in the NamedPF object
can be
put in the RulesSeq object.
But what would be the benefit? .. except that it would simplify a bit
how Lift calls these PF's?
... to me distinguishing between functions and partial functions here
by using Either or even using different RulesSeq traits would not
bring much benefits ... but I hope I'm wrong.
--j
On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com
wrote:
All,
I committed a bunch of changes in LiftRules. In a previous thread
Jorge suggested the abstraction of LiftRules variables. 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
--
Viktor Klang
Senior Systems Analyst
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
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
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, 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 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)
ways of protecting RulesSeqs from mutation than just throwing an
exception.
This was actually DPP's suggestion. I'm not sure why would someone
mutate them after boot but I'm totally opened if there is a strong
case for allowing that. I do not have strong feelings about this so
changing it would be trivial. Still I kind of like it this way.
What
other ways of protecting mutations after boot are you referring?
...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only
available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only have non-append/prependable stuff in LiftRules?
But really, what is it a problem that lift is reconfigurable during
runtime?
I thought that was kind of cool?
As I said I don't have strong opinions on this. It was DPP's
suggestion and personally I kind of like it which does not mean that
things can not change :) ... AFAIC reconfiguration at runtime does not
make a whole lot of sense because:
1. We'd have to expose other functions to allow people to also remove
their function not only prepend append them
2. I do not see what kinds of problems runtime reconfiguration really
solve (I'm only referring on the current RulesSeq members). I haven't
encounter a practical need but if you have please let me know.
3. Dynamic behavior can happen inside user's functions without
allowing runtime reconfiguration.
Just my 2 cents ...
P.S.
If the general consensus is to remove this restriction I have no
problem removing it ... so more thoughts/perspectives on this are
welcomed.
I have no opinion, I'm just offering solutions :)
Cheers,
Viktor
Cheers,
Viktor
Nit-pick: why is 'toList' (which just returns 'rules') defined as
private[http] when 'rules' itself is public?
Why would you use toList in the lift app code? ...RulesSeq is
mainly
about adding user functions to lift. If rules itself is public
doesn't necessary mean that it should not have its private logic.
Also, if RulesSeq are always made up of either Functions or
PartialFunctions, maybe we should enforce that at a type level,
and
the
helper methods on Seqs of PFs that now exist in the NamedPF
object
can be
put in the RulesSeq object.
But what would be the benefit? .. except that it would simplify a
bit
how Lift calls these PF's?
... to me distinguishing between functions and partial functions
here
by using Either or even using different RulesSeq traits would not
bring much benefits ... but I hope I'm wrong.
--j
On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com
wrote:
All,
I committed a bunch of changes in LiftRules. In a previous
thread
Jorge suggested the abstraction of LiftRules variables. 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
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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, 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
protected. Even if they're all dangerous, there are better (i.e.,
type
safe)
ways of protecting RulesSeqs from mutation than just throwing an
exception.
This was actually DPP's suggestion. I'm not sure why would someone
mutate them after boot but I'm totally opened if there is a strong
case for allowing that. I do not have strong feelings about this so
changing it would be trivial. Still I kind of like it this way. What
other ways of protecting mutations after boot are you referring? ...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only have non-append/prependable stuff in LiftRules?
But really, what is it a problem that lift is reconfigurable during runtime?
I thought that was kind of cool?
As I said I don't have strong opinions on this. It was DPP's
suggestion and personally I kind of like it which does not mean that
things can not change :) ... AFAIC reconfiguration at runtime does not
make a whole lot of sense because:
1. We'd have to expose other functions to allow people to also remove
their function not only prepend append them
2. I do not see what kinds of problems runtime reconfiguration really
solve (I'm only referring on the current RulesSeq members). I haven't
encounter a practical need but if you have please let me know.
3. Dynamic behavior can happen inside user's functions without
allowing runtime reconfiguration.
Just my 2 cents ...
P.S.
If the general consensus is to remove this restriction I have no
problem removing it ... so more thoughts/perspectives on this are
welcomed.
Cheers,
Viktor
Cheers,
Viktor
Nit-pick: why is 'toList' (which just returns 'rules') defined as
private[http] when 'rules' itself is public?
Why would you use toList in the lift app code? ...RulesSeq is mainly
about adding user functions to lift. If rules itself is public
doesn't necessary mean that it should not have its private logic.
Also, if RulesSeq are always made up of either Functions or
PartialFunctions, maybe we should enforce that at a type level, and
the
helper methods on Seqs of PFs that now exist in the NamedPF object
can be
put in the RulesSeq object.
But what would be the benefit? .. except that it would simplify a bit
how Lift calls these PF's?
... to me distinguishing between functions and partial functions here
by using Either or even using different RulesSeq traits would not
bring much benefits ... but I hope I'm wrong.
--j
On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com
wrote:
All,
I committed a bunch of changes in LiftRules. In a previous thread
Jorge suggested the abstraction of LiftRules variables. 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
--
Viktor Klang
Senior Systems Analyst
--
Viktor Klang
Senior Systems Analyst
--~--~-~--~~~---~--~~
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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 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) ways of protecting RulesSeqs from mutation than just throwing an exception. This was actually DPP's suggestion. I'm not sure why would someone mutate them after boot but I'm totally opened if there is a strong case for allowing that. I do not have strong feelings about this so changing it would be trivial. Still I kind of like it this way. What other ways of protecting mutations after boot are you referring? ... something like ignore it and do nothing? Hmm, how about locking them by havign a paralell lazy val? val somePf : RuleSeq = Nil; lazy val runtimeSomePf = somePf.toList Then prepending/appending on the somePf AFTER runtimeSomePf has been dereferenced won't make a difference. (runtimeSomePf would be used by Lift internally if that isn't clear enough :) ) Or another, perhaps more suitable suggestion: make boot() have an InitializationContext parameter that's only available in the scope of boot, and then the problem should disappear? Cheers, Viktor Nit-pick: why is 'toList' (which just returns 'rules') defined as private[http] when 'rules' itself is public? Why would you use toList in the lift app code? ...RulesSeq is mainly about adding user functions to lift. If rules itself is public doesn't necessary mean that it should not have its private logic. Also, if RulesSeq are always made up of either Functions or PartialFunctions, maybe we should enforce that at a type level, and the helper methods on Seqs of PFs that now exist in the NamedPF object can be put in the RulesSeq object. But what would be the benefit? .. except that it would simplify a bit how Lift calls these PF's? ... to me distinguishing between functions and partial functions here by using Either or even using different RulesSeq traits would not bring much benefits ... but I hope I'm wrong. --j On Sat, Dec 13, 2008 at 2:31 PM, Marius marius.dan...@gmail.com wrote: All, I committed a bunch of changes in LiftRules. In a previous thread Jorge suggested the abstraction of LiftRules variables. 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 -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ 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,
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 configure LiftRules, then we don't expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the webapp
etc.
Input?
Cheers,
Viktor
On Sun, Dec 14, 2008 at 3:41 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
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
because the tests don't have to worry about the behavior of the program
changing. The same n steps will lead to the same result.
If anyone can come up with a use case for globally changing program
behavior during program execution, I'm all ears, but barring that, once the
boot phase is over, the stuff in LiftRules should be frozen.
Thanks,
David
On Sun, Dec 14, 2008 at 3:54 AM, 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, 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 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)
ways of protecting RulesSeqs from mutation than just throwing an
exception.
This was actually DPP's suggestion. I'm not sure why would someone
mutate them after boot but I'm totally opened if there is a strong
case for allowing that. I do not have strong feelings about this
so
changing it would be trivial. Still I kind of like it this way.
What
other ways of protecting mutations after boot are you referring?
...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only
available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only have non-append/prependable stuff in LiftRules?
But really, what is it a problem that lift is reconfigurable during
runtime?
I thought that was kind of cool?
As I said I don't have strong opinions on this. It was DPP's
suggestion and personally I kind of like it which does not mean that
things can not change :) ... AFAIC reconfiguration at runtime does not
make a whole lot of sense because:
1. We'd have to expose other functions to allow people to also remove
their function not only prepend append them
2. I do not see what kinds of problems runtime reconfiguration really
solve (I'm only referring on the current RulesSeq members). I haven't
encounter a practical need but if you have please let me know.
3. Dynamic behavior can happen inside user's functions without
allowing runtime reconfiguration.
Just my 2 cents ...
P.S.
If the general consensus is to remove this restriction I have no
problem removing it ... so more thoughts/perspectives on this are
welcomed.
Cheers,
Viktor
Cheers,
Viktor
Nit-pick: why is 'toList' (which just returns 'rules') defined
as
private[http] when 'rules' itself is public?
Why would you use toList in the lift app code? ...RulesSeq is
mainly
about adding user functions to lift. If rules itself is public
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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 described previously. (Injecting an initialization
context into boot and use that to configure LiftRules, then we don't expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the webapp
etc.
I have no idea what this means or how to translate it into code. Can you
give me an example of code that injects an initialization context into
boot?
Input?
Cheers,
Viktor
On Sun, Dec 14, 2008 at 3:41 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
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
because the tests don't have to worry about the behavior of the program
changing. The same n steps will lead to the same result.
If anyone can come up with a use case for globally changing program
behavior during program execution, I'm all ears, but barring that, once the
boot phase is over, the stuff in LiftRules should be frozen.
Thanks,
David
On Sun, Dec 14, 2008 at 3:54 AM, 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, 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 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)
ways of protecting RulesSeqs from mutation than just throwing
an
exception.
This was actually DPP's suggestion. I'm not sure why would
someone
mutate them after boot but I'm totally opened if there is a
strong
case for allowing that. I do not have strong feelings about this
so
changing it would be trivial. Still I kind of like it this way.
What
other ways of protecting mutations after boot are you referring?
...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has
been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only
available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only have non-append/prependable stuff in LiftRules?
But really, what is it a problem that lift is reconfigurable during
runtime?
I thought that was kind of cool?
As I said I don't have strong opinions on this. It was DPP's
suggestion and personally I kind of like it which does not mean that
things can not change :) ... AFAIC reconfiguration at runtime does not
make a whole lot of sense because:
1. We'd have to expose other functions to allow people to also remove
their function not only prepend append them
2. I do not see what kinds of problems runtime reconfiguration really
solve (I'm only referring on the current RulesSeq members). I haven't
encounter a practical need but if you have please let me know.
3. Dynamic behavior can happen inside user's functions without
allowing runtime reconfiguration.
Just my 2 cents ...
P.S.
If the general consensus is to remove this restriction I have no
problem removing it ... so more thoughts/perspectives on this are
welcomed.
Cheers,
Viktor
Cheers,
Viktor
Nit-pick: why is
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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 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 configure LiftRules, then we don't expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the
webapp etc.
I have no idea what this means or how to translate it into code. Can you
give me an example of code that injects an initialization context into
boot?
class Boot
{
def boot(val lc: LiftConfig) =
{
add all configuration to LiftConfig
}
}
and then in the code that lookups, creates and calls Boot.boot (haven't got
access to the repository on this machine)
just add/modify the code in the bootstrap loader:
{
val boot = ...//Lookup and create Boot instance
val lc = LiftConfig() //(1)
boot.boot(lc) //(2)
LiftRules.init(lc) //(3)
}
(1) : Must create LiftConfig (this object is the placeholder of the
configuration=
(2) : Pass it into the boot-call
(3) : Initialize LiftRules with the configuration prepared by the boot-call
result:
No need to expose mutability in LiftRules (since we discovered that changing
stuff while the webserver was up and running had few applications at best)
More clear now?
Remeber that this is only a friendly suggestion to an issue brought up by
someone else in this thread.
If such suggestions are superflous, please just tell me so and I'll keep my
trap shut.
Cheers,
Viktor
Input?
Cheers,
Viktor
On Sun, Dec 14, 2008 at 3:41 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
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
because the tests don't have to worry about the behavior of the program
changing. The same n steps will lead to the same result.
If anyone can come up with a use case for globally changing program
behavior during program execution, I'm all ears, but barring that, once the
boot phase is over, the stuff in LiftRules should be frozen.
Thanks,
David
On Sun, Dec 14, 2008 at 3:54 AM, 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, 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 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)
ways of protecting RulesSeqs from mutation than just throwing
an
exception.
This was actually DPP's suggestion. I'm not sure why would
someone
mutate them after boot but I'm totally opened if there is a
strong
case for allowing that. I do not have strong feelings about this
so
changing it would be trivial. Still I kind of like it this way.
What
other ways of protecting mutations after boot are you referring?
...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has
been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't
clear
enough
:) )
Still we'd allow useless strong references on those lists.
Or another, perhaps more suitable suggestion:
make boot() have an InitializationContext parameter that's only
available
in
the scope of boot, and then the problem should disappear?
How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.
I meant something like:
def boot(val lc : LiftContext) =
{
//prepend/append,configure everything on lc
}
And then when the LiftFilter runt boot:
{
val lc = LiftContext(/*servletContext and stuff goes here*/)
boot(lc)
LiftRules.init(lc)
}
And then only
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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 LiftRules will
reference a LiftConfig in which case LiftRules code needs to change to
use LiftConfig) or when we'd want to expose some new stuff we'd have
to add it in two different places LiftConfig toexpose it to users and
LiftRules so that Lift code to use that.
Otherwise not a bad idea ...
Br's,
Marius
On Dec 14, 5:21 pm, Viktor Klang viktor.kl...@gmail.com wrote:
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 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 configure LiftRules, then we don't expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the
webapp etc.
I have no idea what this means or how to translate it into code. Can you
give me an example of code that injects an initialization context into
boot?
class Boot
{
def boot(val lc: LiftConfig) =
{
add all configuration to LiftConfig
}
}
and then in the code that lookups, creates and calls Boot.boot (haven't got
access to the repository on this machine)
just add/modify the code in the bootstrap loader:
{
val boot = ...//Lookup and create Boot instance
val lc = LiftConfig() //(1)
boot.boot(lc) //(2)
LiftRules.init(lc) //(3)
}
(1) : Must create LiftConfig (this object is the placeholder of the
configuration=
(2) : Pass it into the boot-call
(3) : Initialize LiftRules with the configuration prepared by the boot-call
result:
No need to expose mutability in LiftRules (since we discovered that changing
stuff while the webserver was up and running had few applications at best)
More clear now?
Remeber that this is only a friendly suggestion to an issue brought up by
someone else in this thread.
If such suggestions are superflous, please just tell me so and I'll keep my
trap shut.
Cheers,
Viktor
Input?
Cheers,
Viktor
On Sun, Dec 14, 2008 at 3:41 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
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
because the tests don't have to worry about the behavior of the program
changing. The same n steps will lead to the same result.
If anyone can come up with a use case for globally changing program
behavior during program execution, I'm all ears, but barring that, once
the
boot phase is over, the stuff in LiftRules should be frozen.
Thanks,
David
On Sun, Dec 14, 2008 at 3:54 AM, 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, 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 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)
ways of protecting RulesSeqs from mutation than just throwing
an
exception.
This was actually DPP's suggestion. I'm not sure why would
someone
mutate them after boot but I'm totally opened if there is a
strong
case for allowing that. I do not have strong feelings about this
so
changing it would be trivial. Still I kind of like it this way.
What
other ways of protecting mutations after boot are you referring?
...
something like ignore it and do nothing?
Hmm, how about locking them by havign a paralell lazy val?
val somePf : RuleSeq = Nil;
lazy val runtimeSomePf = somePf.toList
Then prepending/appending on the somePf AFTER runtimeSomePf has
been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't
clear
enough
:) )
Still we'd allow useless strong references on
[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions
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 -~--~~~~--~~--~--~---
