I am okay with an NPE thrown from using S outside a request. Yeah, it'd be
nicer to have a more polite error message, but there should be no creep
towards being able to call S outside a request/session scope.
Also, except for tests or actors, one should never think about initializing
S.
On
So would you prefer no change or change to have better error message?
-Ross
On Nov 23, 2009, at 1:55 PM, David Pollak wrote:
I am okay with an NPE thrown from using S outside a request. Yeah,
it'd be nicer to have a more polite error message, but there should
be no creep towards being
On Mon, Nov 23, 2009 at 11:01 AM, Ross Mellgren dri...@gmail.com wrote:
So would you prefer no change or change to have better error message?
Change to have a better error message
-Ross
On Nov 23, 2009, at 1:55 PM, David Pollak wrote:
I am okay with an NPE thrown from using S outside a
I'm poking around the LiftTicket codebase, and currently it suffers from an NPE
on Boot:
ERROR - Failed to Boot
java.lang.ExceptionInInitializerError
at
org.liftticket.liftticket.snippet.UserAdmin$.menus(UserAdmin.scala:41)
at bootstrap.liftweb.Boot.buildMenus(Boot.scala:74)
Ross,
Where in your code are you calling this method? What I'd the context
that puts it outside of a request?
Cheers, Tim
Sent from my iPhone
On 21 Nov 2009, at 23:03, Ross Mellgren dri...@gmail.com wrote:
I'm poking around the LiftTicket codebase, and currently it suffers
from an NPE
It's being called to provide the link text for menus during sitemap creation at
boot time, as well as during class initialization time to make some vals that
contain error text. I believe initializing these at Boot time to be incorrect
since the correct locale cannot be known until a request is
Oops I misspoke, the strToLinkText conversion is already lazy, so it's not the
menu text, just the message. Here is the diff:
@@ -91,7 +91,7 @@ object RoleAdmin {
case _ = Text(S.?(No instance to delete))
}
- val missingTemplate = Text(S.?(Missing template))
+ def missingTemplate =
I agree that getting an NPE is less than desirable!
I'm not sure things are wrong per-say; the defualt locale calculator
has an app wide setting and there is nothing to say that that a user
must implement their locale calculator in a particular way... This is
one of the great things about
Hmm, you raise an interesting point. So I guess the situation is more
variegated:
1) If you have a locale calculator that works per-request and does not have an
app default, then it is definitely incorrect to call S.? out of a request
context,
2) but if you have one that works app-wide then it
