[Lift] Re: Proposed localization change to S
I think that adding an overload for loc(String,String) that maps to
loc(String,NodeSeq) with null testing provides simplicity for the user (not
having to explicitly wrap everything in Text() unless you have specific need
for it). At the risk of making this a little more complex but adding some
flexibility, how about
def loc(key : String, default : => String) =
loc(str).openOr(Text(Box.!!(default).openOr("")))
I'm not sure what we really want to return if the provided default is null.
I was also wondering if we want to Log a failed lookup key so that you could
easily determine that you missed some l10n properties. That could look like:
def loc(key : String, default : => String) = loc(str).openOr({
Log.warn({() => "Failed lookup of " + key + " for locale " + S.locale})
Text(Box.!!(default).openOr(""))
}
Cheers,
Derek
On Fri, Mar 6, 2009 at 4:57 PM, David Pollak
wrote:
>
>
> On Fri, Mar 6, 2009 at 3:52 PM, Timothy Perrett
> wrote:
>
>> Isn't the danger here that Text() will explode if for some reason default
>> was null (e.g Reading from a DB)?
>>
>> It's not a massive issue, as people should be diligent about supplying
>> defaults but it's just a though.
>>
>
> You can always add null testing.
> - Show quoted text -
>
>
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 6 Mar 2009, at 18:32, Derek Chen-Becker wrote:
>>
>> It would be a little cleaner if there was a helper overload:
>>
>> def loc (key : String, default : String) = loc(key, Text(default))
>>
>> Derek
>>
>> On Fri, Mar 6, 2009 at 12:16 PM, Timothy Perrett > > wrote:
>>
>>>
>>> I've just been looking at some of the other method overloads in S and
>>> it appears we already have:
>>>
>>> S.loc(String, NodeSeq)
>>>
>>> This is exactly what I need anyway - wondering if there is any need to
>>> override S.? with another method now?
>>>
>>> Cheers, Tim
>>>
>>> On Mar 6, 5:03 pm, Timothy Perrett wrote:
>>> > Sounds cool - I'll make the change and commit it.
>>> >
>>> > Cheers, Tim
>>> >
>>> > On 06/03/2009 16:56, "marius d." wrote:
>>> >
>>> >
>>> >
>>> > > +1 for overloading '? '
>>> >
>>> > > On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
>>> > >> I think this is a reasonable addition, but I would use
>>> >
>>> > >> def ?(key : String, defaultKey : String) = ...
>>> >
>>> > >> That way changing the default text just doesn't require changes to
>>> code.
>>> >
>>> > >> Derek
>>> >
>>> > >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
>>> wrote:
>>> >
>>> > >>> Guys,
>>> >
>>> > >>> I have a situation where I want to localize a bunch of dynamic
>>> texts,
>>> > >>> however the current behavior of S.? is to return the input text if
>>> its
>>> > >>> found in a resource bundle. Whilst I see the rational for this, I
>>> have
>>> > >>> another situation where I want to pass a key, and if it doesn't
>>> find
>>> > >>> it, display something else (the english version). Id rather not use
>>> > >>> the english text as the translation key, as if the english text
>>> > >>> changes, my database translations will break (not good!)
>>> >
>>> > >>> I can achieve the functionality needed right by doing something
>>> like:
>>> >
>>> > >>>S.loc(item.localization_key.toString + ".name") match {
>>> > >>> case Full(t) => t
>>> > >>> case _ => Text(doc.name.toString)
>>> > >>>}
>>> >
>>> > >>> But it would be nice if we could have a utility method in S which
>>> > >>> allowed you do do:
>>> >
>>> > >>> ?("my.localization.key", defaultText.toString)
>>> >
>>> > >>> Thoughts?
>>> >
>>> > >>> Cheers, Tim
>>>
>>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp- Show quoted text -
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
On Fri, Mar 6, 2009 at 3:52 PM, Timothy Perrett wrote:
> Isn't the danger here that Text() will explode if for some reason default
> was null (e.g Reading from a DB)?
>
> It's not a massive issue, as people should be diligent about supplying
> defaults but it's just a though.
>
You can always add null testing.
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 6 Mar 2009, at 18:32, Derek Chen-Becker wrote:
>
> It would be a little cleaner if there was a helper overload:
>
> def loc (key : String, default : String) = loc(key, Text(default))
>
> Derek
>
> On Fri, Mar 6, 2009 at 12:16 PM, Timothy Perrett
> wrote:
>
>>
>> I've just been looking at some of the other method overloads in S and
>> it appears we already have:
>>
>> S.loc(String, NodeSeq)
>>
>> This is exactly what I need anyway - wondering if there is any need to
>> override S.? with another method now?
>>
>> Cheers, Tim
>>
>> On Mar 6, 5:03 pm, Timothy Perrett wrote:
>> > Sounds cool - I'll make the change and commit it.
>> >
>> > Cheers, Tim
>> >
>> > On 06/03/2009 16:56, "marius d." wrote:
>> >
>> >
>> >
>> > > +1 for overloading '? '
>> >
>> > > On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
>> > >> I think this is a reasonable addition, but I would use
>> >
>> > >> def ?(key : String, defaultKey : String) = ...
>> >
>> > >> That way changing the default text just doesn't require changes to
>> code.
>> >
>> > >> Derek
>> >
>> > >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
>> wrote:
>> >
>> > >>> Guys,
>> >
>> > >>> I have a situation where I want to localize a bunch of dynamic
>> texts,
>> > >>> however the current behavior of S.? is to return the input text if
>> its
>> > >>> found in a resource bundle. Whilst I see the rational for this, I
>> have
>> > >>> another situation where I want to pass a key, and if it doesn't find
>> > >>> it, display something else (the english version). Id rather not use
>> > >>> the english text as the translation key, as if the english text
>> > >>> changes, my database translations will break (not good!)
>> >
>> > >>> I can achieve the functionality needed right by doing something
>> like:
>> >
>> > >>>S.loc(item.localization_key.toString + ".name") match {
>> > >>> case Full(t) => t
>> > >>> case _ => Text(doc.name.toString)
>> > >>>}
>> >
>> > >>> But it would be nice if we could have a utility method in S which
>> > >>> allowed you do do:
>> >
>> > >>> ?("my.localization.key", defaultText.toString)
>> >
>> > >>> Thoughts?
>> >
>> > >>> Cheers, Tim
>>
>>
>
>
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
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: reporting snippet instantiation errors
OK, I reworked it a bit so that you not only get the exception, but you get
a stack trace. I can't think of any sane reason that you would want a
snippet constructor exception so I figured the trace would be useful for
troubleshooting. It's checked in on the wip-dcb-mighdoll-snippet-createexcpt
branch. Any objections before I merge it?
Derek
On Fri, Mar 6, 2009 at 10:47 AM, Derek Chen-Becker wrote:
> I agree that it's an iffy pattern, but I also think that it's important to
> make error messages as clear as possible. I'm testing the patch right now
> (made a minor mod) and I'll push the branch to github in a little bit for
> review.
>
> Derek
>
> On Fri, Mar 6, 2009 at 9:14 AM, Timothy Perrett
> wrote:
>
>>
>> Lee,
>>
>> That seems like a pretty dangerous opertation. Wouldn’t you do:
>>
>> class MySnippet {
>> val file: Box[Source] = tryo {
>> Source.fromFile("mistypedFileName")
>> }
>> }
>>
>> In this way you could then use pattern matching and avoid NPE’s
>>
>> Cheers, Tim
>> - Show quoted text -
>>
>>
>> On 06/03/2009 16:04, "Lee Mighdoll" wrote:
>>
>> - Show quoted text -
>>
>> Sure, thanks for taking a look. My snippet class had something like this:
>>
>> import scala.io.Source
>>
>> class MySnippet {
>> val file = Source.fromFile("mistypedFileName")
>> }
>>
>> (The patched version generates two error log messages in this case. I
>> couldn't figure out a small patch to make it just one message.)
>>
>> Lee
>>
>> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
>> wrote:
>>
>> Let me create a branch for this and test it out. Also, could you tell me
>> what the error was with your snippet so I can compare current behavior with
>> what the patch provides?
>>
>> Derek
>>
>>
>> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll
>> wrote:
>>
>> When I had a bug which threw an exception instantiating my snippet, Lift
>> logged a confusing error message: "ClassNotFound". The class was found, it
>> just didn't run correctly...
>>
>> Enclosed is a patch to show a more informative error message.
>>
>> Lee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >>
>>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
Isn't the danger here that Text() will explode if for some reason
default was null (e.g Reading from a DB)?
It's not a massive issue, as people should be diligent about supplying
defaults but it's just a though.
Cheers, Tim
Sent from my iPhone
On 6 Mar 2009, at 18:32, Derek Chen-Becker
wrote:
> It would be a little cleaner if there was a helper overload:
>
> def loc (key : String, default : String) = loc(key, Text(default))
>
> Derek
>
> On Fri, Mar 6, 2009 at 12:16 PM, Timothy Perrett > wrote:
>
> I've just been looking at some of the other method overloads in S and
> it appears we already have:
>
> S.loc(String, NodeSeq)
>
> This is exactly what I need anyway - wondering if there is any need to
> override S.? with another method now?
>
> Cheers, Tim
>
> On Mar 6, 5:03 pm, Timothy Perrett wrote:
> > Sounds cool - I'll make the change and commit it.
> >
> > Cheers, Tim
> >
> > On 06/03/2009 16:56, "marius d." wrote:
> >
> >
> >
> > > +1 for overloading '? '
> >
> > > On Mar 6, 4:52 pm, Derek Chen-Becker
> wrote:
> > >> I think this is a reasonable addition, but I would use
> >
> > >> def ?(key : String, defaultKey : String) = ...
> >
> > >> That way changing the default text just doesn't require changes
> to code.
> >
> > >> Derek
> >
> > >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
> wrote:
> >
> > >>> Guys,
> >
> > >>> I have a situation where I want to localize a bunch of dynamic
> texts,
> > >>> however the current behavior of S.? is to return the input
> text if its
> > >>> found in a resource bundle. Whilst I see the rational for
> this, I have
> > >>> another situation where I want to pass a key, and if it
> doesn't find
> > >>> it, display something else (the english version). Id rather
> not use
> > >>> the english text as the translation key, as if the english text
> > >>> changes, my database translations will break (not good!)
> >
> > >>> I can achieve the functionality needed right by doing
> something like:
> >
> > >>>S.loc(item.localization_key.toString + ".name") match {
> > >>> case Full(t) => t
> > >>> case _ => Text(doc.name.toString)
> > >>>}
> >
> > >>> But it would be nice if we could have a utility method in S
> which
> > >>> allowed you do do:
> >
> > >>> ?("my.localization.key", defaultText.toString)
> >
> > >>> Thoughts?
> >
> > >>> Cheers, Tim
>
>
>
> >
--~--~-~--~~~---~--~~
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: Eclipse + Lift question: WebAppContext is not a member of _root_.org.mortbay.jetty.webapp
> How are you doing eclipse dependency management? Q4e, m2e or maven- > eclipse-plugin? I'm not sure if this answers your question, but when I look at the list of installed software in Eclipse, I don't see anything that matches those names exactly. I see "Maven Integration for Eclipse", version 0.9.7.2009020947, and "Maven Embedder". I got them from m2eclipse.codehaus.org, so I assume that's the "m2e" that you're referring to. --~--~-~--~~~---~--~~ 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: reporting snippet instantiation errors
Actually, I had forgotten that we generally don't accept patches from the
mailing list in order to keep the IP of Lift clean. All of the committers
have to sign release forms to make sure that we don't taint the codebase. In
your case this was relatively minor and I've done the equivalent work on the
codebase myself. In the future it would be preferable to ask for a feature
and let us implement it to be absolutely sure that nothing gets tainted. We
very much appreciate the contributions that people on the list make, but we
really have to be careful to avoid any unpleasant situations. We should
probably have this information outlined on the website somewhere.
Thanks,
Derek
On Fri, Mar 6, 2009 at 3:23 PM, Lee Mighdoll wrote:
> Thanks for both the suggestion and the patch review.
>
> For future reference on submitting patches -- is it best to email a patch
> or is there some more savvy git trick?
>
> Lee
>
>
> On Fri, Mar 6, 2009 at 8:47 AM, Derek Chen-Becker
> wrote:
>
>> I agree that it's an iffy pattern, but I also think that it's important to
>> make error messages as clear as possible. I'm testing the patch right now
>> (made a minor mod) and I'll push the branch to github in a little bit for
>> review.
>>
>> Derek
>>
>> On Fri, Mar 6, 2009 at 9:14 AM, Timothy Perrett
>> wrote:
>>
>>>
>>> Lee,
>>>
>>> That seems like a pretty dangerous opertation. Wouldn’t you do:
>>>
>>> class MySnippet {
>>> val file: Box[Source] = tryo {
>>> Source.fromFile("mistypedFileName")
>>> }
>>> }
>>>
>>> In this way you could then use pattern matching and avoid NPE’s
>>>
>>> Cheers, Tim
>>> - Show quoted text -
>>>
>>>
>>> On 06/03/2009 16:04, "Lee Mighdoll" wrote:
>>>
>>> - Show quoted text -
>>>
>>> Sure, thanks for taking a look. My snippet class had something like
>>> this:
>>>
>>> import scala.io.Source
>>>
>>> class MySnippet {
>>> val file = Source.fromFile("mistypedFileName")
>>> }
>>>
>>> (The patched version generates two error log messages in this case. I
>>> couldn't figure out a small patch to make it just one message.)
>>>
>>> Lee
>>>
>>> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
>>> wrote:
>>>
>>> Let me create a branch for this and test it out. Also, could you tell me
>>> what the error was with your snippet so I can compare current behavior with
>>> what the patch provides?
>>>
>>> Derek
>>>
>>>
>>> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll
>>> wrote:
>>>
>>> When I had a bug which threw an exception instantiating my snippet, Lift
>>> logged a confusing error message: "ClassNotFound". The class was found, it
>>> just didn't run correctly...
>>>
>>> Enclosed is a patch to show a more informative error message.
>>>
>>> Lee
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
Thanks for both the suggestion and the patch review.
For future reference on submitting patches -- is it best to email a patch or
is there some more savvy git trick?
Lee
On Fri, Mar 6, 2009 at 8:47 AM, Derek Chen-Becker wrote:
> I agree that it's an iffy pattern, but I also think that it's important to
> make error messages as clear as possible. I'm testing the patch right now
> (made a minor mod) and I'll push the branch to github in a little bit for
> review.
>
> Derek
>
> On Fri, Mar 6, 2009 at 9:14 AM, Timothy Perrett
> wrote:
>
>>
>> Lee,
>>
>> That seems like a pretty dangerous opertation. Wouldn’t you do:
>>
>> class MySnippet {
>> val file: Box[Source] = tryo {
>> Source.fromFile("mistypedFileName")
>> }
>> }
>>
>> In this way you could then use pattern matching and avoid NPE’s
>>
>> Cheers, Tim
>> - Show quoted text -
>>
>>
>> On 06/03/2009 16:04, "Lee Mighdoll" wrote:
>>
>> - Show quoted text -
>>
>> Sure, thanks for taking a look. My snippet class had something like this:
>>
>> import scala.io.Source
>>
>> class MySnippet {
>> val file = Source.fromFile("mistypedFileName")
>> }
>>
>> (The patched version generates two error log messages in this case. I
>> couldn't figure out a small patch to make it just one message.)
>>
>> Lee
>>
>> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
>> wrote:
>>
>> Let me create a branch for this and test it out. Also, could you tell me
>> what the error was with your snippet so I can compare current behavior with
>> what the patch provides?
>>
>> Derek
>>
>>
>> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll
>> wrote:
>>
>> When I had a bug which threw an exception instantiating my snippet, Lift
>> logged a confusing error message: "ClassNotFound". The class was found, it
>> just didn't run correctly...
>>
>> Enclosed is a patch to show a more informative error message.
>>
>> Lee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
Thanks for both the suggestion and the patch review.
For future reference on submitting patches -- is it best to email a patch or
is there some more savvy git trick?
Lee
On Fri, Mar 6, 2009 at 8:47 AM, Derek Chen-Becker wrote:
> I agree that it's an iffy pattern, but I also think that it's important to
> make error messages as clear as possible. I'm testing the patch right now
> (made a minor mod) and I'll push the branch to github in a little bit for
> review.
>
> Derek
>
> On Fri, Mar 6, 2009 at 9:14 AM, Timothy Perrett
> wrote:
>
>>
>> Lee,
>>
>> That seems like a pretty dangerous opertation. Wouldn’t you do:
>>
>> class MySnippet {
>> val file: Box[Source] = tryo {
>> Source.fromFile("mistypedFileName")
>> }
>> }
>>
>> In this way you could then use pattern matching and avoid NPE’s
>>
>> Cheers, Tim
>> - Show quoted text -
>>
>>
>> On 06/03/2009 16:04, "Lee Mighdoll" wrote:
>>
>> - Show quoted text -
>>
>> Sure, thanks for taking a look. My snippet class had something like this:
>>
>> import scala.io.Source
>>
>> class MySnippet {
>> val file = Source.fromFile("mistypedFileName")
>> }
>>
>> (The patched version generates two error log messages in this case. I
>> couldn't figure out a small patch to make it just one message.)
>>
>> Lee
>>
>> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
>> wrote:
>>
>> Let me create a branch for this and test it out. Also, could you tell me
>> what the error was with your snippet so I can compare current behavior with
>> what the patch provides?
>>
>> Derek
>>
>>
>> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll
>> wrote:
>>
>> When I had a bug which threw an exception instantiating my snippet, Lift
>> logged a confusing error message: "ClassNotFound". The class was found, it
>> just didn't run correctly...
>>
>> Enclosed is a patch to show a more informative error message.
>>
>> Lee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: Record and JSON
And I forgot the link: http://paste.pocoo.org/show/106757/ --j On Fri, Mar 6, 2009 at 12:11 PM, Jorge Ortiz wrote: > Hey Folks, > > I wrote a Json AST and parser/serializer for unrelated reasons yesterday. > This could be the basis of a Record <--> Json tool. > > --j > > > On Wed, Mar 4, 2009 at 9:11 AM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> >> >> On Wed, Mar 4, 2009 at 9:08 AM, Marius wrote: >> >>> >>> Hi, >>> >>> I was thinking that it might be useful to be able to obtain a JSON >>> representation of a Record and also from a JSON construct to create a >>> Record. >>> >>> Record defines now: >>> >>> def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil >>> >>> but that's not very intuitive ... not to mention not implemented yet. >>> >>> Thoughts ? >> >> >> I've been needing bi-directional JSON support to allow for the creation of >> complex JSON data structures. >> >> So, my thought is I have a need, but not a solution. :-) >> >> >>> >>> >>> Br's, >>> Marius >>> >>> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> 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: Record and JSON
Hey Folks, I wrote a Json AST and parser/serializer for unrelated reasons yesterday. This could be the basis of a Record <--> Json tool. --j On Wed, Mar 4, 2009 at 9:11 AM, David Pollak wrote: > > > On Wed, Mar 4, 2009 at 9:08 AM, Marius wrote: > >> >> Hi, >> >> I was thinking that it might be useful to be able to obtain a JSON >> representation of a Record and also from a JSON construct to create a >> Record. >> >> Record defines now: >> >> def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil >> >> but that's not very intuitive ... not to mention not implemented yet. >> >> Thoughts ? > > > I've been needing bi-directional JSON support to allow for the creation of > complex JSON data structures. > > So, my thought is I have a need, but not a solution. :-) > > >> >> >> Br's, >> Marius >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > 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: MappedTextarea problem
blueprintCSS which is more than likely the CSS boss for your app defines textarea style in screen.css. I tend to add a dedicated stylesheet for just such an overriding- required situation. Tyler On Mar 3, 5:05 pm, Derek Chen-Becker wrote: > I agree with Joachim, this is most likely a CSS issue since we're seeing > explicit "rows" and "cols" attributes on the element. If you get firebug and > inspect the page with it, you should be able to see what is controlling the > textarea size. > > Derek > > On Tue, Mar 3, 2009 at 3:29 PM, DavidV wrote: > > > Here's the XHTML generated by the Firefox page source. When I change > > the values in my own code, they also change in the source, but the > > size of the textarea does not change at all. > > > > > Current Medication(s) > > > lift:gc="F984808911835ROX" rows="3" cols="15"> > > > > Intended Medication(s) > > > > lift:gc="F984808911836ZOS" rows="3" cols="15"> > > > > Comments > > > lift:gc="F984808911837DS1" rows="3" cols="15"> > > > On Mar 3, 4:17 pm, "Joachim A." wrote: > > > It might be the case that David has some css rules which change the size > > of > > > the textarea. > > > It's easy to check in firebug or something similair to see what the > > applied > > > values are. > > > > Joachim > > > > > Can you post the generated XHTML for the textarea? I would want to > > verify > > > > that it's actually setting the attributes. > > > > > Derek > > > > > On Tue, Mar 3, 2009 at 2:08 PM, DavidV > > wrote: > > > > > For some reason when I override the textareaRows and textareaCols > > > > > methods in MappedTextarea, the size of the text block appears the > > same > > > > > in my web application no matter what size I assign to the rows and > > > > > cols. Does anyone know how to decrease the size of the blank text > > > > > area that shows up on the webpage? > > > > > Thanks, > > > > > David > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
It would be a little cleaner if there was a helper overload:
def loc (key : String, default : String) = loc(key, Text(default))
Derek
On Fri, Mar 6, 2009 at 12:16 PM, Timothy Perrett wrote:
>
> I've just been looking at some of the other method overloads in S and
> it appears we already have:
>
> S.loc(String, NodeSeq)
>
> This is exactly what I need anyway - wondering if there is any need to
> override S.? with another method now?
>
> Cheers, Tim
>
> On Mar 6, 5:03 pm, Timothy Perrett wrote:
> > Sounds cool - I'll make the change and commit it.
> >
> > Cheers, Tim
> >
> > On 06/03/2009 16:56, "marius d." wrote:
> >
> >
> >
> > > +1 for overloading '? '
> >
> > > On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
> > >> I think this is a reasonable addition, but I would use
> >
> > >> def ?(key : String, defaultKey : String) = ...
> >
> > >> That way changing the default text just doesn't require changes to
> code.
> >
> > >> Derek
> >
> > >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
> wrote:
> >
> > >>> Guys,
> >
> > >>> I have a situation where I want to localize a bunch of dynamic texts,
> > >>> however the current behavior of S.? is to return the input text if
> its
> > >>> found in a resource bundle. Whilst I see the rational for this, I
> have
> > >>> another situation where I want to pass a key, and if it doesn't find
> > >>> it, display something else (the english version). Id rather not use
> > >>> the english text as the translation key, as if the english text
> > >>> changes, my database translations will break (not good!)
> >
> > >>> I can achieve the functionality needed right by doing something like:
> >
> > >>>S.loc(item.localization_key.toString + ".name") match {
> > >>> case Full(t) => t
> > >>> case _ => Text(doc.name.toString)
> > >>>}
> >
> > >>> But it would be nice if we could have a utility method in S which
> > >>> allowed you do do:
> >
> > >>> ?("my.localization.key", defaultText.toString)
> >
> > >>> Thoughts?
> >
> > >>> Cheers, Tim
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
I've just been looking at some of the other method overloads in S and
it appears we already have:
S.loc(String, NodeSeq)
This is exactly what I need anyway - wondering if there is any need to
override S.? with another method now?
Cheers, Tim
On Mar 6, 5:03 pm, Timothy Perrett wrote:
> Sounds cool - I'll make the change and commit it.
>
> Cheers, Tim
>
> On 06/03/2009 16:56, "marius d." wrote:
>
>
>
> > +1 for overloading '? '
>
> > On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
> >> I think this is a reasonable addition, but I would use
>
> >> def ?(key : String, defaultKey : String) = ...
>
> >> That way changing the default text just doesn't require changes to code.
>
> >> Derek
>
> >> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett
> >> wrote:
>
> >>> Guys,
>
> >>> I have a situation where I want to localize a bunch of dynamic texts,
> >>> however the current behavior of S.? is to return the input text if its
> >>> found in a resource bundle. Whilst I see the rational for this, I have
> >>> another situation where I want to pass a key, and if it doesn't find
> >>> it, display something else (the english version). Id rather not use
> >>> the english text as the translation key, as if the english text
> >>> changes, my database translations will break (not good!)
>
> >>> I can achieve the functionality needed right by doing something like:
>
> >>> S.loc(item.localization_key.toString + ".name") match {
> >>> case Full(t) => t
> >>> case _ => Text(doc.name.toString)
> >>> }
>
> >>> But it would be nice if we could have a utility method in S which
> >>> allowed you do do:
>
> >>> ?("my.localization.key", defaultText.toString)
>
> >>> Thoughts?
>
> >>> Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
Sounds cool - I'll make the change and commit it.
Cheers, Tim
On 06/03/2009 16:56, "marius d." wrote:
>
> +1 for overloading '? '
>
> On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
>> I think this is a reasonable addition, but I would use
>>
>> def ?(key : String, defaultKey : String) = ...
>>
>> That way changing the default text just doesn't require changes to code.
>>
>> Derek
>>
>> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett wrote:
>>
>>> Guys,
>>
>>> I have a situation where I want to localize a bunch of dynamic texts,
>>> however the current behavior of S.? is to return the input text if its
>>> found in a resource bundle. Whilst I see the rational for this, I have
>>> another situation where I want to pass a key, and if it doesn't find
>>> it, display something else (the english version). Id rather not use
>>> the english text as the translation key, as if the english text
>>> changes, my database translations will break (not good!)
>>
>>> I can achieve the functionality needed right by doing something like:
>>
>>> S.loc(item.localization_key.toString + ".name") match {
>>> case Full(t) => t
>>> case _ => Text(doc.name.toString)
>>> }
>>
>>> But it would be nice if we could have a utility method in S which
>>> allowed you do do:
>>
>>> ?("my.localization.key", defaultText.toString)
>>
>>> Thoughts?
>>
>>> Cheers, Tim
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
+1 for overloading '? '
On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
> I think this is a reasonable addition, but I would use
>
> def ?(key : String, defaultKey : String) = ...
>
> That way changing the default text just doesn't require changes to code.
>
> Derek
>
> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett wrote:
>
> > Guys,
>
> > I have a situation where I want to localize a bunch of dynamic texts,
> > however the current behavior of S.? is to return the input text if its
> > found in a resource bundle. Whilst I see the rational for this, I have
> > another situation where I want to pass a key, and if it doesn't find
> > it, display something else (the english version). Id rather not use
> > the english text as the translation key, as if the english text
> > changes, my database translations will break (not good!)
>
> > I can achieve the functionality needed right by doing something like:
>
> > S.loc(item.localization_key.toString + ".name") match {
> > case Full(t) => t
> > case _ => Text(doc.name.toString)
> > }
>
> > But it would be nice if we could have a utility method in S which
> > allowed you do do:
>
> > ?("my.localization.key", defaultText.toString)
>
> > Thoughts?
>
> > Cheers, Tim
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
I agree that it's an iffy pattern, but I also think that it's important to
make error messages as clear as possible. I'm testing the patch right now
(made a minor mod) and I'll push the branch to github in a little bit for
review.
Derek
On Fri, Mar 6, 2009 at 9:14 AM, Timothy Perrett wrote:
>
> Lee,
>
> That seems like a pretty dangerous opertation. Wouldn’t you do:
>
> class MySnippet {
> val file: Box[Source] = tryo {
> Source.fromFile("mistypedFileName")
> }
> }
>
> In this way you could then use pattern matching and avoid NPE’s
>
> Cheers, Tim- Show quoted text -
>
>
> On 06/03/2009 16:04, "Lee Mighdoll" wrote:
>
> - Show quoted text -
>
> Sure, thanks for taking a look. My snippet class had something like this:
>
> import scala.io.Source
>
> class MySnippet {
> val file = Source.fromFile("mistypedFileName")
> }
>
> (The patched version generates two error log messages in this case. I
> couldn't figure out a small patch to make it just one message.)
>
> Lee
>
> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
> wrote:
>
> Let me create a branch for this and test it out. Also, could you tell me
> what the error was with your snippet so I can compare current behavior with
> what the patch provides?
>
> Derek
>
>
> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll
> wrote:
>
> When I had a bug which threw an exception instantiating my snippet, Lift
> logged a confusing error message: "ClassNotFound". The class was found, it
> just didn't run correctly...
>
> Enclosed is a patch to show a more informative error message.
>
> Lee
>
>
>
>
>
>
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
Lee,
That seems like a pretty dangerous opertation. Wouldn¹t you do:
class MySnippet {
val file: Box[Source] = tryo {
Source.fromFile("mistypedFileName")
}
}
In this way you could then use pattern matching and avoid NPE¹s
Cheers, Tim
On 06/03/2009 16:04, "Lee Mighdoll" wrote:
> Sure, thanks for taking a look. My snippet class had something like this:
>
> import scala.io.Source
>
> class MySnippet {
> val file = Source.fromFile("mistypedFileName")
> }
>
> (The patched version generates two error log messages in this case. I
> couldn't figure out a small patch to make it just one message.)
>
> Lee
>
> On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker
> wrote:
>> Let me create a branch for this and test it out. Also, could you tell me what
>> the error was with your snippet so I can compare current behavior with what
>> the patch provides?
>>
>> Derek
>>
>>
>> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll wrote:
>>> When I had a bug which threw an exception instantiating my snippet, Lift
>>> logged a confusing error message: "ClassNotFound". The class was found, it
>>> just didn't run correctly...
>>>
>>> Enclosed is a patch to show a more informative error message.
>>>
>>> Lee
>>>
>>>
>>
>>
>>
>
>
> >
>
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
Sure, thanks for taking a look. My snippet class had something like this:
import scala.io.Source
class MySnippet {
val file = Source.fromFile("mistypedFileName")
}
(The patched version generates two error log messages in this case. I
couldn't figure out a small patch to make it just one message.)
Lee
On Fri, Mar 6, 2009 at 7:20 AM, Derek Chen-Becker wrote:
> Let me create a branch for this and test it out. Also, could you tell me
> what the error was with your snippet so I can compare current behavior with
> what the patch provides?
>
> Derek
>
>
> On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll wrote:
>
>> When I had a bug which threw an exception instantiating my snippet, Lift
>> logged a confusing error message: "ClassNotFound". The class was found, it
>> just didn't run correctly...
>>
>> Enclosed is a patch to show a more informative error message.
>>
>> Lee
>>
>>
>>
>
> >
>
--~--~-~--~~~---~--~~
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: reporting snippet instantiation errors
Sorry, to clarify, it was the snippet class constructor that threw, correct? On Fri, Mar 6, 2009 at 8:20 AM, Derek Chen-Becker wrote: > Let me create a branch for this and test it out. Also, could you tell me > what the error was with your snippet so I can compare current behavior with > what the patch provides? > > Derek- Show quoted text - > > > On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll wrote: > >> When I had a bug which threw an exception instantiating my snippet, Lift >> logged a confusing error message: "ClassNotFound". The class was found, it >> just didn't run correctly... >> >> Enclosed is a patch to show a more informative error message. >> >> Lee >> >> >> >> > --~--~-~--~~~---~--~~ 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: reporting snippet instantiation errors
Let me create a branch for this and test it out. Also, could you tell me what the error was with your snippet so I can compare current behavior with what the patch provides? Derek On Thu, Mar 5, 2009 at 10:59 PM, Lee Mighdoll wrote: > When I had a bug which threw an exception instantiating my snippet, Lift > logged a confusing error message: "ClassNotFound". The class was found, it > just didn't run correctly... > > Enclosed is a patch to show a more informative error message. > > Lee > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
I think this is a reasonable addition, but I would use
def ?(key : String, defaultKey : String) = ...
That way changing the default text just doesn't require changes to code.
Derek
On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett wrote:
>
> Guys,
>
> I have a situation where I want to localize a bunch of dynamic texts,
> however the current behavior of S.? is to return the input text if its
> found in a resource bundle. Whilst I see the rational for this, I have
> another situation where I want to pass a key, and if it doesn't find
> it, display something else (the english version). Id rather not use
> the english text as the translation key, as if the english text
> changes, my database translations will break (not good!)
>
> I can achieve the functionality needed right by doing something like:
>
>S.loc(item.localization_key.toString + ".name") match {
> case Full(t) => t
> case _ => Text(doc.name.toString)
>}
>
> But it would be nice if we could have a utility method in S which
> allowed you do do:
>
> ?("my.localization.key", defaultText.toString)
>
> Thoughts?
>
> Cheers, Tim
> >
>
--~--~-~--~~~---~--~~
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] Proposed localization change to S
Guys,
I have a situation where I want to localize a bunch of dynamic texts,
however the current behavior of S.? is to return the input text if its
found in a resource bundle. Whilst I see the rational for this, I have
another situation where I want to pass a key, and if it doesn't find
it, display something else (the english version). Id rather not use
the english text as the translation key, as if the english text
changes, my database translations will break (not good!)
I can achieve the functionality needed right by doing something like:
S.loc(item.localization_key.toString + ".name") match {
case Full(t) => t
case _ => Text(doc.name.toString)
}
But it would be nice if we could have a utility method in S which
allowed you do do:
?("my.localization.key", defaultText.toString)
Thoughts?
Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed addition to LRU
Scratch that, had to change to: def keys: List[KeyType] = map.keySet().toList.map(_.asInstanceOf [KeyType]) because of a type error. On Mar 6, 9:50 am, Timothy Perrett wrote: > Ok - I changed it to: > > def keys: List[KeyType] = map.keySet().asInstanceOf[Set > [KeyType]].toList > > there was an implicit in jcl: > > import _root_.scala.collection.jcl.Conversions.convertSet > > Cheers, Tim > > On Mar 5, 9:49 pm, David Pollak wrote: > > > On Thu, Mar 5, 2009 at 12:04 PM, Timothy Perrett > > wrote: > > > > I agree, and I would have gone for toList or toSeq or something > > > however its a java.util.Set, so in order to get that functionality > > > we'd need to to: > > > > .toArray.toList > > > Try looking at scala.collection.jcl I think there's an implicit that will > > take the set and turn it into a Seq[whatever] > > > > Whilst I could live with this, it does feel somewhat dirty. > > > > Cheers, Tim > > > > On Mar 5, 7:57 pm, David Pollak wrote: > > > > Looks good to me except the toArray part... I prefer toList is that's > > > > available > > > > > On Mar 5, 2009 11:41 AM, "Tim Perrett" wrote: > > > > > Guys, > > > > > I have a situation where I need to retrive all the keys in my > > > > KeyedCache - however, KeyedCache extends LRU, which it turn uses > > > > apache commons LRUMap internally. > > > > > The LRU class has a private val map: LRUMap > > > > > Is there any objections to me adding a method to LRU to return all the > > > > keys from that map?: > > > > > // off the top of my head... > > > > def keys: Array[KeyType] = map.keySet().asInstanceOf[Set > > > > [KeyType]].toArray > > > > > Thoughts? > > > > > Cheers, Tim > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > 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: Proposed addition to LRU
Ok - I changed it to: def keys: List[KeyType] = map.keySet().asInstanceOf[Set [KeyType]].toList there was an implicit in jcl: import _root_.scala.collection.jcl.Conversions.convertSet Cheers, Tim On Mar 5, 9:49 pm, David Pollak wrote: > On Thu, Mar 5, 2009 at 12:04 PM, Timothy Perrett > wrote: > > > > > I agree, and I would have gone for toList or toSeq or something > > however its a java.util.Set, so in order to get that functionality > > we'd need to to: > > > .toArray.toList > > Try looking at scala.collection.jcl I think there's an implicit that will > take the set and turn it into a Seq[whatever] > > > > > > > Whilst I could live with this, it does feel somewhat dirty. > > > Cheers, Tim > > > On Mar 5, 7:57 pm, David Pollak wrote: > > > Looks good to me except the toArray part... I prefer toList is that's > > > available > > > > On Mar 5, 2009 11:41 AM, "Tim Perrett" wrote: > > > > Guys, > > > > I have a situation where I need to retrive all the keys in my > > > KeyedCache - however, KeyedCache extends LRU, which it turn uses > > > apache commons LRUMap internally. > > > > The LRU class has a private val map: LRUMap > > > > Is there any objections to me adding a method to LRU to return all the > > > keys from that map?: > > > > // off the top of my head... > > > def keys: Array[KeyType] = map.keySet().asInstanceOf[Set > > > [KeyType]].toArray > > > > Thoughts? > > > > Cheers, Tim > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > 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: Record and JSON
POC == Proof of concept On Mar 5, 11:33 pm, "Charles F. Munat" wrote: > POC? --~--~-~--~~~---~--~~ 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: Eclipse + Lift question: WebAppContext is not a member of _root_.org.mortbay.jetty.webapp
On Mar 6, 1:07 am, David Bernard wrote: > try (not tested) > * In your pom.xml, force the version of jetty to be an exact version > like 6.1.14 instead of the current version of jetty something like > [6.1,) (== latest version available upper 6.1) Setting version to [6.1.6,7) works fine. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
