[Lift] Re: Question about the Getting Started Guide

[Indrajit Raychaudhuri]

Jack,

maven-jetty-plugin belongs to the group org.mortbay.jetty, not 
org.apache.maven.plugins. This makes me suspect that your jetty plugin 
isn't configured properly.

A minimal jetty plugin configuration would look like this:

   
 org.mortbay.jetty
 maven-jetty-plugin
 
   /
 
   

Could you please ensure this config under build -> plugin section in 
your pom.xml and retry?

Cheers, Indrajit



On 30/09/09 10:09 AM, jlist9 wrote:
>
> I just tried it on another computer and got exactly the same error when
> running (below). I think something is broken. I checked the mvn output
> in the first run to create helloworld project and didn't see any mentioning
> of jetty...
>
> D:\Java\liftweb\work>mvn jetty:run
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'jetty'.
> [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
> for updates from central
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
> not exist or no valid version c
> ould be found
> [INFO] 
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO] 
> 
> [INFO] Total time:<  1 second
> [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
> [INFO] Final Memory: 1M/4M
> [INFO] 
> 
>
> On Tue, Sep 29, 2009 at 8:59 PM, Naftoli Gugenheim  
> wrote:
>>
>> I had such an issue when it was confused about which version of Jetty. Is 
>> there any more detail? Try running with error details enabled (mvn -help 
>> should tell you how).
>>
>> -
>> jlist9  wrote:
>>
>>
>> Yes, I have a network connection. Maven downloaded some other
>> components and the end result was BUILD SUCCESSFUL...
>>
>> On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheim  
>> wrote:
>>>
>>> Do you have a network connection? The idea of maven is that it
>>> downloads whatever it's missing.
>>>
>>> On Tue, Sep 29, 2009 at 9:11 PM, jlist9  wrote:

 Hi,

 I'm new to Lift. I'm trying to follow the getting started guide to
 build the first simple
 demo.helloworld project. At the end of Maven command output I see
 "BUILD SUCCESSFUL".
 However, when I run "mvn jetty:run", I get error:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
 exist or no valid version could be found

 I wonder if I need to manually install jetty? If so, is there any
 configuration instructions?

 Thanks
 Jack

>

>>>

>>>
>>
>>
>>
>>>
>>
>
> >

--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

[jlist9]

I just tried it on another computer and got exactly the same error when
running (below). I think something is broken. I checked the mvn output
in the first run to create helloworld project and didn't see any mentioning
of jetty...

D:\Java\liftweb\work>mvn jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking
for updates from central
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
not exist or no valid version c
ould be found
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009
[INFO] Final Memory: 1M/4M
[INFO] 

On Tue, Sep 29, 2009 at 8:59 PM, Naftoli Gugenheim  wrote:
>
> I had such an issue when it was confused about which version of Jetty. Is 
> there any more detail? Try running with error details enabled (mvn -help 
> should tell you how).
>
> -
> jlist9 wrote:
>
>
> Yes, I have a network connection. Maven downloaded some other
> components and the end result was BUILD SUCCESSFUL...
>
> On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheim  
> wrote:
>>
>> Do you have a network connection? The idea of maven is that it
>> downloads whatever it's missing.
>>
>> On Tue, Sep 29, 2009 at 9:11 PM, jlist9  wrote:
>>>
>>> Hi,
>>>
>>> I'm new to Lift. I'm trying to follow the getting started guide to
>>> build the first simple
>>> demo.helloworld project. At the end of Maven command output I see
>>> "BUILD SUCCESSFUL".
>>> However, when I run "mvn jetty:run", I get error:
>>>
>>> The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
>>> exist or no valid version could be found
>>>
>>> I wonder if I need to manually install jetty? If so, is there any
>>> configuration instructions?
>>>
>>> Thanks
>>> Jack
>>>
>>> >
>>>
>>
>> >
>>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Concurrent Web Service Requests?

[marius d.]

lift is already a "reserved" prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.

Br's,
Marius

On Sep 29, 11:11 pm, Naftoli Gugenheim  wrote:
> So what is your proposal? Am I interpreting you correctly that you are for a 
> prefix of 'lift'? And it will be a reserved suffix?
>
> -
>
> marius d. wrote:
>
> I realize that I may be a little late here but I do have second
> thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
> understand that these attributes are not really snippets or built is
> snippets but is this an enough reason to introduce a new prefix?
> Personally I don't think so. Historically lift reserved prefix names
> were heavily debated and argued and this is a little sensitive area.
>
> But the good news is that I may be the only one feeling this way about
> this and everyone else likes it so I'm just a negligible minority.
>
> Br's,
> Marius
>
> On Sep 25, 12:02 pm, David Pollak 
> wrote:
>
> > On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
> > wrote:
>
> > > If you like the idea of having them all as attributes but don't like the
> > > idea of using a single attribute ('xx:eager_eval="true" 
> > > xx:parallel="true"'
> > > rather than 'xx:eval="eager parallel"' as I suggested, where xx is the
> > > prefix to be chosen) then maybe the prefix should be 'eval'.
>
> > I've changed the code to:
> > liftx:eager_eval="true"
> > liftx:par="true" | liftx:parallel="true"
>
> > The reasons for not combining them:
>
> >    - They are evaluated in different parts of the code, thus eager/parallel
> >    doesn't make sense from a code path perspective
> >    - I am reserving the value of liftx:par for future implementation to
> >    allow farming the snippet evaluation to another mechanism.  Right now, 
> > it's
> >    hard-coded to use LiftActors.  I can see a time when it would work with 
> > Akka
> >    actors or some other parallelization mechanism
>
> > > As far as "ajax evaluation" I'm not sure I'm understanding. Could you show
> > > me what you're thinking?
> > > If I have a snippet
> > > 
> > > what would be the syntax to have it inserted via ajax?
>
> >  
> >   
> > 
>
> > > -
> > > Ross Mellgren wrote:
>
> > > My 2 cents,
>
> > > I'm not sure I'm a fan of do: namespace, though I agree it would be
> > > nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
>
> > > -Ross
>
> > > On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
>
> > > > On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim <
> > > naftoli...@gmail.com
> > > > > wrote:
>
> > > > What do you mean by "as a normal snippet"?
>
> > > > The parallel snippet processing is implemented deep inside
> > > > LiftSession.  It's not a snippet.  All the  tags, even
> > > > those with defaults built into Lift, are implemented as snippets and
> > > > are invoked with normal snippet invocation mechanisms.
>
> > > > That you will nest your snippet inside a special snippet?
>
> > > > There is no special snippet.  I used the word "normal" to highlight
> > > > that it's functionality that doesn't require a change to LiftSession
> > > > or other parts of Lift to function correctly.
>
> > > > To me it seems worthwhile to have a consistency between the two
> > > > syntax-wise, since they have some common denominator semantics-wise.
> > > > Actually, maybe throw in eager_eval to the mix. Maybe we could have
> > > > one eval or lift:eval or liftx:eval or whatever attribute, which can
> > > > contain a space separated list of specifiers--eager, ajax, parellel.
>
> > > > Anything that's prefixed with lift: is a snippet.  I'm open to
> > > > unifying eager_eval and do:lazy (or do:par or do:parallel) into a
> > > > unified namespace.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim <
> > > naftoli...@gmail.com
> > > > >wrote:
>
> > > > > A snippet attribute can be invoked with something other than
> > > > > lift:snippet="Class.method"? There's a short syntax? What is it?
>
> > > > There may be a short syntax (e.g., lift:Class.method) in the future.
>
> > > > > What was used for the feature that inserts a snippet
> > > > asynchronously via
> > > > > Ajax?
>
> > > > That feature isn't done yet, but that feature is likely to be done
> > > > as a
> > > > normal snippet.
>
> > > > > My concern is that as more features are thought up and added they
> > > > shouldn't
> > > > > all end up with different prefixes.
> > > > > Also, if the prefix is nothing special I would go with the more
> > > > verbose
> > > > > "parallel" because otherwise it's not obvious what it does. If
> > > > it's prefixed
> > > > > with "lift:" at least you know it's a lift tag and you can look it
> > > > up
> > > > > somewhere or ask on the list etc. But if you come back to some old
> > > > template
> > > > > that says "do:par" you may be left clueless.
>
> > > > > --

[Lift] Re: Can we deploy lift webapp on Google App Engine?

[Randinn]

Try http://github.com/ymnk/lift-gae-jdo for a example, personally I
don't care for the limited approach GEA gives you, but that's me

On Sep 30, 9:22 am, Sury  wrote:
> Thanks a lot ;-)
>
> On 29 Sep 2009, at 06:54 PM, TylerWeir  wrote:
>
>
>
> > google for "lift appengine" there a few out there.
>
> > On Sep 29, 11:05 am, justss  wrote:
> >> Great TylerWeir!!! Thanks a lot... Can you please suggest any kind of
> >> documentation for this... sorry to be bothering you for that. Any
> >> tutorial would be of great help.
>
> >> Cheers.
>
> >> On Sep 29, 2:08 pm, TylerWeir  wrote:
>
> >>>http://lift-example.appspot.com
>
> >>> There are caveats though, the major one is the lack of actors.
>
> >>> On Sep 29, 8:53 am, justss  wrote:
>
>  Hi All,
>
>  I'm brand new to Scala and lift framework. I have created a very
>  simple hello world web app in lift framework and deployed it
>  successfully on tomcat.
>  Now I want to know whether I can deploy the same lift application  
>  on
>  Google app engine or not? I have the war ready, so in I thought  
>  that
>  it should have been as simple as deploying any war on tomcat or
>  websphere!!! But I see it is not ;-(
>  Can anyone please guide me as to how I can deploy my mini lift  
>  app on
>  GAE?
>
>  Thanks in advance.
>  A Newbie
--~--~-~--~~~---~--~~
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: Concurrent Web Service Requests?

[Naftoli Gugenheim]

So what is your proposal? Am I interpreting you correctly that you are for a 
prefix of 'lift'? And it will be a reserved suffix?

-
marius d. wrote:


I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.

But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.

Br's,
Marius

On Sep 25, 12:02 pm, David Pollak 
wrote:
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
> wrote:
>
>
>
> > If you like the idea of having them all as attributes but don't like the
> > idea of using a single attribute ('xx:eager_eval="true" xx:parallel="true"'
> > rather than 'xx:eval="eager parallel"' as I suggested, where xx is the
> > prefix to be chosen) then maybe the prefix should be 'eval'.
>
> I've changed the code to:
> liftx:eager_eval="true"
> liftx:par="true" | liftx:parallel="true"
>
> The reasons for not combining them:
>
>    - They are evaluated in different parts of the code, thus eager/parallel
>    doesn't make sense from a code path perspective
>    - I am reserving the value of liftx:par for future implementation to
>    allow farming the snippet evaluation to another mechanism.  Right now, it's
>    hard-coded to use LiftActors.  I can see a time when it would work with 
> Akka
>    actors or some other parallelization mechanism
>
>
>
> > As far as "ajax evaluation" I'm not sure I'm understanding. Could you show
> > me what you're thinking?
> > If I have a snippet
> > 
> > what would be the syntax to have it inserted via ajax?
>
>  
>   
> 
>
>
>
>
>
> > -
> > Ross Mellgren wrote:
>
> > My 2 cents,
>
> > I'm not sure I'm a fan of do: namespace, though I agree it would be
> > nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
>
> > -Ross
>
> > On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
>
> > > On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > wrote:
>
> > > What do you mean by "as a normal snippet"?
>
> > > The parallel snippet processing is implemented deep inside
> > > LiftSession.  It's not a snippet.  All the  tags, even
> > > those with defaults built into Lift, are implemented as snippets and
> > > are invoked with normal snippet invocation mechanisms.
>
> > > That you will nest your snippet inside a special snippet?
>
> > > There is no special snippet.  I used the word "normal" to highlight
> > > that it's functionality that doesn't require a change to LiftSession
> > > or other parts of Lift to function correctly.
>
> > > To me it seems worthwhile to have a consistency between the two
> > > syntax-wise, since they have some common denominator semantics-wise.
> > > Actually, maybe throw in eager_eval to the mix. Maybe we could have
> > > one eval or lift:eval or liftx:eval or whatever attribute, which can
> > > contain a space separated list of specifiers--eager, ajax, parellel.
>
> > > Anything that's prefixed with lift: is a snippet.  I'm open to
> > > unifying eager_eval and do:lazy (or do:par or do:parallel) into a
> > > unified namespace.
>
> > > -
> > > David Pollak wrote:
>
> > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > >wrote:
>
> > > > A snippet attribute can be invoked with something other than
> > > > lift:snippet="Class.method"? There's a short syntax? What is it?
>
> > > There may be a short syntax (e.g., lift:Class.method) in the future.
>
> > > > What was used for the feature that inserts a snippet
> > > asynchronously via
> > > > Ajax?
>
> > > That feature isn't done yet, but that feature is likely to be done
> > > as a
> > > normal snippet.
>
> > > > My concern is that as more features are thought up and added they
> > > shouldn't
> > > > all end up with different prefixes.
> > > > Also, if the prefix is nothing special I would go with the more
> > > verbose
> > > > "parallel" because otherwise it's not obvious what it does. If
> > > it's prefixed
> > > > with "lift:" at least you know it's a lift tag and you can look it
> > > up
> > > > somewhere or ask on the list etc. But if you come back to some old
> > > template
> > > > that says "do:par" you may be left clueless.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
>
> > > > > Could that be changed to lift:concurrent or lift:par etc. (see
> > > email on
> > > > > scala-user from Marting Odersky mentioned the future use of
> > > 'seq' and
> > > > 'par'
> > > > > in concu

[Lift] Re: Concurrent Web Service Requests?

[marius d.]

I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.

But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.

Br's,
Marius

On Sep 25, 12:02 pm, David Pollak 
wrote:
> On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim 
> wrote:
>
>
>
> > If you like the idea of having them all as attributes but don't like the
> > idea of using a single attribute ('xx:eager_eval="true" xx:parallel="true"'
> > rather than 'xx:eval="eager parallel"' as I suggested, where xx is the
> > prefix to be chosen) then maybe the prefix should be 'eval'.
>
> I've changed the code to:
> liftx:eager_eval="true"
> liftx:par="true" | liftx:parallel="true"
>
> The reasons for not combining them:
>
>    - They are evaluated in different parts of the code, thus eager/parallel
>    doesn't make sense from a code path perspective
>    - I am reserving the value of liftx:par for future implementation to
>    allow farming the snippet evaluation to another mechanism.  Right now, it's
>    hard-coded to use LiftActors.  I can see a time when it would work with 
> Akka
>    actors or some other parallelization mechanism
>
>
>
> > As far as "ajax evaluation" I'm not sure I'm understanding. Could you show
> > me what you're thinking?
> > If I have a snippet
> > 
> > what would be the syntax to have it inserted via ajax?
>
>  
>   
> 
>
>
>
>
>
> > -
> > Ross Mellgren wrote:
>
> > My 2 cents,
>
> > I'm not sure I'm a fan of do: namespace, though I agree it would be
> > nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
>
> > -Ross
>
> > On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
>
> > > On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > wrote:
>
> > > What do you mean by "as a normal snippet"?
>
> > > The parallel snippet processing is implemented deep inside
> > > LiftSession.  It's not a snippet.  All the  tags, even
> > > those with defaults built into Lift, are implemented as snippets and
> > > are invoked with normal snippet invocation mechanisms.
>
> > > That you will nest your snippet inside a special snippet?
>
> > > There is no special snippet.  I used the word "normal" to highlight
> > > that it's functionality that doesn't require a change to LiftSession
> > > or other parts of Lift to function correctly.
>
> > > To me it seems worthwhile to have a consistency between the two
> > > syntax-wise, since they have some common denominator semantics-wise.
> > > Actually, maybe throw in eager_eval to the mix. Maybe we could have
> > > one eval or lift:eval or liftx:eval or whatever attribute, which can
> > > contain a space separated list of specifiers--eager, ajax, parellel.
>
> > > Anything that's prefixed with lift: is a snippet.  I'm open to
> > > unifying eager_eval and do:lazy (or do:par or do:parallel) into a
> > > unified namespace.
>
> > > -
> > > David Pollak wrote:
>
> > > On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > >wrote:
>
> > > > A snippet attribute can be invoked with something other than
> > > > lift:snippet="Class.method"? There's a short syntax? What is it?
>
> > > There may be a short syntax (e.g., lift:Class.method) in the future.
>
> > > > What was used for the feature that inserts a snippet
> > > asynchronously via
> > > > Ajax?
>
> > > That feature isn't done yet, but that feature is likely to be done
> > > as a
> > > normal snippet.
>
> > > > My concern is that as more features are thought up and added they
> > > shouldn't
> > > > all end up with different prefixes.
> > > > Also, if the prefix is nothing special I would go with the more
> > > verbose
> > > > "parallel" because otherwise it's not obvious what it does. If
> > > it's prefixed
> > > > with "lift:" at least you know it's a lift tag and you can look it
> > > up
> > > > somewhere or ask on the list etc. But if you come back to some old
> > > template
> > > > that says "do:par" you may be left clueless.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
>
> > > > > Could that be changed to lift:concurrent or lift:par etc. (see
> > > email on
> > > > > scala-user from Marting Odersky mentioned the future use of
> > > 'seq' and
> > > > 'par'
> > > > > in concurrent collections)?
> > > > > Why use a different prefix than everything else built in to
> > > lift? And
> > > > > 'lazy' is arguably not what's happening.
>
> > > > We're using a differe

[Lift] Re: Question about the Getting Started Guide

[Naftoli Gugenheim]

I had such an issue when it was confused about which version of Jetty. Is there 
any more detail? Try running with error details enabled (mvn -help should tell 
you how).

-
jlist9 wrote:


Yes, I have a network connection. Maven downloaded some other
components and the end result was BUILD SUCCESSFUL...

On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheim  wrote:
>
> Do you have a network connection? The idea of maven is that it
> downloads whatever it's missing.
>
> On Tue, Sep 29, 2009 at 9:11 PM, jlist9  wrote:
>>
>> Hi,
>>
>> I'm new to Lift. I'm trying to follow the getting started guide to
>> build the first simple
>> demo.helloworld project. At the end of Maven command output I see
>> "BUILD SUCCESSFUL".
>> However, when I run "mvn jetty:run", I get error:
>>
>> The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
>> exist or no valid version could be found
>>
>> I wonder if I need to manually install jetty? If so, is there any
>> configuration instructions?
>>
>> Thanks
>> Jack
>>
>> >
>>
>
> >
>



--~--~-~--~~~---~--~~
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: Question about the Getting Started Guide

[jlist9]

Yes, I have a network connection. Maven downloaded some other
components and the end result was BUILD SUCCESSFUL...

On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheim  wrote:
>
> Do you have a network connection? The idea of maven is that it
> downloads whatever it's missing.
>
> On Tue, Sep 29, 2009 at 9:11 PM, jlist9  wrote:
>>
>> Hi,
>>
>> I'm new to Lift. I'm trying to follow the getting started guide to
>> build the first simple
>> demo.helloworld project. At the end of Maven command output I see
>> "BUILD SUCCESSFUL".
>> However, when I run "mvn jetty:run", I get error:
>>
>> The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
>> exist or no valid version could be found
>>
>> I wonder if I need to manually install jetty? If so, is there any
>> configuration instructions?
>>
>> Thanks
>> Jack
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Bill Venners]

Hi Josh,

I don't think it is such a bad sign that multiple actor libraries are
popping up. There isn't one way to write actors. There are many. List
seems to create lots of very short-lived actors if I have understood
that correctly. Nothing wrong with that, but it doesn't mean that all
implementations of the actor concept must absolutely support that use
case. Some actors can be tuned to be short lived creatures, others
designed for more stable, longer lives. Some actors can be designed
primarily for being in one VM, others for existing in distributed
systems, etc. Scala's focus on letting people design things in
libraries is exactly why it is possible to do multiple actor designs.
In Erlang it might not be as easy.

That said, it would be nice to get the memory leak problem solved in
Scala actors, and I'm confident that will happen eventually. But I use
one simple Scala actor in ScalaTest and it works just fine for my use
case, which is to collect events fired during parallel runs, serialize
them, and report them in various ways. There's just one actor for each
ScalaTest run, so I have no memory leak problem. I probably will
remove that actor eventually though, not because of any problems with
the implementation but just because I suspect it isn't the best fit
performance-wise.

Bill
On Tue, Sep 29, 2009 at 7:37 PM, Josh Suereth  wrote:
> As much as I agree with your decision, it just makes me sad.   I know lots
> of people that learned scala for "actors are the way of the future" I
> think we need to push harder.  Hopefully all major projects migrating off
> actors will give EPFL a wake up call?
>
> - Josh
>
> On Tue, Sep 29, 2009 at 1:41 PM, David Pollak
>  wrote:
>>
>>
>> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck 
>> wrote:
>>>
>>> Apologies if I've missed something obvious but my web search hasn't
>>> turned anything up...
>>>
>>> What are the Scala Actors instability issues? I'm in the process of
>>> doing some major Scala development work and this comment raises
>>> concerns that I'd like to understand.
>>
>> The issues (with the Scala Actors in general and Lift's use of them) are:
>>
>> Scala Actors use a custom version of Doug Leah's Fork/Join library.  This
>> was necessary for JDK 1.4 support.  With JDK 1.5, the java.util.concurrent
>> stuff should have been used.  I was led to understand that this change was
>> made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still
>> contains fork-join.  The FJ library has a memory retention issue where it
>> trades memory for non-locking performance and, with many threads in a
>> thread-pool, this leads to out of memory issues.
>> The Scala Actor code is very brittle.
>>  See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
>>  The code has not been materially refactored, which means that even in 2.8,
>> there will be significant potential problems with the Actors.  Those
>> potential problems have manifest themselves as real problems in 2.7.x.  I
>> have spent in aggregate nearly 3 weeks of my time since November 2008
>> working around the defects in the Actor library.  It's easier to have our
>> own Actors (the current Actor library is about 2 days of work on my part and
>> the refactoring of Lift to work with the existing Actor library is another 2
>> days of work.)
>> EPFL has been generally slow to respond to bug reports.  I am very
>> frustrated and quite frankly tired of having to cajole EPFL into responding
>> to defects in one of the premier Scala libraries.
>>
>> I would strongly suggest that you look at Akka.  It's got a better view
>> and implementation of Actors than does the standard Scala distribution. Akka
>> includes support for distributed actors, etc.
>> Hope this helps.
>>
>>>
>>> Best,
>>>
>>> Stuart
>>>
>>> On Sep 29, 3:30 am, David Pollak 
>>> wrote:
>>> > Folks,
>>> >
>>> > Given the continued instability of Scala Actors, I've decided to remove
>>> > them
>>> > from Lift.
>>> >
>>> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
>>> > But, you'll also be able to use Akka Actors to power Lift's
>>> > CometActors.
>>> > Specifically, I'm working with Jonas to make sure that we share a
>>> > common
>>> > interface to Actors.
>>> >
>>> > I've gotten Lift nearly completely migrated over to Lift's Actors on
>>> > the
>>> > dpp_wip_actorize branch.
>>> >  Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>> >
>>> > There will be some breaking changes to your applications.
>>> >  Specifically:
>>> >
>>> >    - Box will be moved to a new package, net.liftweb.base (this is
>>> > where the
>>> >    interface for Actors will live as well)
>>> >    - If you make any assumptions about your CometActors being Scala
>>> > Actors
>>> >    (e.g., using linking), you will have to rewrite this code
>>> >    - Some methods in Lift that currently take Scala Actors as
>>> > parameters
>>> >    will take Lift Actors (e.g., ActorPing)
>>> >
>>> > There will be a parallel Maven r

[Lift] Re: Question about the Getting Started Guide

[Naftoli Gugenheim]

Do you have a network connection? The idea of maven is that it
downloads whatever it's missing.

On Tue, Sep 29, 2009 at 9:11 PM, jlist9  wrote:
>
> Hi,
>
> I'm new to Lift. I'm trying to follow the getting started guide to
> build the first simple
> demo.helloworld project. At the end of Maven command output I see
> "BUILD SUCCESSFUL".
> However, when I run "mvn jetty:run", I get error:
>
> The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
> exist or no valid version could be found
>
> I wonder if I need to manually install jetty? If so, is there any
> configuration instructions?
>
> Thanks
> Jack
>
> >
>

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Naftoli Gugenheim]

Hmmm. I still think that given lift-common and lift-util, lift-common
is more "core" sounding than lift-util...
Maybe lift-helpers?

On Tue, Sep 29, 2009 at 11:14 PM, marius d.  wrote:
>
> I'd vote for:
>
> lift-common instead of lift-base. lift-base can be easily
> misinterpreted as lift's base traits and classes? ... which is not the
> case. This can hold, Box, comb parsers (JSON, VCard etc), liftactors
> etc.
>
> lift-util - things that are in the current util but lean towards web
> realm.
>
> Br's,
> Marius
>
> On Sep 29, 2:17 pm, Timothy Perrett  wrote:
>> +1 sounds like sense to me :-)
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 29 Sep 2009, at 19:20, Naftoli Gugenheim 
>> wrote:
>>
>>
>>
>> > If I was new to Lift and saw a lift-util module and a lift-base
>> > module and had to guess which did not depend on anything web
>> > related, I would probably pick lift-util without hesitation. After
>> > all, "lift" is the name of a web framework, and "lift-base" implies
>> > that it's basic but central classes etc. "lift-util" sounds like
>> > utilities that are useful to lift, even necessary, but not central
>> > to what lift is. Many libraries have a "util" that has code with
>> > broad applicability but that needed to be packaged with the library
>> > because it relies on it and it wan't worth it to get the
>> > functionality elsewhere.
>> > So if it's an option I would move the web-related functionality to
>> > lift-base and leave Box and Actor etc. in lift-util.
>>
>> > -
>> > David Pollak wrote:
>>
>> > On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger <
>> > heiko.seeber...@googlemail.com> wrote:
>>
>> >> What's the reason to have a new module (lift-base)? Why not put
>> >> Actor to
>> >> lift-util and keep Box where it is?
>>
>> > Because there are a lot of web-related things in lift-utils.  I am
>> > going to
>> > for a separate package that is far more generic.
>>
>> >> In your branch def !?(timeout: Long, param: T) will return an Option.
>> >> Shouldn't this be a Box?
>>
>> >> Heiko
>>
>> >> 2009/9/29 David Pollak 
>>
>> >> Folks,
>>
>> >>> Given the continued instability of Scala Actors, I've decided to
>> >>> remove
>> >>> them from Lift.
>>
>> >>> Specifically, I'm migrating CometActors to sit on top of Lift's
>> >>> Actors.
>> >>> But, you'll also be able to use Akka Actors to power Lift's
>> >>> CometActors.
>> >>> Specifically, I'm working with Jonas to make sure that we share a
>> >>> common
>> >>> interface to Actors.
>>
>> >>> I've gotten Lift nearly completely migrated over to Lift's Actors
>> >>> on the
>> >>> dpp_wip_actorize branch.  See
>> >>>http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>
>> >>> There will be some breaking changes to your applications.
>> >>> Specifically:
>>
>> >>>   - Box will be moved to a new package, net.liftweb.base (this is
>> >>> where
>> >>>   the interface for Actors will live as well)
>> >>>   - If you make any assumptions about your CometActors being Scala
>> >>>   Actors (e.g., using linking), you will have to rewrite this code
>> >>>   - Some methods in Lift that currently take Scala Actors as
>> >>> parameters
>> >>>   will take Lift Actors (e.g., ActorPing)
>>
>> >>> There will be a parallel Maven repository with the new Lift Actor
>> >>> stuff in
>> >>> it so you will be able to build you apps against the new code
>> >>> before the
>> >>> official switch-over.
>>
>> >>> Milestone 6 (which should be out next week) will be based on the
>> >>> existing
>> >>> Actor model.  After we get feedback from the community about the
>> >>> new Actor
>> >>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>
>> >>> Questions, thoughts, or comments?
>>
>> >>> Thanks,
>>
>> >>> David
>>
>> >>> --
>> >>> Lift, the simply functional web frameworkhttp://liftweb.net
>> >>> Beginning Scalahttp://www.apress.com/book/view/1430219890
>> >>> Follow me:http://twitter.com/dpp
>> >>> Surf the harmonics
>>
>> >> --
>> >> Heiko Seeberger
>>
>> >> My job: weiglewilczek.com
>> >> My blog: heikoseeberger.name
>> >> Follow me: twitter.com/hseeberger
>> >> OSGi on Scala: scalamodules.org
>> >> Lift, the simply functional web framework: liftweb.net
>>
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Surf the harmonics
> >
>

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[marius d.]

I'd vote for:

lift-common instead of lift-base. lift-base can be easily
misinterpreted as lift's base traits and classes? ... which is not the
case. This can hold, Box, comb parsers (JSON, VCard etc), liftactors
etc.

lift-util - things that are in the current util but lean towards web
realm.

Br's,
Marius

On Sep 29, 2:17 pm, Timothy Perrett  wrote:
> +1 sounds like sense to me :-)
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 29 Sep 2009, at 19:20, Naftoli Gugenheim   
> wrote:
>
>
>
> > If I was new to Lift and saw a lift-util module and a lift-base  
> > module and had to guess which did not depend on anything web  
> > related, I would probably pick lift-util without hesitation. After  
> > all, "lift" is the name of a web framework, and "lift-base" implies  
> > that it's basic but central classes etc. "lift-util" sounds like  
> > utilities that are useful to lift, even necessary, but not central  
> > to what lift is. Many libraries have a "util" that has code with  
> > broad applicability but that needed to be packaged with the library  
> > because it relies on it and it wan't worth it to get the  
> > functionality elsewhere.
> > So if it's an option I would move the web-related functionality to  
> > lift-base and leave Box and Actor etc. in lift-util.
>
> > -
> > David Pollak wrote:
>
> > On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger <
> > heiko.seeber...@googlemail.com> wrote:
>
> >> What's the reason to have a new module (lift-base)? Why not put  
> >> Actor to
> >> lift-util and keep Box where it is?
>
> > Because there are a lot of web-related things in lift-utils.  I am  
> > going to
> > for a separate package that is far more generic.
>
> >> In your branch def !?(timeout: Long, param: T) will return an Option.
> >> Shouldn't this be a Box?
>
> >> Heiko
>
> >> 2009/9/29 David Pollak 
>
> >> Folks,
>
> >>> Given the continued instability of Scala Actors, I've decided to  
> >>> remove
> >>> them from Lift.
>
> >>> Specifically, I'm migrating CometActors to sit on top of Lift's  
> >>> Actors.
> >>> But, you'll also be able to use Akka Actors to power Lift's  
> >>> CometActors.
> >>> Specifically, I'm working with Jonas to make sure that we share a  
> >>> common
> >>> interface to Actors.
>
> >>> I've gotten Lift nearly completely migrated over to Lift's Actors  
> >>> on the
> >>> dpp_wip_actorize branch.  See
> >>>http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> >>> There will be some breaking changes to your applications.  
> >>> Specifically:
>
> >>>   - Box will be moved to a new package, net.liftweb.base (this is  
> >>> where
> >>>   the interface for Actors will live as well)
> >>>   - If you make any assumptions about your CometActors being Scala
> >>>   Actors (e.g., using linking), you will have to rewrite this code
> >>>   - Some methods in Lift that currently take Scala Actors as  
> >>> parameters
> >>>   will take Lift Actors (e.g., ActorPing)
>
> >>> There will be a parallel Maven repository with the new Lift Actor  
> >>> stuff in
> >>> it so you will be able to build you apps against the new code  
> >>> before the
> >>> official switch-over.
>
> >>> Milestone 6 (which should be out next week) will be based on the  
> >>> existing
> >>> Actor model.  After we get feedback from the community about the  
> >>> new Actor
> >>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>
> >>> Questions, thoughts, or comments?
>
> >>> Thanks,
>
> >>> David
>
> >>> --
> >>> Lift, the simply functional web frameworkhttp://liftweb.net
> >>> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >>> Follow me:http://twitter.com/dpp
> >>> Surf the harmonics
>
> >> --
> >> Heiko Seeberger
>
> >> My job: weiglewilczek.com
> >> My blog: heikoseeberger.name
> >> Follow me: twitter.com/hseeberger
> >> OSGi on Scala: scalamodules.org
> >> Lift, the simply functional web framework: liftweb.net
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Josh Suereth]

As much as I agree with your decision, it just makes me sad.   I know lots
of people that learned scala for "actors are the way of the future" I
think we need to push harder.  Hopefully all major projects migrating off
actors will give EPFL a wake up call?

- Josh

On Tue, Sep 29, 2009 at 1:41 PM, David Pollak  wrote:

>
>
> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck 
> wrote:
>
>>
>> Apologies if I've missed something obvious but my web search hasn't
>> turned anything up...
>>
>> What are the Scala Actors instability issues? I'm in the process of
>> doing some major Scala development work and this comment raises
>> concerns that I'd like to understand.
>>
>
> The issues (with the Scala Actors in general and Lift's use of them) are:
>
>- Scala Actors use a custom version of Doug Leah's Fork/Join library.
> This was necessary for JDK 1.4 support.  With JDK 1.5, the
>java.util.concurrent stuff should have been used.  I was led to understand
>that this change was made in Scala 2.7.5, but it was not and even the Scala
>2.8 stuff still contains fork-join.  The FJ library has a memory retention
>issue where it trades memory for non-locking performance and, with many
>threads in a thread-pool, this leads to out of memory issues.
>- The Scala Actor code is very brittle.  See
>http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html 
> The code has not been materially refactored, which means that even in 2.8,
>there will be significant potential problems with the Actors.  Those
>potential problems have manifest themselves as real problems in 2.7.x.  I
>have spent in aggregate nearly 3 weeks of my time since November 2008
>working around the defects in the Actor library.  It's easier to have our
>own Actors (the current Actor library is about 2 days of work on my part 
> and
>the refactoring of Lift to work with the existing Actor library is another 
> 2
>days of work.)
>- EPFL has been generally slow to respond to bug reports.  I am very
>frustrated and quite frankly tired of having to cajole EPFL into responding
>to defects in one of the premier Scala libraries.
>
> I would strongly suggest that you look at Akka.  It's got a better view and
> implementation of Actors than does the standard Scala distribution. Akka
> includes support for distributed actors, etc.
>
> Hope this helps.
>
>
>>
>> Best,
>>
>> Stuart
>>
>> On Sep 29, 3:30 am, David Pollak 
>> wrote:
>> > Folks,
>> >
>> > Given the continued instability of Scala Actors, I've decided to remove
>> them
>> > from Lift.
>> >
>> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
>> > But, you'll also be able to use Akka Actors to power Lift's CometActors.
>> > Specifically, I'm working with Jonas to make sure that we share a common
>> > interface to Actors.
>> >
>> > I've gotten Lift nearly completely migrated over to Lift's Actors on the
>> > dpp_wip_actorize branch.  Seehttp://
>> github.com/dpp/liftweb/tree/dpp_wip_actorize
>> >
>> > There will be some breaking changes to your applications.  Specifically:
>> >
>> >- Box will be moved to a new package, net.liftweb.base (this is where
>> the
>> >interface for Actors will live as well)
>> >- If you make any assumptions about your CometActors being Scala
>> Actors
>> >(e.g., using linking), you will have to rewrite this code
>> >- Some methods in Lift that currently take Scala Actors as parameters
>> >will take Lift Actors (e.g., ActorPing)
>> >
>> > There will be a parallel Maven repository with the new Lift Actor stuff
>> in
>> > it so you will be able to build you apps against the new code before the
>> > official switch-over.
>> >
>> > Milestone 6 (which should be out next week) will be based on the
>> existing
>> > Actor model.  After we get feedback from the community about the new
>> Actor
>> > stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>> >
>> > Questions, thoughts, or comments?
>> >
>> > Thanks,
>> >
>> > David
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Surf the harmonics
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
>
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>

--~--~-~--~~~---~--~~
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] Question about the Getting Started Guide

[jlist9]

Hi,

I'm new to Lift. I'm trying to follow the getting started guide to
build the first simple
demo.helloworld project. At the end of Maven command output I see
"BUILD SUCCESSFUL".
However, when I run "mvn jetty:run", I get error:

The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
exist or no valid version could be found

I wonder if I need to manually install jetty? If so, is there any
configuration instructions?

Thanks
Jack

--~--~-~--~~~---~--~~
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: Can we deploy lift webapp on Google App Engine?

[Sury]

Thanks a lot ;-)


On 29 Sep 2009, at 06:54 PM, TylerWeir  wrote:

>
> google for "lift appengine" there a few out there.
>
> On Sep 29, 11:05 am, justss  wrote:
>> Great TylerWeir!!! Thanks a lot... Can you please suggest any kind of
>> documentation for this... sorry to be bothering you for that. Any
>> tutorial would be of great help.
>>
>> Cheers.
>>
>> On Sep 29, 2:08 pm, TylerWeir  wrote:
>>
>>> http://lift-example.appspot.com
>>
>>> There are caveats though, the major one is the lack of actors.
>>
>>> On Sep 29, 8:53 am, justss  wrote:
>>
 Hi All,
>>
 I'm brand new to Scala and lift framework. I have created a very
 simple hello world web app in lift framework and deployed it
 successfully on tomcat.
 Now I want to know whether I can deploy the same lift application  
 on
 Google app engine or not? I have the war ready, so in I thought  
 that
 it should have been as simple as deploying any war on tomcat or
 websphere!!! But I see it is not ;-(
 Can anyone please guide me as to how I can deploy my mini lift  
 app on
 GAE?
>>
 Thanks in advance.
 A Newbie
>>
>>
> >

--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[Ross Mellgren]

I'm sure opinions vary, but my personal preference in general is to  
implement JavaScript in JavaScript as a linked .js file and leave the  
HTML/XML generation in the server and not mix the two terribly much  
unless it's simple or there's a compelling reason.

What do you mean by "more functional"?

-Ross

On Sep 29, 2009, at 6:23 PM, glenn wrote:

>
> Ross,
>
> I think you and I  came to same conclusion. Writing it as raw
> JavaScript, as I
> did initially, seems the only way I could find to do this. FYI, where
> I was using this
> was with the TreeView widget. There, "toggle" takes an anonymous
> function, and
> "this" is an implicit parameter, denoting the Tree selected.
>
> val func = JsRaw("""function() $('#item-save').html(this.id + ' was
> toggled')""")
> TreeView("tree", JsObj(("persist", "location"),("toggle",  func)),
> loadTree, loadNode)
>
>
> I was hoping for a more functional way to write func, in order to do
> more complex processing on the client.
>
> Glenn
>
>
>
> On Sep 29, 2:55 pm, Ross Mellgren  wrote:
>> Oh I'm sorry, I got tunnel vision and did not read the rest of your
>> code. You'll not be able to do quite what you want, since this.id is
>> on the javascript side and the NodeSeq is on the server side.
>>
>> If you really want this.id within that div, I think you'll have to
>> construct or modify the div on the JS side. I rummaged through the
>> Lift jQuery docs and I couldn't find something that will append/ 
>> inject
>> to a JQueryLeft (such as JqId) but using a JsExp and not a fixed
>> NodeSeq. This is not to say there isn't such a thing, just that I
>> couldn't find it. Of course, you can whip this up using the lower
>> level javascript stuff:
>>
>> AnonFunc(JqId("item-save") ~>
>>   JsFunc("empty") ~>
>>   JsFunc("after", Call("jQuery", " was toggled")  
>> ~>
>>   JsFunc("prepend", JsVar("this", "id"
>>
>> Of course, at that point I'd just say it might be a better idea to
>> write the JavaScript directly, since this expands to
>>
>> $("#item-save").empty().after($(" was toggled").prepend
>> (this.id));
>>
>> -Ross
>>
>> On Sep 29, 2009, at 5:22 PM, glenn wrote:
>>
>>
>>
>>> Hi, Ross,
>>
>>> Unfornately, all of these just result in:
>>
>>> function() {jQuery('#'+"item-save").empty().after("this.id was
>>> toggled");}
>>
>>> They simply treat this.id as part of the passed in NodeSeq,
>>> "this.id was toggled". I need it
>>> to output this.id + "was toggled".
>>
>>> Glenn
>>
>>> On Sep 29, 1:46 pm, Ross Mellgren  wrote:
 Try JsVar("this", "id") or JsRaw("this.id")
>>
 -Ross
>>
 On Sep 29, 2009, at 4:22 PM, glenn wrote:
>>
> I'd like to converting the following
>>
> JsRaw("""function() $('#item-save').html(this.id + ' was
> toggled')""")
>>
> into something more object-oriented, using JQuery support
> functions in
> Lift.
>>
> I've tried various combiniations, including this
>>
> AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)}  
> was
> toggled))
>>
> but nothing seems to work. It just treats this.id as ordinary  
> text,
> not as a Javascript variable.
>>
> Any ideas would be appreciated.
>>
> Glenn
> >


--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[Naftoli Gugenheim]

Maybe write javascript code that gets all its variables by calling functions. 
Then supply those functions as Lift JsXX. This way you can supply values from 
Lift but the javascript "program" is written in javascript.


-
glenn wrote:


Ross,

I think you and I  came to same conclusion. Writing it as raw
JavaScript, as I
did initially, seems the only way I could find to do this. FYI, where
I was using this
was with the TreeView widget. There, "toggle" takes an anonymous
function, and
"this" is an implicit parameter, denoting the Tree selected.

val func = JsRaw("""function() $('#item-save').html(this.id + ' was
toggled')""")
TreeView("tree", JsObj(("persist", "location"),("toggle",  func)),
loadTree, loadNode)


I was hoping for a more functional way to write func, in order to do
more complex processing on the client.

Glenn



On Sep 29, 2:55 pm, Ross Mellgren  wrote:
> Oh I'm sorry, I got tunnel vision and did not read the rest of your  
> code. You'll not be able to do quite what you want, since this.id is  
> on the javascript side and the NodeSeq is on the server side.
>
> If you really want this.id within that div, I think you'll have to  
> construct or modify the div on the JS side. I rummaged through the  
> Lift jQuery docs and I couldn't find something that will append/inject  
> to a JQueryLeft (such as JqId) but using a JsExp and not a fixed  
> NodeSeq. This is not to say there isn't such a thing, just that I  
> couldn't find it. Of course, you can whip this up using the lower  
> level javascript stuff:
>
> AnonFunc(JqId("item-save") ~>
>           JsFunc("empty") ~>
>           JsFunc("after", Call("jQuery", " was toggled") ~>
>                           JsFunc("prepend", JsVar("this", "id"
>
> Of course, at that point I'd just say it might be a better idea to  
> write the JavaScript directly, since this expands to
>
> $("#item-save").empty().after($(" was toggled").prepend
> (this.id));
>
> -Ross
>
> On Sep 29, 2009, at 5:22 PM, glenn wrote:
>
>
>
> > Hi, Ross,
>
> > Unfornately, all of these just result in:
>
> > function() {jQuery('#'+"item-save").empty().after("this.id was
> > toggled");}
>
> > They simply treat this.id as part of the passed in NodeSeq,
> > "this.id was toggled". I need it
> > to output this.id + "was toggled".
>
> > Glenn
>
> > On Sep 29, 1:46 pm, Ross Mellgren  wrote:
> >> Try JsVar("this", "id") or JsRaw("this.id")
>
> >> -Ross
>
> >> On Sep 29, 2009, at 4:22 PM, glenn wrote:
>
> >>> I'd like to converting the following
>
> >>> JsRaw("""function() $('#item-save').html(this.id + ' was
> >>> toggled')""")
>
> >>> into something more object-oriented, using JQuery support  
> >>> functions in
> >>> Lift.
>
> >>> I've tried various combiniations, including this
>
> >>> AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
> >>> toggled))
>
> >>> but nothing seems to work. It just treats this.id as ordinary text,
> >>> not as a Javascript variable.
>
> >>> Any ideas would be appreciated.
>
> >>> Glenn


--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[glenn]

Ross,

I think you and I  came to same conclusion. Writing it as raw
JavaScript, as I
did initially, seems the only way I could find to do this. FYI, where
I was using this
was with the TreeView widget. There, "toggle" takes an anonymous
function, and
"this" is an implicit parameter, denoting the Tree selected.

val func = JsRaw("""function() $('#item-save').html(this.id + ' was
toggled')""")
TreeView("tree", JsObj(("persist", "location"),("toggle",  func)),
loadTree, loadNode)


I was hoping for a more functional way to write func, in order to do
more complex processing on the client.

Glenn



On Sep 29, 2:55 pm, Ross Mellgren  wrote:
> Oh I'm sorry, I got tunnel vision and did not read the rest of your  
> code. You'll not be able to do quite what you want, since this.id is  
> on the javascript side and the NodeSeq is on the server side.
>
> If you really want this.id within that div, I think you'll have to  
> construct or modify the div on the JS side. I rummaged through the  
> Lift jQuery docs and I couldn't find something that will append/inject  
> to a JQueryLeft (such as JqId) but using a JsExp and not a fixed  
> NodeSeq. This is not to say there isn't such a thing, just that I  
> couldn't find it. Of course, you can whip this up using the lower  
> level javascript stuff:
>
> AnonFunc(JqId("item-save") ~>
>           JsFunc("empty") ~>
>           JsFunc("after", Call("jQuery", " was toggled") ~>
>                           JsFunc("prepend", JsVar("this", "id"
>
> Of course, at that point I'd just say it might be a better idea to  
> write the JavaScript directly, since this expands to
>
> $("#item-save").empty().after($(" was toggled").prepend
> (this.id));
>
> -Ross
>
> On Sep 29, 2009, at 5:22 PM, glenn wrote:
>
>
>
> > Hi, Ross,
>
> > Unfornately, all of these just result in:
>
> > function() {jQuery('#'+"item-save").empty().after("this.id was
> > toggled");}
>
> > They simply treat this.id as part of the passed in NodeSeq,
> > "this.id was toggled". I need it
> > to output this.id + "was toggled".
>
> > Glenn
>
> > On Sep 29, 1:46 pm, Ross Mellgren  wrote:
> >> Try JsVar("this", "id") or JsRaw("this.id")
>
> >> -Ross
>
> >> On Sep 29, 2009, at 4:22 PM, glenn wrote:
>
> >>> I'd like to converting the following
>
> >>> JsRaw("""function() $('#item-save').html(this.id + ' was
> >>> toggled')""")
>
> >>> into something more object-oriented, using JQuery support  
> >>> functions in
> >>> Lift.
>
> >>> I've tried various combiniations, including this
>
> >>> AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
> >>> toggled))
>
> >>> but nothing seems to work. It just treats this.id as ordinary text,
> >>> not as a Javascript variable.
>
> >>> Any ideas would be appreciated.
>
> >>> Glenn
--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[Ross Mellgren]

Oh I'm sorry, I got tunnel vision and did not read the rest of your  
code. You'll not be able to do quite what you want, since this.id is  
on the javascript side and the NodeSeq is on the server side.

If you really want this.id within that div, I think you'll have to  
construct or modify the div on the JS side. I rummaged through the  
Lift jQuery docs and I couldn't find something that will append/inject  
to a JQueryLeft (such as JqId) but using a JsExp and not a fixed  
NodeSeq. This is not to say there isn't such a thing, just that I  
couldn't find it. Of course, you can whip this up using the lower  
level javascript stuff:

AnonFunc(JqId("item-save") ~>
  JsFunc("empty") ~>
  JsFunc("after", Call("jQuery", " was toggled") ~>
  JsFunc("prepend", JsVar("this", "id"

Of course, at that point I'd just say it might be a better idea to  
write the JavaScript directly, since this expands to

$("#item-save").empty().after($(" was toggled").prepend 
(this.id));

-Ross


On Sep 29, 2009, at 5:22 PM, glenn wrote:

>
> Hi, Ross,
>
> Unfornately, all of these just result in:
>
> function() {jQuery('#'+"item-save").empty().after("this.id was
> toggled");}
>
> They simply treat this.id as part of the passed in NodeSeq,
> "this.id was toggled". I need it
> to output this.id + "was toggled".
>
> Glenn
>
>
>
>
> On Sep 29, 1:46 pm, Ross Mellgren  wrote:
>> Try JsVar("this", "id") or JsRaw("this.id")
>>
>> -Ross
>>
>> On Sep 29, 2009, at 4:22 PM, glenn wrote:
>>
>>
>>
>>> I'd like to converting the following
>>
>>> JsRaw("""function() $('#item-save').html(this.id + ' was
>>> toggled')""")
>>
>>> into something more object-oriented, using JQuery support  
>>> functions in
>>> Lift.
>>
>>> I've tried various combiniations, including this
>>
>>> AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
>>> toggled))
>>
>>> but nothing seems to work. It just treats this.id as ordinary text,
>>> not as a Javascript variable.
>>
>>> Any ideas would be appreciated.
>>
>>> Glenn
> >


--~--~-~--~~~---~--~~
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: VCard parser...

[marius d.]

Oh wow :)

Br's,
Marius

On Sep 29, 2:18 pm, "Charles F. Munat"  wrote:
> Oh, it's no problem, dude! I've been meaning to pick up a bottle of this
> Jacobsen Vintage #2 beer for a while now, but it's only available in
> Europe. Maybe you could ship me one?
>
> http://www.carlsberggroup.com/brands/Pages/Jacobsen_Vintage_no_2.aspx
>
> Chas.
> :-)
>
> marius d. wrote:
> > Hly cow !  I owe the committers more than a
> > beer. I totally forgot about review board.
>
> > All, please accept my apologies.
>
> > Br's,
> > Marius
>
> > On Sep 29, 8:27 am, Timothy Perrett  wrote:
> >> I guess we could let him off this time ;-)
>
> >> Any plans to add a vCard builder? I could really use that as it happens!
>
> >> Cheers
>
> >> Tim
>
> >> Sent from my iPhone
>
> >> On 29 Sep 2009, at 14:10, David Pollak   
> >> wrote:
>
> >>> Marius added it.  He owes the committers a beer for not going  
> >>> through review board.
> >>> On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett   wrote:
> >>> Guys,
> >>> Who added the VCard parser, who ever made the commit needs to set
> >>> there git username :-)
> >>> VCard parsing is very, very cool - are there any plans for a builder
> >>> for VCard?
> >>> Cheers, Tim
> >>> --
> >>> Lift, the simply functional web frameworkhttp://liftweb.net
> >>> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >>> Follow me:http://twitter.com/dpp
> >>> Surf the harmonics
--~--~-~--~~~---~--~~
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: VCard parser...

[marius d.]

I've looked on the diffs but I need to look into more details as these
are no trivial changes. So far I really like what I'm seeing.
Hopefully I'll have time today to do it.

Br's,
Marius

On Sep 29, 1:02 pm, David Pollak 
wrote:
> On Tue, Sep 29, 2009 at 6:50 AM, marius d.  wrote:
>
> > Hly cow !  I owe the committers more than a
> > beer. I totally forgot about review board.
>
> > All, please accept my apologies.
>
> No worries, we're getting used to the new system.  But, feel encouraged to
> reviewhttp://reviewboard.liftweb.net/r/15/
>
>
>
> > Br's,
> > Marius
>
> > On Sep 29, 8:27 am, Timothy Perrett  wrote:
> > > I guess we could let him off this time ;-)
>
> > > Any plans to add a vCard builder? I could really use that as it happens!
>
> > > Cheers
>
> > > Tim
>
> > > Sent from my iPhone
>
> > > On 29 Sep 2009, at 14:10, David Pollak 
> > > wrote:
>
> > > > Marius added it.  He owes the committers a beer for not going
> > > > through review board.
>
> > > > On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett
> >  > > > > wrote:
>
> > > > Guys,
>
> > > > Who added the VCard parser, who ever made the commit needs to set
> > > > there git username :-)
>
> > > > VCard parsing is very, very cool - are there any plans for a builder
> > > > for VCard?
>
> > > > Cheers, Tim
>
> > > > --
> > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > > Follow me:http://twitter.com/dpp
> > > > Surf the harmonics
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[Naftoli Gugenheim]

Well the compiler is trying to convert your JsRaw into a NodeSeq, because 
that's what happens to anything inside an xml literal. It probably uses 
toString.
I can't tell you how to do it correctly because I'm not familiar with Lift's 
javascript functionality.


-
glenn wrote:


Hi, Ross,

Unfornately, all of these just result in:

function() {jQuery('#'+"item-save").empty().after("this.id was
toggled");}

They simply treat this.id as part of the passed in NodeSeq,
"this.id was toggled". I need it
to output this.id + "was toggled".

Glenn




On Sep 29, 1:46 pm, Ross Mellgren  wrote:
> Try JsVar("this", "id") or JsRaw("this.id")
>
> -Ross
>
> On Sep 29, 2009, at 4:22 PM, glenn wrote:
>
>
>
> > I'd like to converting the following
>
> > JsRaw("""function() $('#item-save').html(this.id + ' was
> > toggled')""")
>
> > into something more object-oriented, using JQuery support functions in
> > Lift.
>
> > I've tried various combiniations, including this
>
> > AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
> > toggled))
>
> > but nothing seems to work. It just treats this.id as ordinary text,
> > not as a Javascript variable.
>
> > Any ideas would be appreciated.
>
> > Glenn


--~--~-~--~~~---~--~~
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: Help with using JSExp and JsCmd traits

[glenn]

Hi, Ross,

Unfornately, all of these just result in:

function() {jQuery('#'+"item-save").empty().after("this.id was
toggled");}

They simply treat this.id as part of the passed in NodeSeq,
"this.id was toggled". I need it
to output this.id + "was toggled".

Glenn




On Sep 29, 1:46 pm, Ross Mellgren  wrote:
> Try JsVar("this", "id") or JsRaw("this.id")
>
> -Ross
>
> On Sep 29, 2009, at 4:22 PM, glenn wrote:
>
>
>
> > I'd like to converting the following
>
> > JsRaw("""function() $('#item-save').html(this.id + ' was
> > toggled')""")
>
> > into something more object-oriented, using JQuery support functions in
> > Lift.
>
> > I've tried various combiniations, including this
>
> > AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
> > toggled))
>
> > but nothing seems to work. It just treats this.id as ordinary text,
> > not as a Javascript variable.
>
> > Any ideas would be appreciated.
>
> > Glenn
--~--~-~--~~~---~--~~
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: Code Plugability in Lift

[Timothy Perrett]

In that case, why don't we just take the largest common denominator  
and go for market appeal? Is it Hibernate?

I'm just thinking some support - even vendor specifc - is better than  
no support.

Cheers, Tim

Sent from my iPhone

On 29 Sep 2009, at 21:55, Derek Chen-Becker   
wrote:

> Well, the issue is that JPA doesn't have a vendor-neutral API for  
> configuring the persistence unit other than XML or annotations, so  
> anything we do is going to be vendor-specific. We may be able to  
> provide an EclipseLink, Hibernate, JPEX, etc driver for Record that  
> ties in, but it's going to unique to each impl.
>
> Derek
>
> On Tue, Sep 29, 2009 at 9:21 AM, glenn  wrote:
>
> If you want to keep to a JPA standard, I believe EclipseLink, the
> former toplink, is the
> defacto standard API for that. Keep Hibernate, and any of the other
> varieties, out of it.
> In fact, if you stick to just the JPA stuff in EclipseLink, and don't
> use any of the
> extras, then Hibernate can use it, just fine.
>
> Glenn
>
> On Sep 28, 11:01 am, Derek Chen-Becker  wrote:
> > It's a really ugly corner that JPA paints us into here. There  
> aren't any
> > vendor-neutral APIs for programmatically wiring entities up, so  
> it's going
> > to have to be some sort of trickery.
> >
> > On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett  
> wrote:
> >
> > > Are you feeling OK david? For a moment I thought you said  
> *runtime*
> > > bytecode generation?!
> >
> > > Cheers, Tim
> >
> > > On 25 Sep 2009, at 23:06, David Pollak wrote:
> >
> > > I've been thinking about vomitting (I mean creating) bytecode at  
> runtime
> > > that creates a mock class for Hibernate consumption.
> >
> > > On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker  
> wrote:
> >
> > >> I've been thinking about it in the back of my head. I may be  
> able to get
> > >> something working that's vendor specific (e.g. Hibernate) by  
> using their
> > >> internal API to have the Record+JPA driver wire up the entities  
> at runtime
> > >> based on Record metadata. Feels kinda dirty, but if it works  
> that would be
> > >> great.
> >
> > >> Derek
> >
> > >> On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett  
>  > >> > wrote:
> >
> > >>> I know we've discussed this before, but ultimately we'd like  
> to wrap
> > >>> JPA with a Record front end somehow...
> >
> > >>> Cheers, Tim
> >
> > >>> On Sep 21, 10:42 pm, David Pollak  
> 
> > >>> wrote:
> > >>> > On Mon, Sep 21, 2009 at 2:03 PM, glenn   
> wrote:
> >
> > >>> > > David,
> >
> > >>> > > Does this mean you could write an entity class, like so:
> >
> > >>> > > class User(val firstName: String, val lastName: String,  
> val userName:
> > >>> > > String, val email: String, val password: String) with  
> myTrait {...}
> >
> > >>> > > and it would be useable in either a JPA or mapper or record
> > >>> > > implementation?
> >
> > >>> > No.  Mapper/Record require a richer representation of fields  
> than
> > >>> Pojos.
> > >>> >  The reason for this can be found athttp://
> > >>> blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning- 
> w...
> >
> > >>> > > That would be the ticket.
> >
> > >>> > > Glenn
> >
> > >>> > > On Sep 21, 12:47 pm, David Pollak  
> 
> > >>> > > wrote:
> > >>> > > > This is an impedance mis-match between POJOs (what JPA  
> expects) and
> > >>> the
> > >>> > > > richer fields that Mapper and Record have.
> > >>> > > > I'm working on an interface (
> >
> > >>>http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne 
> ..
> > >>> .)
> > >>> > > > that should be a base trait on everything in Lift that's  
> gettable
> > >>> or
> > >>> > > > gettable/settable.
> >
> > >>> > > > Then you could write a trait that looks like:
> >
> > >>> > > > trait MyThing {  def name: PSettableValueHolder[String]
> > >>> > > > *
> > >>> > > > *
> > >>> > > > * def getName(): String = name.is*
> > >>> > > > * def setName(in: String) = name.set(in)*
> > >>> > > > *
> > >>> > > > *
> > >>> > > > * *
> >
> > >>> > > > }
> >
> > >>> > > > Such a trait should be able to bridge a JPA  
> implementation and a
> > >>> Lift
> > >>> > > mapper
> > >>> > > > implementation.
> >
> > >>> > > > If you've got a better solution, please code it up and  
> let's talk
> > >>> about
> > >>> > > it.
> >
> > >>> > > > On Mon, Sep 21, 2009 at 9:31 AM, glenn  
>  wrote:
> >
> > >>> > > > > Forgive me. I'm bringing up the subject of  
> modularization in Lift
> > >>> > > > > under a new heading, but the last discussion was,  
> sadly, all over
> > >>> the
> > >>> > > > > map and only served to emphasize the problem. So let  
> me narrow it
> > >>> > > > > down, a bit, here, and ask:
> >
> > >>> > > > > How is it possible to create two different snippet
> > >>> implementations, or
> > >>> > > > > two different models, one JPA and one not, or one  
> using the
> > >>> mapper
> > >>> > > > > framework and another the record, and replace one with  
> the other
> > >>> > > > > without having to recompile the application?
> >

[Lift] Re: Code Plugability in Lift

[Derek Chen-Becker]

Well, the issue is that JPA doesn't have a vendor-neutral API for
configuring the persistence unit other than XML or annotations, so anything
we do is going to be vendor-specific. We may be able to provide an
EclipseLink, Hibernate, JPEX, etc driver for Record that ties in, but it's
going to unique to each impl.

Derek

On Tue, Sep 29, 2009 at 9:21 AM, glenn  wrote:

>
> If you want to keep to a JPA standard, I believe EclipseLink, the
> former toplink, is the
> defacto standard API for that. Keep Hibernate, and any of the other
> varieties, out of it.
> In fact, if you stick to just the JPA stuff in EclipseLink, and don't
> use any of the
> extras, then Hibernate can use it, just fine.
>
> Glenn
>
> On Sep 28, 11:01 am, Derek Chen-Becker  wrote:
> > It's a really ugly corner that JPA paints us into here. There aren't any
> > vendor-neutral APIs for programmatically wiring entities up, so it's
> going
> > to have to be some sort of trickery.
> >
> > On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett  >wrote:
> >
> > > Are you feeling OK david? For a moment I thought you said *runtime*
> > > bytecode generation?!
> >
> > > Cheers, Tim
> >
> > > On 25 Sep 2009, at 23:06, David Pollak wrote:
> >
> > > I've been thinking about vomitting (I mean creating) bytecode at
> runtime
> > > that creates a mock class for Hibernate consumption.
> >
> > > On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker <
> dchenbec...@gmail.com>wrote:
> >
> > >> I've been thinking about it in the back of my head. I may be able to
> get
> > >> something working that's vendor specific (e.g. Hibernate) by using
> their
> > >> internal API to have the Record+JPA driver wire up the entities at
> runtime
> > >> based on Record metadata. Feels kinda dirty, but if it works that
> would be
> > >> great.
> >
> > >> Derek
> >
> > >> On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett
>  > >> > wrote:
> >
> > >>> I know we've discussed this before, but ultimately we'd like to wrap
> > >>> JPA with a Record front end somehow...
> >
> > >>> Cheers, Tim
> >
> > >>> On Sep 21, 10:42 pm, David Pollak 
> > >>> wrote:
> > >>> > On Mon, Sep 21, 2009 at 2:03 PM, glenn  wrote:
> >
> > >>> > > David,
> >
> > >>> > > Does this mean you could write an entity class, like so:
> >
> > >>> > > class User(val firstName: String, val lastName: String, val
> userName:
> > >>> > > String, val email: String, val password: String) with myTrait
> {...}
> >
> > >>> > > and it would be useable in either a JPA or mapper or record
> > >>> > > implementation?
> >
> > >>> > No.  Mapper/Record require a richer representation of fields than
> > >>> Pojos.
> > >>> >  The reason for this can be found athttp://
> > >>> blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w...
> >
> > >>> > > That would be the ticket.
> >
> > >>> > > Glenn
> >
> > >>> > > On Sep 21, 12:47 pm, David Pollak  >
> > >>> > > wrote:
> > >>> > > > This is an impedance mis-match between POJOs (what JPA expects)
> and
> > >>> the
> > >>> > > > richer fields that Mapper and Record have.
> > >>> > > > I'm working on an interface (
> >
> > >>>http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne
> ..
> > >>> .)
> > >>> > > > that should be a base trait on everything in Lift that's
> gettable
> > >>> or
> > >>> > > > gettable/settable.
> >
> > >>> > > > Then you could write a trait that looks like:
> >
> > >>> > > > trait MyThing {  def name: PSettableValueHolder[String]
> > >>> > > > *
> > >>> > > > *
> > >>> > > > * def getName(): String = name.is*
> > >>> > > > * def setName(in: String) = name.set(in)*
> > >>> > > > *
> > >>> > > > *
> > >>> > > > * *
> >
> > >>> > > > }
> >
> > >>> > > > Such a trait should be able to bridge a JPA implementation and
> a
> > >>> Lift
> > >>> > > mapper
> > >>> > > > implementation.
> >
> > >>> > > > If you've got a better solution, please code it up and let's
> talk
> > >>> about
> > >>> > > it.
> >
> > >>> > > > On Mon, Sep 21, 2009 at 9:31 AM, glenn 
> wrote:
> >
> > >>> > > > > Forgive me. I'm bringing up the subject of modularization in
> Lift
> > >>> > > > > under a new heading, but the last discussion was, sadly, all
> over
> > >>> the
> > >>> > > > > map and only served to emphasize the problem. So let me
> narrow it
> > >>> > > > > down, a bit, here, and ask:
> >
> > >>> > > > > How is it possible to create two different snippet
> > >>> implementations, or
> > >>> > > > > two different models, one JPA and one not, or one using the
> > >>> mapper
> > >>> > > > > framework and another the record, and replace one with the
> other
> > >>> > > > > without having to recompile the application?
> >
> > >>> > > > > We're not talking here about interface design - you still
> have to
> > >>> deal
> > >>> > > > > with boot.  And traits, as has been suggested by
> others...well,
> > >>> you'd
> > >>> > > > > better not expose them to the world outside your
> implementation,
> > >>> as
> > >>> > > > > any changes would require recompilation. In other words, yo

[Lift] Re: Help with using JSExp and JsCmd traits

[Ross Mellgren]

Try JsVar("this", "id") or JsRaw("this.id")

-Ross

On Sep 29, 2009, at 4:22 PM, glenn wrote:

>
> I'd like to converting the following
>
> JsRaw("""function() $('#item-save').html(this.id + ' was
> toggled')""")
>
> into something more object-oriented, using JQuery support functions in
> Lift.
>
> I've tried various combiniations, including this
>
> AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
> toggled))
>
> but nothing seems to work. It just treats this.id as ordinary text,
> not as a Javascript variable.
>
> Any ideas would be appreciated.
>
> Glenn
> >


--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Jonas Bonér]

2009/9/29 Heiko Seeberger :
> What's the reason to have a new module (lift-base)? Why not put Actor to
> lift-util and keep Box where it is?
> In your branch def !?(timeout: Long, param: T) will return an Option.
> Shouldn't this be a Box?

We are trying to find a common interface for the Actors to work with
both lift-actors and akka actors.
Akka is not using Box but Option.

> Heiko
>
> 2009/9/29 David Pollak 
>>
>> Folks,
>>
>> Given the continued instability of Scala Actors, I've decided to remove
>> them from Lift.
>>
>> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
>> But, you'll also be able to use Akka Actors to power Lift's CometActors.
>> Specifically, I'm working with Jonas to make sure that we share a common
>> interface to Actors.
>>
>> I've gotten Lift nearly completely migrated over to Lift's Actors on the
>> dpp_wip_actorize branch.  See
>> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>
>> There will be some breaking changes to your applications.  Specifically:
>>
>> Box will be moved to a new package, net.liftweb.base (this is where the
>> interface for Actors will live as well)
>> If you make any assumptions about your CometActors being Scala Actors
>> (e.g., using linking), you will have to rewrite this code
>> Some methods in Lift that currently take Scala Actors as parameters will
>> take Lift Actors (e.g., ActorPing)
>>
>> There will be a parallel Maven repository with the new Lift Actor stuff in
>> it so you will be able to build you apps against the new code before the
>> official switch-over.
>>
>> Milestone 6 (which should be out next week) will be based on the existing
>> Actor model.  After we get feedback from the community about the new Actor
>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>
>> Questions, thoughts, or comments?
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>>
>
>
>
> --
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> >
>



-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org

--~--~-~--~~~---~--~~
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] Help with using JSExp and JsCmd traits

[glenn]

I'd like to converting the following

JsRaw("""function() $('#item-save').html(this.id + ' was
toggled')""")

into something more object-oriented, using JQuery support functions in
Lift.

I've tried various combiniations, including this

AnonFunc(JqId("item-save") >> JqEmptyAfter({JsRaw(this.id)} was
toggled))

but nothing seems to work. It just treats this.id as ordinary text,
not as a Javascript variable.

Any ideas would be appreciated.

Glenn
--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Naftoli Gugenheim]

It's true that technically it's not backward compatible, but how many users add 
lift-util as a dependency manually? If you only have lift-core as a dependency 
then as long as its dependencies are correct the user will get the jars he 
needs. Although that only helps maven-wise, not for package names.
Also, what will be with Helpers? It mixes a lot of things. Since Helpers 
depends on things like BindHelpers it would have to go in the web-related 
package which can depend on the generic package. From there it could mix in 
things from both packages. Someone not writing a web ap could use the 
individual relevant helpers.
Both Box and Helpers are very common imports from util, but I think that if one 
has to go, compatibility also prefers moving Helpers because although common, 
I'd assume Box is even more common.
With 2.8 there's a way to move packages without breaking compatibility though.



-
Indrajit Raychaudhuri wrote:


+1, more so because other apps not using much of lift 'web'by stuff 
could use this too.

Couple of options:
1. lift-common (along the lines of Jakarta Commons - not intuitive, but 
Java developers used to Jakarta Commons would be able to relate)

2. Actually naming lift-base as lift-util and lift-util as something 
else. This is backward incompatible though, but then again this is 
bleeding edge SNAPSHOT afterall :-P

3. Something else that's better ?

Cheers, Indrajit


On 29/09/09 11:38 PM, Timothy Perrett wrote:
>
> OK - that I can understand.
>
> Could I suggest however that we find a different name? Both myself and
> Marius were a little confused by that - nothing springs to mind, but
> perhaps lets bounce around some names.
>
> Cheers, Tim
>
> On 29 Sep 2009, at 18:41, David Pollak wrote:
>
>> lift-util is weighted very much toward web development.  lift-base
>> will be generic.
>>
>
>
> >



--~--~-~--~~~---~--~~
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] selecting random rows from a table

[harryh]

Let's say I want 10 random users from a table In SQL I would do this:

SELECT * FROM users ORDER BY random() LIMIT 10;

Is there any way (without resorting to a fully raw SQL query) to do
this with lift-mapper?  I though this would work:

Users.findAll(OrderBySql("random()", IHaveValidatedThisSQL("harryh",
"2009-9-29")),
  MaxRows(10))

This does not work, however, because when using SELECT DISTINCT you
can't ORDER BY something that you aren't selecting (in PostgreSQL at
least, might be ok in MySQL).

-harryh
--~--~-~--~~~---~--~~
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: VCard parser...

[Charles F. Munat]

Oh, it's no problem, dude! I've been meaning to pick up a bottle of this 
Jacobsen Vintage #2 beer for a while now, but it's only available in 
Europe. Maybe you could ship me one?

http://www.carlsberggroup.com/brands/Pages/Jacobsen_Vintage_no_2.aspx

Chas.
:-)

marius d. wrote:
> Hly cow !  I owe the committers more than a
> beer. I totally forgot about review board.
> 
> All, please accept my apologies.
> 
> Br's,
> Marius
> 
> On Sep 29, 8:27 am, Timothy Perrett  wrote:
>> I guess we could let him off this time ;-)
>>
>> Any plans to add a vCard builder? I could really use that as it happens!
>>
>> Cheers
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 29 Sep 2009, at 14:10, David Pollak   
>> wrote:
>>
>>> Marius added it.  He owes the committers a beer for not going  
>>> through review board.
>>> On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett >>> wrote:
>>> Guys,
>>> Who added the VCard parser, who ever made the commit needs to set
>>> there git username :-)
>>> VCard parsing is very, very cool - are there any plans for a builder
>>> for VCard?
>>> Cheers, Tim
>>> --
>>> Lift, the simply functional web frameworkhttp://liftweb.net
>>> Beginning Scalahttp://www.apress.com/book/view/1430219890
>>> Follow me:http://twitter.com/dpp
>>> Surf the harmonics
> > 
> 

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Timothy Perrett]

+1 sounds like sense to me :-)

Cheers, Tim

Sent from my iPhone

On 29 Sep 2009, at 19:20, Naftoli Gugenheim   
wrote:

>
> If I was new to Lift and saw a lift-util module and a lift-base  
> module and had to guess which did not depend on anything web  
> related, I would probably pick lift-util without hesitation. After  
> all, "lift" is the name of a web framework, and "lift-base" implies  
> that it's basic but central classes etc. "lift-util" sounds like  
> utilities that are useful to lift, even necessary, but not central  
> to what lift is. Many libraries have a "util" that has code with  
> broad applicability but that needed to be packaged with the library  
> because it relies on it and it wan't worth it to get the  
> functionality elsewhere.
> So if it's an option I would move the web-related functionality to  
> lift-base and leave Box and Actor etc. in lift-util.
>
>
> -
> David Pollak wrote:
>
> On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger <
> heiko.seeber...@googlemail.com> wrote:
>
>> What's the reason to have a new module (lift-base)? Why not put  
>> Actor to
>> lift-util and keep Box where it is?
>
>
> Because there are a lot of web-related things in lift-utils.  I am  
> going to
> for a separate package that is far more generic.
>
>
>>
>> In your branch def !?(timeout: Long, param: T) will return an Option.
>> Shouldn't this be a Box?
>>
>> Heiko
>>
>> 2009/9/29 David Pollak 
>>
>> Folks,
>>>
>>> Given the continued instability of Scala Actors, I've decided to  
>>> remove
>>> them from Lift.
>>>
>>> Specifically, I'm migrating CometActors to sit on top of Lift's  
>>> Actors.
>>> But, you'll also be able to use Akka Actors to power Lift's  
>>> CometActors.
>>> Specifically, I'm working with Jonas to make sure that we share a  
>>> common
>>> interface to Actors.
>>>
>>> I've gotten Lift nearly completely migrated over to Lift's Actors  
>>> on the
>>> dpp_wip_actorize branch.  See
>>> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>>
>>> There will be some breaking changes to your applications.   
>>> Specifically:
>>>
>>>   - Box will be moved to a new package, net.liftweb.base (this is  
>>> where
>>>   the interface for Actors will live as well)
>>>   - If you make any assumptions about your CometActors being Scala
>>>   Actors (e.g., using linking), you will have to rewrite this code
>>>   - Some methods in Lift that currently take Scala Actors as  
>>> parameters
>>>   will take Lift Actors (e.g., ActorPing)
>>>
>>> There will be a parallel Maven repository with the new Lift Actor  
>>> stuff in
>>> it so you will be able to build you apps against the new code  
>>> before the
>>> official switch-over.
>>>
>>> Milestone 6 (which should be out next week) will be based on the  
>>> existing
>>> Actor model.  After we get feedback from the community about the  
>>> new Actor
>>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>>
>>> Questions, thoughts, or comments?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>>
>>>
>>
>>
>> --
>> Heiko Seeberger
>>
>> My job: weiglewilczek.com
>> My blog: heikoseeberger.name
>> Follow me: twitter.com/hseeberger
>> OSGi on Scala: scalamodules.org
>> Lift, the simply functional web framework: liftweb.net
>>
>>>
>>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Rick R]

lift-webutil


On Tue, Sep 29, 2009 at 2:11 PM, David Pollak  wrote:

>
>
> On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett  > wrote:
>
>>
>> OK - that I can understand.
>>
>> Could I suggest however that we find a different name? Both myself and
>> Marius were a little confused by that - nothing springs to mind, but
>> perhaps lets bounce around some names.
>>
>
> Sure.  Now's the time.  In a week or so, I want to get the naming and the
> interfaces clean so people something stable to code against.
>
>
>>
>> Cheers, Tim
>>
>> On 29 Sep 2009, at 18:41, David Pollak wrote:
>>
>> > lift-util is weighted very much toward web development.  lift-base
>> > will be generic.
>> >
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Naftoli Gugenheim]

If I was new to Lift and saw a lift-util module and a lift-base module and had 
to guess which did not depend on anything web related, I would probably pick 
lift-util without hesitation. After all, "lift" is the name of a web framework, 
and "lift-base" implies that it's basic but central classes etc. "lift-util" 
sounds like utilities that are useful to lift, even necessary, but not central 
to what lift is. Many libraries have a "util" that has code with broad 
applicability but that needed to be packaged with the library because it relies 
on it and it wan't worth it to get the functionality elsewhere.
So if it's an option I would move the web-related functionality to lift-base 
and leave Box and Actor etc. in lift-util. 


-
David Pollak wrote:

On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> What's the reason to have a new module (lift-base)? Why not put Actor to
> lift-util and keep Box where it is?


Because there are a lot of web-related things in lift-utils.  I am going to
for a separate package that is far more generic.


>
> In your branch def !?(timeout: Long, param: T) will return an Option.
> Shouldn't this be a Box?
>
> Heiko
>
> 2009/9/29 David Pollak 
>
> Folks,
>>
>> Given the continued instability of Scala Actors, I've decided to remove
>> them from Lift.
>>
>> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
>> But, you'll also be able to use Akka Actors to power Lift's CometActors.
>> Specifically, I'm working with Jonas to make sure that we share a common
>> interface to Actors.
>>
>> I've gotten Lift nearly completely migrated over to Lift's Actors on the
>> dpp_wip_actorize branch.  See
>> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>
>> There will be some breaking changes to your applications.  Specifically:
>>
>>- Box will be moved to a new package, net.liftweb.base (this is where
>>the interface for Actors will live as well)
>>- If you make any assumptions about your CometActors being Scala
>>Actors (e.g., using linking), you will have to rewrite this code
>>- Some methods in Lift that currently take Scala Actors as parameters
>>will take Lift Actors (e.g., ActorPing)
>>
>> There will be a parallel Maven repository with the new Lift Actor stuff in
>> it so you will be able to build you apps against the new code before the
>> official switch-over.
>>
>> Milestone 6 (which should be out next week) will be based on the existing
>> Actor model.  After we get feedback from the community about the new Actor
>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>
>> Questions, thoughts, or comments?
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>>
>>
>
>
> --
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics



--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Indrajit Raychaudhuri]

+1, more so because other apps not using much of lift 'web'by stuff 
could use this too.

Couple of options:
1. lift-common (along the lines of Jakarta Commons - not intuitive, but 
Java developers used to Jakarta Commons would be able to relate)

2. Actually naming lift-base as lift-util and lift-util as something 
else. This is backward incompatible though, but then again this is 
bleeding edge SNAPSHOT afterall :-P

3. Something else that's better ?

Cheers, Indrajit


On 29/09/09 11:38 PM, Timothy Perrett wrote:
>
> OK - that I can understand.
>
> Could I suggest however that we find a different name? Both myself and
> Marius were a little confused by that - nothing springs to mind, but
> perhaps lets bounce around some names.
>
> Cheers, Tim
>
> On 29 Sep 2009, at 18:41, David Pollak wrote:
>
>> lift-util is weighted very much toward web development.  lift-base
>> will be generic.
>>
>
>
> >

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[David Pollak]

On Tue, Sep 29, 2009 at 11:08 AM, Timothy Perrett
wrote:

>
> OK - that I can understand.
>
> Could I suggest however that we find a different name? Both myself and
> Marius were a little confused by that - nothing springs to mind, but
> perhaps lets bounce around some names.
>

Sure.  Now's the time.  In a week or so, I want to get the naming and the
interfaces clean so people something stable to code against.


>
> Cheers, Tim
>
> On 29 Sep 2009, at 18:41, David Pollak wrote:
>
> > lift-util is weighted very much toward web development.  lift-base
> > will be generic.
> >
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Timothy Perrett]

OK - that I can understand.

Could I suggest however that we find a different name? Both myself and  
Marius were a little confused by that - nothing springs to mind, but  
perhaps lets bounce around some names.

Cheers, Tim

On 29 Sep 2009, at 18:41, David Pollak wrote:

> lift-util is weighted very much toward web development.  lift-base  
> will be generic.
>


--~--~-~--~~~---~--~~
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: VCard parser...

[David Pollak]

On Tue, Sep 29, 2009 at 6:50 AM, marius d.  wrote:

>
> Hly cow !  I owe the committers more than a
> beer. I totally forgot about review board.
>
> All, please accept my apologies.
>
>
No worries, we're getting used to the new system.  But, feel encouraged to
review http://reviewboard.liftweb.net/r/15/


> Br's,
> Marius
>
> On Sep 29, 8:27 am, Timothy Perrett  wrote:
> > I guess we could let him off this time ;-)
> >
> > Any plans to add a vCard builder? I could really use that as it happens!
> >
> > Cheers
> >
> > Tim
> >
> > Sent from my iPhone
> >
> > On 29 Sep 2009, at 14:10, David Pollak 
> > wrote:
> >
> > > Marius added it.  He owes the committers a beer for not going
> > > through review board.
> >
> > > On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett
>  > > > wrote:
> >
> > > Guys,
> >
> > > Who added the VCard parser, who ever made the commit needs to set
> > > there git username :-)
> >
> > > VCard parsing is very, very cool - are there any plans for a builder
> > > for VCard?
> >
> > > Cheers, Tim
> >
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: Can we deploy lift webapp on Google App Engine?

[TylerWeir]

google for "lift appengine" there a few out there.

On Sep 29, 11:05 am, justss  wrote:
> Great TylerWeir!!! Thanks a lot... Can you please suggest any kind of
> documentation for this... sorry to be bothering you for that. Any
> tutorial would be of great help.
>
> Cheers.
>
> On Sep 29, 2:08 pm, TylerWeir  wrote:
>
> >http://lift-example.appspot.com
>
> > There are caveats though, the major one is the lack of actors.
>
> > On Sep 29, 8:53 am, justss  wrote:
>
> > > Hi All,
>
> > > I'm brand new to Scala and lift framework. I have created a very
> > > simple hello world web app in lift framework and deployed it
> > > successfully on tomcat.
> > > Now I want to know whether I can deploy the same lift application on
> > > Google app engine or not? I have the war ready, so in I thought that
> > > it should have been as simple as deploying any war on tomcat or
> > > websphere!!! But I see it is not ;-(
> > > Can anyone please guide me as to how I can deploy my mini lift app on
> > > GAE?
>
> > > Thanks in advance.
> > > A Newbie
>
>
--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[David Pollak]

On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> What's the reason to have a new module (lift-base)? Why not put Actor to
> lift-util and keep Box where it is?


Because there are a lot of web-related things in lift-utils.  I am going to
for a separate package that is far more generic.


>
> In your branch def !?(timeout: Long, param: T) will return an Option.
> Shouldn't this be a Box?
>
> Heiko
>
> 2009/9/29 David Pollak 
>
> Folks,
>>
>> Given the continued instability of Scala Actors, I've decided to remove
>> them from Lift.
>>
>> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
>> But, you'll also be able to use Akka Actors to power Lift's CometActors.
>> Specifically, I'm working with Jonas to make sure that we share a common
>> interface to Actors.
>>
>> I've gotten Lift nearly completely migrated over to Lift's Actors on the
>> dpp_wip_actorize branch.  See
>> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>
>> There will be some breaking changes to your applications.  Specifically:
>>
>>- Box will be moved to a new package, net.liftweb.base (this is where
>>the interface for Actors will live as well)
>>- If you make any assumptions about your CometActors being Scala
>>Actors (e.g., using linking), you will have to rewrite this code
>>- Some methods in Lift that currently take Scala Actors as parameters
>>will take Lift Actors (e.g., ActorPing)
>>
>> There will be a parallel Maven repository with the new Lift Actor stuff in
>> it so you will be able to build you apps against the new code before the
>> official switch-over.
>>
>> Milestone 6 (which should be out next week) will be based on the existing
>> Actor model.  After we get feedback from the community about the new Actor
>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>
>> Questions, thoughts, or comments?
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>>
>>
>
>
> --
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[David Pollak]

On Tue, Sep 29, 2009 at 12:49 AM, Timothy Perrett
wrote:

> David,
>
> I'm not 100% clear on having Box not in lift-util? Lift-util then depends
> on lift-base which appears to be dependency bloat to me
>
> I use lift-util in several non-lift apps and libs - none of those would
> need lift-actors
>

lift-util is weighted very much toward web development.  lift-base will be
generic.


>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 29 Sep 2009, at 03:30, David Pollak 
> wrote:
>
> Folks,
>
> Given the continued instability of Scala Actors, I've decided to remove
> them from Lift.
>
> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
> But, you'll also be able to use Akka Actors to power Lift's CometActors.
> Specifically, I'm working with Jonas to make sure that we share a common
> interface to Actors.
>
> I've gotten Lift nearly completely migrated over to Lift's Actors on the
> dpp_wip_actorize branch.  See
> 
> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> There will be some breaking changes to your applications.  Specifically:
>
>- Box will be moved to a new package, net.liftweb.base (this is where
>the interface for Actors will live as well)
>- If you make any assumptions about your CometActors being Scala Actors
>(e.g., using linking), you will have to rewrite this code
>- Some methods in Lift that currently take Scala Actors as parameters
>will take Lift Actors (e.g., ActorPing)
>
> There will be a parallel Maven repository with the new Lift Actor stuff in
> it so you will be able to build you apps against the new code before the
> official switch-over.
>
> Milestone 6 (which should be out next week) will be based on the existing
> Actor model.  After we get feedback from the community about the new Actor
> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>
> Questions, thoughts, or comments?
>
> Thanks,
>
> David
>
>
>
> --
> Lift, the simply functional web framework 
> http://liftweb.net
> Beginning Scala 
> http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[David Pollak]

On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck wrote:

>
> Apologies if I've missed something obvious but my web search hasn't
> turned anything up...
>
> What are the Scala Actors instability issues? I'm in the process of
> doing some major Scala development work and this comment raises
> concerns that I'd like to understand.
>

The issues (with the Scala Actors in general and Lift's use of them) are:

   - Scala Actors use a custom version of Doug Leah's Fork/Join library.
This was necessary for JDK 1.4 support.  With JDK 1.5, the
   java.util.concurrent stuff should have been used.  I was led to understand
   that this change was made in Scala 2.7.5, but it was not and even the Scala
   2.8 stuff still contains fork-join.  The FJ library has a memory retention
   issue where it trades memory for non-locking performance and, with many
   threads in a thread-pool, this leads to out of memory issues.
   - The Scala Actor code is very brittle.  See
   http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html
The code has not been materially refactored, which means that even in
2.8,
   there will be significant potential problems with the Actors.  Those
   potential problems have manifest themselves as real problems in 2.7.x.  I
   have spent in aggregate nearly 3 weeks of my time since November 2008
   working around the defects in the Actor library.  It's easier to have our
   own Actors (the current Actor library is about 2 days of work on my part and
   the refactoring of Lift to work with the existing Actor library is another 2
   days of work.)
   - EPFL has been generally slow to respond to bug reports.  I am very
   frustrated and quite frankly tired of having to cajole EPFL into responding
   to defects in one of the premier Scala libraries.

I would strongly suggest that you look at Akka.  It's got a better view and
implementation of Actors than does the standard Scala distribution. Akka
includes support for distributed actors, etc.

Hope this helps.


>
> Best,
>
> Stuart
>
> On Sep 29, 3:30 am, David Pollak 
> wrote:
> > Folks,
> >
> > Given the continued instability of Scala Actors, I've decided to remove
> them
> > from Lift.
> >
> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
> > But, you'll also be able to use Akka Actors to power Lift's CometActors.
> > Specifically, I'm working with Jonas to make sure that we share a common
> > interface to Actors.
> >
> > I've gotten Lift nearly completely migrated over to Lift's Actors on the
> > dpp_wip_actorize branch.  Seehttp://
> github.com/dpp/liftweb/tree/dpp_wip_actorize
> >
> > There will be some breaking changes to your applications.  Specifically:
> >
> >- Box will be moved to a new package, net.liftweb.base (this is where
> the
> >interface for Actors will live as well)
> >- If you make any assumptions about your CometActors being Scala
> Actors
> >(e.g., using linking), you will have to rewrite this code
> >- Some methods in Lift that currently take Scala Actors as parameters
> >will take Lift Actors (e.g., ActorPing)
> >
> > There will be a parallel Maven repository with the new Lift Actor stuff
> in
> > it so you will be able to build you apps against the new code before the
> > official switch-over.
> >
> > Milestone 6 (which should be out next week) will be based on the existing
> > Actor model.  After we get feedback from the community about the new
> Actor
> > stuff, we will switch -SNAPSHOT over to the new Actor stuff.
> >
> > Questions, thoughts, or comments?
> >
> > Thanks,
> >
> > David
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[David Pollak]

On Tue, Sep 29, 2009 at 3:33 AM, Stefan Langer
wrote:

> Has this been communicated? And if is there a bug number associated with
> this issue?
>

I have filed a number of bugs, had a number of on-list exchanges with
Philipp Haller, and others in the community have done the same.  We are not
keeping the issue a secret.


>
> Regards
> Stefan
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~-~--~~~---~--~~
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: CometActor timeout problem

[David Pollak]

On Tue, Sep 29, 2009 at 8:00 AM, Jack Widman  wrote:

> Thanks. I will adapt these changes and if its still not working I will post
> the code so you can run it. Also, I admit, I have a ways to go in the art of
> functional programming.


Rule #1 - don't use anything mutable unless you have a good reason.
 Document your reason in your code.  That'll make you think
Rule #2 - take advantage of the type system.  having built-in XML means not
devolving into Strings which are pretty much untyped



>
>
> On Tue, Sep 29, 2009 at 12:50 AM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 7:29 PM, Jack Widman wrote:
>>
>>> Thanks David so much for this example. It is very cool to accomplish this
>>> in such a small amount of code! I am trying to adapt my code to work like
>>> this and it would help me if you could look at this (short) piece of code
>>> and tell me whats wrong with it. This code is supposed to display a list of
>>> pages and then actors in the background process each page. As each page is
>>> processed, the processed page is put into a Queue called PageQueue, and as
>>> each new page occurs in the Queue, the main page is rerendered. When I run
>>> it, the following happens:
>>>
>>>1. The initial list of pages is successfully displayed
>>>2. The actors in the background do their thing but the main page
>>>never shows the modified pages
>>>3. If I wait awhile and then refresh the main page, the modified
>>>pages do appear.
>>>4. Then I see the following exception:
>>>
>>> This page contains the following errors: error on line 14 at column 16:
>>> Namespace prefix auth on score is not defined
>>> Below is a rendering of the page up to the first error.
>>>
>>
>> Without a complete running (or failing) example, I can't really help out a
>> lot... but I have put a few comments inline.
>>
>>
>>> Here is the code:
>>>
>>> package com.authoritude.comet
>>>
>>> import net.liftweb.http.SHtml
>>> import net.liftweb.http.S
>>> import _root_.net.liftweb.http.js.JE._
>>> import _root_.net.liftweb.http.js.JsCmds._
>>> import scala.xml._
>>> import net.liftweb.http.S
>>> import net.liftweb.http.CometActor
>>> import net.liftweb.http.SessionVar
>>> import net.liftweb.util._
>>> import _root_.scala.xml._
>>> import _root_.net.liftweb.util.Helpers._
>>> import scala.actors._
>>> import scala.collection.mutable.Queue
>>>
>>>
>>> class BlogComet extends CometActor {
>>>
>>>   override def defaultPrefix = Full("auth")
>>>
>>>   var pages:List[Page] = PageManager.getPages
>>>
>>
>> state should be private to the Actor, not public.
>>
>>
>>>
>>>   def createDisplay(pages:List[Page]):NodeSeq = {
>>>
>>> var output:String=""
>>> for (page<-pages) {
>>>   output += {page.render}
>>> }
>>> XML.loadString(output+"")
>>>   }
>>>
>>
>> Why String + XML -> XML?
>> Why intermediate mutable state?
>>
>> How about
>> 
>> {
>>   for {page <- pages} yield > href={page.url}>{page.render>
>> }
>> 
>>
>>
>>
>>
>>>
>>>   def render = bind("score" -> listOfPages)
>>>
>>>   //new Page objects are arriving in the PageQueue from other threads
>>>   def listOfPages = {
>>> var page = PageQueue.getLatest
>>> //modifyPage takes page.getID, finds this page in
>>> // pages, and modifies it.
>>> pages = PageManager.modifyPage(page,pages)
>>> createDisplay(pages)
>>>   }
>>>
>>>   ActorPing.schedule(this, Tick, 1000L)
>>>
>>>   override def lowPriority : PartialFunction[Any, Unit] = {
>>>
>>> case Tick => {
>>>   partialUpdate(SetHtml("score", createDisplay(pages)))
>>>
>>
>> Why partialUpdate rather than just doing a reRender?  You're only saving a
>>  which is not much of a savings.
>>
>>
>>>ActorPing.schedule(this,Tick, 1000L)
>>>
>>
>> Why do this once a second?  Why not send a message from PageQueue when
>> things change?
>>
>>
>>> }
>>>   }
>>> }
>>>
>>> case object Tick
>>>
>>>
>>> I hope this is not to much to ask...
>>>
>>>
>>>
>>> On Mon, Sep 28, 2009 at 12:36 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
 Jack,
 Here's a working example.

 Here's the source for the CometActor:


 package com.liftcode.comet
 import net.liftweb._
 import http._
 import util._

 class Background extends CometActor {
   private val values = new Array[Box[Int]](100)

   // render the information
   def render =
   
 
   {
 values.zipWithIndex.map{
   case (Full(v), idx) => Item: {idx} is {v}
   case (_, idx) => Item: {idx} Calculating
 }
   }
 
   

   // receive the update and re-render
   override def lowPriority = {
 case (idx: Int, value: Int) =>
   values(idx) = Full(value)
   reRender(false)
   }

   // fork 100 thread
   override def localSetup() {
 super.localSetup()
 values.zipWithIndex.foreach 

[Lift] Re: Removing Scala Actors from Lift

[Meredith Gregory]

Dear David,

i don't really see this as losing our Scala Actors so much as *gaining* an
interface. Surely, someone can wire up Scala Actors to that interface if
there is a need. ;-)

Best wishes,

--greg

On Mon, Sep 28, 2009 at 7:30 PM, David Pollak  wrote:

> Folks,
>
> Given the continued instability of Scala Actors, I've decided to remove
> them from Lift.
>
> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
> But, you'll also be able to use Akka Actors to power Lift's CometActors.
> Specifically, I'm working with Jonas to make sure that we share a common
> interface to Actors.
>
> I've gotten Lift nearly completely migrated over to Lift's Actors on the
> dpp_wip_actorize branch.  See
> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> There will be some breaking changes to your applications.  Specifically:
>
>- Box will be moved to a new package, net.liftweb.base (this is where
>the interface for Actors will live as well)
>- If you make any assumptions about your CometActors being Scala Actors
>(e.g., using linking), you will have to rewrite this code
>- Some methods in Lift that currently take Scala Actors as parameters
>will take Lift Actors (e.g., ActorPing)
>
> There will be a parallel Maven repository with the new Lift Actor stuff in
> it so you will be able to build you apps against the new code before the
> official switch-over.
>
> Milestone 6 (which should be out next week) will be based on the existing
> Actor model.  After we get feedback from the community about the new Actor
> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>
> Questions, thoughts, or comments?
>
> Thanks,
>
> David
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--~--~-~--~~~---~--~~
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: Java 5 support?

[Derek Chen-Becker]

I'll take a stab at it. I'm familiar with Dynamic Proxies but I've never
implemented one before, so this would be a good experience. The only
drawback is that I think I'm going to have to use reflection on the wrapped
Statement/PreparedStatement since we won't know ahead of time which JDBC
version the person is going to want to use. It's going to have ugly guts,
but hopefully it will remain clean to the user other than the performance
impact of double dynamic dispatch.

Derek

On Tue, Sep 29, 2009 at 9:57 AM, David Pollak  wrote:

>
>
> On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim 
> wrote:
>
>>
>> Exactly. Thanks.
>> Is that an opton?
>>
>
> I think DynamicProxy is the way to go.
>
> Derek -- if you want, I can take a crack at getting to code working.
>
>
>>
>> -
>> Viktor Klang wrote:
>>
>> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim > >wrote:
>>
>> >
>> > Another option: Java has a way to dynamically implement an interface. I
>> > forgot what the classes are called. You supply a delegate and you can
>> > pattern match on which method is being invoked. In Java 5 the
>> nonexistent
>> > method will simply never be invoked, but it won't break code.
>> >
>>
>> Dynamic proxy?
>>
>>
>> >
>> > -
>> > Viktor Klang wrote:
>> >
>> > On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com
>> > >wrote:
>> >
>> > > Can you elaborate on what you mean? I was actually going to look at
>> how
>> > > log4jdbc does it and see if I could replicate it.
>> > >
>> >
>> > I haven't really tried this, but if you do:
>> >
>> > if you implement methods with the correct signatures in the
>> LoggedStatement
>> > and LoggedPreparedStatement, then wrap the invocations to the wrapped
>> > instances in a try->catch, and if there's an NoSuchMethodException,
>> return
>> > some default value?
>> >
>> >
>> >
>> > >
>> > > Derek
>> > >
>> > > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang > > >wrote:
>> > >
>> > >> Is it possible to have a  bridge trait for the Statement interface?
>> > >>
>> > >>
>> > >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> > >> dchenbec...@gmail.com> wrote:
>> > >>
>> > >>> No. I hadn't foreseen this issue, but I understand the importance of
>> > have
>> > >>> Java 5 support. I'm fine with writing and maintaining multiple
>> versions
>> > of
>> > >>> the impls for the various versions, but I wonder if there's any
>> clean
>> > way to
>> > >>> manage this with Maven.
>> > >>>
>> > >>> Derek
>> > >>>
>> > >>>
>> > >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>> > >>> feeder.of.the.be...@gmail.com> wrote:
>> > >>>
>> >  Crud.  This just isn't going to be easy, is it?
>> > 
>> > 
>> >  On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>> >  dchenbec...@gmail.com> wrote:
>> > 
>> > > Another issue, which may be more problematic, is that in my case
>> I'm
>> > > compiling against the java.sql.Statement interface. If I remove
>> the
>> > > troublesome methods so that it compiles for 1.5, it no longer
>> > compiles for
>> > > 1.6 because of the missing methods:
>> > >
>> > > [WARNING]
>> > >
>> >
>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
>> > > error: class LoggedStatement needs to be abstract, since method
>> > isPoolable
>> > > in trait Statement of type ()Boolean is not defined
>> > > [WARNING] class LoggedStatement(underlying : Statement) extends
>> > > Statement with DBLog {
>> > > [WARNING]   ^
>> > > [WARNING]
>> > >
>> >
>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
>> > > error: class LoggedPreparedStatement needs to be abstract, since
>> > method
>> > > setNClob in trait PreparedStatement of type
>> (Int,java.io.Reader)Unit
>> > is not
>> > > defined
>> > > [WARNING] class LoggedPreparedStatement (stmt : String, underlying
>> :
>> > > PreparedStatement) extends LoggedStatement(underlying) with
>> > > PreparedStatement {
>> > > [WARNING]   ^
>> > >
>> > >
>> > > Derek
>> > >
>> > >
>> > > On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
>> > > feeder.of.the.be...@gmail.com> wrote:
>> > >
>> > >>
>> > >>
>> > >> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> > >> dchenbec...@gmail.com> wrote:
>> > >>
>> > >>> The issue (and I may be overthinking this) is that we need 1.5
>> > class
>> > >>> libraries to compile against if we want to be able to verify
>> that
>> > the code
>> > >>> compiles under 1.5. If I, say, delete my JDK 5 install and
>> decide
>> > to
>> > >>> reinstall it down the road, it's not going to be available
>> without
>> > a
>> > >>> purchased license.
>> > >>>
>> > >>
>> > >> I can stash away a bunch of different copies of the JDK and give
>>

[Lift] Re: Unwarranted dependencies in lift-record

[Timothy Perrett]

Naftoli,

I agree - it should be possible to break this stuff out into traits so  
that we have a tight record library... for the most part, I cant see  
myself using Record for anything other than custom backends so it  
makes sense to break out the things that are not mandatory.

Cheers, Tim

On 29 Sep 2009, at 16:44, Naftoli Gugenheim wrote:

>
> Besides for actual dependencies, Mapper and Record were designed for  
> web apps, which is why they have asHtml and toForm etc. Personally I  
> don't like that design very much. DPP says it's more convenient for  
> the application programmer if it's all in one place, but if it's not  
> too late to make a fundamental change, wouldn't it be possible to  
> achieve that with traits?
> The least breaking way to do it that makes sense from a library  
> design perspective that comes to mind, is to have classes with the  
> same names with a HtmlMapper trait already mixed in. So  
> net.liftweb.mapper.web.LongKeyedMapper, says, has the same API as  
> the current LongKeyedMapper, but it's achieved by mixing in a trait.
> Or leave it in the same package and put the core parts of mapper in  
> a mapper-base module / mapper.base package.
> This will also have the advantage of allowing other objects to  
> provide toForm/asHtml etc., by having HtmlMapper extend a base trait.
>
>
>
> -
> Timothy Perrett wrote:
>
> Tim, I couldnt agree more!
>
> However, Record also has a dep on lift-webkit from S.funcMap which we
> really need to refactor / remove. Likewise for asJS methods which pull
> a dep on lift-webkit.
>
> Cheers, Tim
>
> On 29 Sep 2009, at 14:39, Tim Nelson wrote:
>
>> Aren't most of the dependencies that Record relies on coming from
>> the RDBMS code?
>>
>> Would it make sense to move that code to a separate module (lift-
>> record-rdbms)?
>>
>> I don't like all of the dependencies that Record relies on because
>> I'm not using the RDBMS code, I'm using a custom Record back end.
>>
>> It would be nice to have Record a completely separate module, but I
>> think at least moving the RDBMS and therefore the Mapper dependency
>> to a separate module would be very easy and remove most of the
>> dependencies.
>>
>> Tim
>>
>> On Tue, Sep 29, 2009 at 8:01 AM, Timothy Perrett >> wrote:
>>
>> This is my point - record should be more abstract... we dont want it
>> depending on all that stuff its pointless.
>>
>> @dpp or @marius... what are your thoughts?
>>
>> Cheers, Tim
>>
>> On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote:
>>
>>>
>>> lift-record depends on lift-mapper and since lift-mapper is heavily
>>> dependent on lift-webkit, lift-record ends up depending on lift-
>> webkit
>>> as well.
>>>
>>> So at the moment, lift-record would end up depending on lift-webkit
>>> (and
>>> lift-widget!) indirectly even if you remove reference to lift-webkit
>>> (superfluous) from lift-record pom.
>>>
>>> lift-widget part is simpler (just one reference in MappedInt, intend
>>> to
>>> take up later if somebody else don't beat me) but lift-webkit looks
>>> lot
>>> of work.
>>>
>>> Cheers, Indrajit
>>>
>>>
>>> On 29/09/09 3:12 PM, Timothy Perrett wrote:

 Guys,

 I just noticed that lift-record depends on lift-webket because of
 some
 calls to S... IMHO, we need to remove this because thats simply too
 tight a coupling between the webkit and an abstract persistence
 interface like record.

 For instance, one record abstraction I wrote isn't even used in
 webapps...

 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: Java 5 support?

[David Pollak]

On Tue, Sep 29, 2009 at 8:32 AM, Naftoli Gugenheim wrote:

>
> Exactly. Thanks.
> Is that an opton?
>

I think DynamicProxy is the way to go.

Derek -- if you want, I can take a crack at getting to code working.


>
> -
> Viktor Klang wrote:
>
> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim  >wrote:
>
> >
> > Another option: Java has a way to dynamically implement an interface. I
> > forgot what the classes are called. You supply a delegate and you can
> > pattern match on which method is being invoked. In Java 5 the nonexistent
> > method will simply never be invoked, but it won't break code.
> >
>
> Dynamic proxy?
>
>
> >
> > -
> > Viktor Klang wrote:
> >
> > On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker <
> dchenbec...@gmail.com
> > >wrote:
> >
> > > Can you elaborate on what you mean? I was actually going to look at how
> > > log4jdbc does it and see if I could replicate it.
> > >
> >
> > I haven't really tried this, but if you do:
> >
> > if you implement methods with the correct signatures in the
> LoggedStatement
> > and LoggedPreparedStatement, then wrap the invocations to the wrapped
> > instances in a try->catch, and if there's an NoSuchMethodException,
> return
> > some default value?
> >
> >
> >
> > >
> > > Derek
> > >
> > > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang  > >wrote:
> > >
> > >> Is it possible to have a  bridge trait for the Statement interface?
> > >>
> > >>
> > >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
> > >> dchenbec...@gmail.com> wrote:
> > >>
> > >>> No. I hadn't foreseen this issue, but I understand the importance of
> > have
> > >>> Java 5 support. I'm fine with writing and maintaining multiple
> versions
> > of
> > >>> the impls for the various versions, but I wonder if there's any clean
> > way to
> > >>> manage this with Maven.
> > >>>
> > >>> Derek
> > >>>
> > >>>
> > >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
> > >>> feeder.of.the.be...@gmail.com> wrote:
> > >>>
> >  Crud.  This just isn't going to be easy, is it?
> > 
> > 
> >  On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
> >  dchenbec...@gmail.com> wrote:
> > 
> > > Another issue, which may be more problematic, is that in my case
> I'm
> > > compiling against the java.sql.Statement interface. If I remove the
> > > troublesome methods so that it compiles for 1.5, it no longer
> > compiles for
> > > 1.6 because of the missing methods:
> > >
> > > [WARNING]
> > >
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> > > error: class LoggedStatement needs to be abstract, since method
> > isPoolable
> > > in trait Statement of type ()Boolean is not defined
> > > [WARNING] class LoggedStatement(underlying : Statement) extends
> > > Statement with DBLog {
> > > [WARNING]   ^
> > > [WARNING]
> > >
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> > > error: class LoggedPreparedStatement needs to be abstract, since
> > method
> > > setNClob in trait PreparedStatement of type
> (Int,java.io.Reader)Unit
> > is not
> > > defined
> > > [WARNING] class LoggedPreparedStatement (stmt : String, underlying
> :
> > > PreparedStatement) extends LoggedStatement(underlying) with
> > > PreparedStatement {
> > > [WARNING]   ^
> > >
> > >
> > > Derek
> > >
> > >
> > > On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> > > feeder.of.the.be...@gmail.com> wrote:
> > >
> > >>
> > >>
> > >> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
> > >> dchenbec...@gmail.com> wrote:
> > >>
> > >>> The issue (and I may be overthinking this) is that we need 1.5
> > class
> > >>> libraries to compile against if we want to be able to verify that
> > the code
> > >>> compiles under 1.5. If I, say, delete my JDK 5 install and decide
> > to
> > >>> reinstall it down the road, it's not going to be available
> without
> > a
> > >>> purchased license.
> > >>>
> > >>
> > >> I can stash away a bunch of different copies of the JDK and give
> > them
> > >> to you when you need them.
> > >>
> > >> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
> > >> builds with.
> > >>
> > >>
> > >>>
> > >>> Derek
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
> > >>> feeder.of.the.be...@gmail.com> wrote:
> > >>>
> > 
> > 
> >  On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
> >  dchenbec...@gmail.com> wrote:
> > 
> > > My main concern is that after October 30, Java 5 costs money
> (I'm
> > > guessing not a trivial amount, either). I can get the JDK right
> > now, but if
> > > so

[Lift] Re: Unwarranted dependencies in lift-record

[Naftoli Gugenheim]

Besides for actual dependencies, Mapper and Record were designed for web apps, 
which is why they have asHtml and toForm etc. Personally I don't like that 
design very much. DPP says it's more convenient for the application programmer 
if it's all in one place, but if it's not too late to make a fundamental 
change, wouldn't it be possible to achieve that with traits?
The least breaking way to do it that makes sense from a library design 
perspective that comes to mind, is to have classes with the same names with a 
HtmlMapper trait already mixed in. So net.liftweb.mapper.web.LongKeyedMapper, 
says, has the same API as the current LongKeyedMapper, but it's achieved by 
mixing in a trait.
Or leave it in the same package and put the core parts of mapper in a 
mapper-base module / mapper.base package.
This will also have the advantage of allowing other objects to provide 
toForm/asHtml etc., by having HtmlMapper extend a base trait.



-
Timothy Perrett wrote:

Tim, I couldnt agree more!

However, Record also has a dep on lift-webkit from S.funcMap which we  
really need to refactor / remove. Likewise for asJS methods which pull  
a dep on lift-webkit.

Cheers, Tim

On 29 Sep 2009, at 14:39, Tim Nelson wrote:

> Aren't most of the dependencies that Record relies on coming from  
> the RDBMS code?
>
> Would it make sense to move that code to a separate module (lift- 
> record-rdbms)?
>
> I don't like all of the dependencies that Record relies on because  
> I'm not using the RDBMS code, I'm using a custom Record back end.
>
> It would be nice to have Record a completely separate module, but I  
> think at least moving the RDBMS and therefore the Mapper dependency  
> to a separate module would be very easy and remove most of the  
> dependencies.
>
> Tim
>
> On Tue, Sep 29, 2009 at 8:01 AM, Timothy Perrett  > wrote:
>
> This is my point - record should be more abstract... we dont want it
> depending on all that stuff its pointless.
>
> @dpp or @marius... what are your thoughts?
>
> Cheers, Tim
>
> On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote:
>
> >
> > lift-record depends on lift-mapper and since lift-mapper is heavily
> > dependent on lift-webkit, lift-record ends up depending on lift- 
> webkit
> > as well.
> >
> > So at the moment, lift-record would end up depending on lift-webkit
> > (and
> > lift-widget!) indirectly even if you remove reference to lift-webkit
> > (superfluous) from lift-record pom.
> >
> > lift-widget part is simpler (just one reference in MappedInt, intend
> > to
> > take up later if somebody else don't beat me) but lift-webkit looks
> > lot
> > of work.
> >
> > Cheers, Indrajit
> >
> >
> > On 29/09/09 3:12 PM, Timothy Perrett wrote:
> >>
> >> Guys,
> >>
> >> I just noticed that lift-record depends on lift-webket because of
> >> some
> >> calls to S... IMHO, we need to remove this because thats simply too
> >> tight a coupling between the webkit and an abstract persistence
> >> interface like record.
> >>
> >> For instance, one record abstraction I wrote isn't even used in
> >> webapps...
> >>
> >> 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: Java 5 support?

[Naftoli Gugenheim]

Exactly. Thanks.
Is that an opton?

-
Viktor Klang wrote:

On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim wrote:

>
> Another option: Java has a way to dynamically implement an interface. I
> forgot what the classes are called. You supply a delegate and you can
> pattern match on which method is being invoked. In Java 5 the nonexistent
> method will simply never be invoked, but it won't break code.
>

Dynamic proxy?


>
> -
> Viktor Klang wrote:
>
> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker  >wrote:
>
> > Can you elaborate on what you mean? I was actually going to look at how
> > log4jdbc does it and see if I could replicate it.
> >
>
> I haven't really tried this, but if you do:
>
> if you implement methods with the correct signatures in the LoggedStatement
> and LoggedPreparedStatement, then wrap the invocations to the wrapped
> instances in a try->catch, and if there's an NoSuchMethodException, return
> some default value?
>
>
>
> >
> > Derek
> >
> > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang  >wrote:
> >
> >> Is it possible to have a  bridge trait for the Statement interface?
> >>
> >>
> >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
> >> dchenbec...@gmail.com> wrote:
> >>
> >>> No. I hadn't foreseen this issue, but I understand the importance of
> have
> >>> Java 5 support. I'm fine with writing and maintaining multiple versions
> of
> >>> the impls for the various versions, but I wonder if there's any clean
> way to
> >>> manage this with Maven.
> >>>
> >>> Derek
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
> >>> feeder.of.the.be...@gmail.com> wrote:
> >>>
>  Crud.  This just isn't going to be easy, is it?
> 
> 
>  On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>  dchenbec...@gmail.com> wrote:
> 
> > Another issue, which may be more problematic, is that in my case I'm
> > compiling against the java.sql.Statement interface. If I remove the
> > troublesome methods so that it compiles for 1.5, it no longer
> compiles for
> > 1.6 because of the missing methods:
> >
> > [WARNING]
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> > error: class LoggedStatement needs to be abstract, since method
> isPoolable
> > in trait Statement of type ()Boolean is not defined
> > [WARNING] class LoggedStatement(underlying : Statement) extends
> > Statement with DBLog {
> > [WARNING]   ^
> > [WARNING]
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> > error: class LoggedPreparedStatement needs to be abstract, since
> method
> > setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit
> is not
> > defined
> > [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
> > PreparedStatement) extends LoggedStatement(underlying) with
> > PreparedStatement {
> > [WARNING]   ^
> >
> >
> > Derek
> >
> >
> > On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> > feeder.of.the.be...@gmail.com> wrote:
> >
> >>
> >>
> >> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
> >> dchenbec...@gmail.com> wrote:
> >>
> >>> The issue (and I may be overthinking this) is that we need 1.5
> class
> >>> libraries to compile against if we want to be able to verify that
> the code
> >>> compiles under 1.5. If I, say, delete my JDK 5 install and decide
> to
> >>> reinstall it down the road, it's not going to be available without
> a
> >>> purchased license.
> >>>
> >>
> >> I can stash away a bunch of different copies of the JDK and give
> them
> >> to you when you need them.
> >>
> >> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
> >> builds with.
> >>
> >>
> >>>
> >>> Derek
> >>>
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
> >>> feeder.of.the.be...@gmail.com> wrote:
> >>>
> 
> 
>  On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>  dchenbec...@gmail.com> wrote:
> 
> > My main concern is that after October 30, Java 5 costs money (I'm
> > guessing not a trivial amount, either). I can get the JDK right
> now, but if
> > some bug in the Java libraries pops up that would prevent things
> from
> > working, I don't know how we'll work around that.
> >
> 
>  I don't see the condition under which that could happen.  When we
>  compile against Java 1.5, we are simply defining the contract
> between our
>  classes and the library classes.  None of the library "seeps" into
> our code
>  (this is not true of Scala traits).  So, as long as the running
> library has
>  t

[Lift] Re: Beginner question, how to run Javascript from function?

[Ross Mellgren]

I use head merging and JsCmds.Script, for example:

{ JsCmds.Script(JsCmds.OnLoad(/* initialization code here */)) } 
 ++
...

Lift will automatically move the  tag coming out into the HTML  
head tag, and JsCmds.OnLoad is equivalent to jQuery ready(), so the  
code will only be executed once the DOM is loaded.

Hope that helps,
-Ross

On Sep 29, 2009, at 7:48 AM, philip wrote:

>
>
> Hi, I want to run some javascript to initialize my component which is
> a YUI richtexteditor.
> Can help? This seems to be the wrong way to do it.
>
> Thanks, Philip
>
> class RichEditor
> {
>  def show = 
> cols="75">
>
>{ JsCmds.Run("alert('hi')") }
>
> }
>
> >


--~--~-~--~~~---~--~~
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: Code Plugability in Lift

[glenn]

If you want to keep to a JPA standard, I believe EclipseLink, the
former toplink, is the
defacto standard API for that. Keep Hibernate, and any of the other
varieties, out of it.
In fact, if you stick to just the JPA stuff in EclipseLink, and don't
use any of the
extras, then Hibernate can use it, just fine.

Glenn

On Sep 28, 11:01 am, Derek Chen-Becker  wrote:
> It's a really ugly corner that JPA paints us into here. There aren't any
> vendor-neutral APIs for programmatically wiring entities up, so it's going
> to have to be some sort of trickery.
>
> On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett 
> wrote:
>
> > Are you feeling OK david? For a moment I thought you said *runtime*
> > bytecode generation?!
>
> > Cheers, Tim
>
> > On 25 Sep 2009, at 23:06, David Pollak wrote:
>
> > I've been thinking about vomitting (I mean creating) bytecode at runtime
> > that creates a mock class for Hibernate consumption.
>
> > On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker 
> > wrote:
>
> >> I've been thinking about it in the back of my head. I may be able to get
> >> something working that's vendor specific (e.g. Hibernate) by using their
> >> internal API to have the Record+JPA driver wire up the entities at runtime
> >> based on Record metadata. Feels kinda dirty, but if it works that would be
> >> great.
>
> >> Derek
>
> >> On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett  >> > wrote:
>
> >>> I know we've discussed this before, but ultimately we'd like to wrap
> >>> JPA with a Record front end somehow...
>
> >>> Cheers, Tim
>
> >>> On Sep 21, 10:42 pm, David Pollak 
> >>> wrote:
> >>> > On Mon, Sep 21, 2009 at 2:03 PM, glenn  wrote:
>
> >>> > > David,
>
> >>> > > Does this mean you could write an entity class, like so:
>
> >>> > > class User(val firstName: String, val lastName: String, val userName:
> >>> > > String, val email: String, val password: String) with myTrait {...}
>
> >>> > > and it would be useable in either a JPA or mapper or record
> >>> > > implementation?
>
> >>> > No.  Mapper/Record require a richer representation of fields than
> >>> Pojos.
> >>> >  The reason for this can be found athttp://
> >>> blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w...
>
> >>> > > That would be the ticket.
>
> >>> > > Glenn
>
> >>> > > On Sep 21, 12:47 pm, David Pollak 
> >>> > > wrote:
> >>> > > > This is an impedance mis-match between POJOs (what JPA expects) and
> >>> the
> >>> > > > richer fields that Mapper and Record have.
> >>> > > > I'm working on an interface (
>
> >>>http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne..
> >>> .)
> >>> > > > that should be a base trait on everything in Lift that's gettable
> >>> or
> >>> > > > gettable/settable.
>
> >>> > > > Then you could write a trait that looks like:
>
> >>> > > > trait MyThing {  def name: PSettableValueHolder[String]
> >>> > > > *
> >>> > > > *
> >>> > > > * def getName(): String = name.is*
> >>> > > > * def setName(in: String) = name.set(in)*
> >>> > > > *
> >>> > > > *
> >>> > > > * *
>
> >>> > > > }
>
> >>> > > > Such a trait should be able to bridge a JPA implementation and a
> >>> Lift
> >>> > > mapper
> >>> > > > implementation.
>
> >>> > > > If you've got a better solution, please code it up and let's talk
> >>> about
> >>> > > it.
>
> >>> > > > On Mon, Sep 21, 2009 at 9:31 AM, glenn  wrote:
>
> >>> > > > > Forgive me. I'm bringing up the subject of modularization in Lift
> >>> > > > > under a new heading, but the last discussion was, sadly, all over
> >>> the
> >>> > > > > map and only served to emphasize the problem. So let me narrow it
> >>> > > > > down, a bit, here, and ask:
>
> >>> > > > > How is it possible to create two different snippet
> >>> implementations, or
> >>> > > > > two different models, one JPA and one not, or one using the
> >>> mapper
> >>> > > > > framework and another the record, and replace one with the other
> >>> > > > > without having to recompile the application?
>
> >>> > > > > We're not talking here about interface design - you still have to
> >>> deal
> >>> > > > > with boot.  And traits, as has been suggested by others...well,
> >>> you'd
> >>> > > > > better not expose them to the world outside your implementation,
> >>> as
> >>> > > > > any changes would require recompilation. In other words, you
> >>> can't
> >>> > > > > really use traits for your interface.
>
> >>> > > > > To use Lift in the enterprise does require that teams be able to
> >>> work
> >>> > > > > independently, doesn't it.
>
> >>> > > > > Glenn
>
> >>> > > > --
> >>> > > > 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
>
> >>> > --
> >>> > 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

[Lift] Re: Can we deploy lift webapp on Google App Engine?

[justss]

Great TylerWeir!!! Thanks a lot... Can you please suggest any kind of
documentation for this... sorry to be bothering you for that. Any
tutorial would be of great help.

Cheers.

On Sep 29, 2:08 pm, TylerWeir  wrote:
> http://lift-example.appspot.com
>
> There are caveats though, the major one is the lack of actors.
>
> On Sep 29, 8:53 am, justss  wrote:
>
> > Hi All,
>
> > I'm brand new to Scala and lift framework. I have created a very
> > simple hello world web app in lift framework and deployed it
> > successfully on tomcat.
> > Now I want to know whether I can deploy the same lift application on
> > Google app engine or not? I have the war ready, so in I thought that
> > it should have been as simple as deploying any war on tomcat or
> > websphere!!! But I see it is not ;-(
> > Can anyone please guide me as to how I can deploy my mini lift app on
> > GAE?
>
> > Thanks in advance.
> > A Newbie

--~--~-~--~~~---~--~~
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: Code Plugability in Lift

[Derek Chen-Becker]

Yeah, there are a lot of things that I like about JPA, but it's clear to me
that design by committee is less than optimal in this case.

On Mon, Sep 28, 2009 at 7:57 PM, Meredith Gregory
wrote:

> Dear Derek,
>
> You hit the nail on the head. JPA is a quagmire disguised as an
> abstraction.
>
> Best wishes,
>
> --greg
>
>
> On Mon, Sep 28, 2009 at 11:01 AM, Derek Chen-Becker  > wrote:
>
>> It's a really ugly corner that JPA paints us into here. There aren't any
>> vendor-neutral APIs for programmatically wiring entities up, so it's going
>> to have to be some sort of trickery.
>>
>>
>> On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett > > wrote:
>>
>>> Are you feeling OK david? For a moment I thought you said *runtime*
>>> bytecode generation?!
>>>
>>> Cheers, Tim
>>>
>>> On 25 Sep 2009, at 23:06, David Pollak wrote:
>>>
>>> I've been thinking about vomitting (I mean creating) bytecode at runtime
>>> that creates a mock class for Hibernate consumption.
>>>
>>> On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
 I've been thinking about it in the back of my head. I may be able to get
 something working that's vendor specific (e.g. Hibernate) by using their
 internal API to have the Record+JPA driver wire up the entities at runtime
 based on Record metadata. Feels kinda dirty, but if it works that would be
 great.

 Derek


 On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett <
 timo...@getintheloop.eu> wrote:

>
> I know we've discussed this before, but ultimately we'd like to wrap
> JPA with a Record front end somehow...
>
> Cheers, Tim
>
> On Sep 21, 10:42 pm, David Pollak 
> wrote:
> > On Mon, Sep 21, 2009 at 2:03 PM, glenn  wrote:
> >
> > > David,
> >
> > > Does this mean you could write an entity class, like so:
> >
> > > class User(val firstName: String, val lastName: String, val
> userName:
> > > String, val email: String, val password: String) with myTrait {...}
> >
> > > and it would be useable in either a JPA or mapper or record
> > > implementation?
> >
> > No.  Mapper/Record require a richer representation of fields than
> Pojos.
> >  The reason for this can be found athttp://
> blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w...
> >
> >
> >
> >
> >
> >
> >
> > > That would be the ticket.
> >
> > > Glenn
> >
> > > On Sep 21, 12:47 pm, David Pollak 
> > > wrote:
> > > > This is an impedance mis-match between POJOs (what JPA expects)
> and the
> > > > richer fields that Mapper and Record have.
> > > > I'm working on an interface (
> > >
> http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne..
> .)
> > > > that should be a base trait on everything in Lift that's gettable
> or
> > > > gettable/settable.
> >
> > > > Then you could write a trait that looks like:
> >
> > > > trait MyThing {  def name: PSettableValueHolder[String]
> > > > *
> > > > *
> > > > * def getName(): String = name.is*
> > > > * def setName(in: String) = name.set(in)*
> > > > *
> > > > *
> > > > * *
> >
> > > > }
> >
> > > > Such a trait should be able to bridge a JPA implementation and a
> Lift
> > > mapper
> > > > implementation.
> >
> > > > If you've got a better solution, please code it up and let's talk
> about
> > > it.
> >
> > > > On Mon, Sep 21, 2009 at 9:31 AM, glenn  wrote:
> >
> > > > > Forgive me. I'm bringing up the subject of modularization in
> Lift
> > > > > under a new heading, but the last discussion was, sadly, all
> over the
> > > > > map and only served to emphasize the problem. So let me narrow
> it
> > > > > down, a bit, here, and ask:
> >
> > > > > How is it possible to create two different snippet
> implementations, or
> > > > > two different models, one JPA and one not, or one using the
> mapper
> > > > > framework and another the record, and replace one with the
> other
> > > > > without having to recompile the application?
> >
> > > > > We're not talking here about interface design - you still have
> to deal
> > > > > with boot.  And traits, as has been suggested by others...well,
> you'd
> > > > > better not expose them to the world outside your
> implementation, as
> > > > > any changes would require recompilation. In other words, you
> can't
> > > > > really use traits for your interface.
> >
> > > > > To use Lift in the enterprise does require that teams be able
> to work
> > > > > independently, doesn't it.
> >
> > > > > Glenn
> >
> > > > --
> > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > Beginning Scalahttp://www.apress.com/book

[Lift] Re: Java 5 support?

[Kevin Wright]

On Tue, Sep 29, 2009 at 3:46 PM, Viktor Klang  wrote:
>
>
> On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim 
> wrote:
>>
>> Another option: Java has a way to dynamically implement an interface. I
>> forgot what the classes are called. You supply a delegate and you can
>> pattern match on which method is being invoked. In Java 5 the nonexistent
>> method will simply never be invoked, but it won't break code.
>
> Dynamic proxy?
>

Sounds like it to me :)

>>
>> -
>> Viktor Klang wrote:
>>
>> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker
>> wrote:
>>
>> > Can you elaborate on what you mean? I was actually going to look at how
>> > log4jdbc does it and see if I could replicate it.
>> >
>>
>> I haven't really tried this, but if you do:
>>
>> if you implement methods with the correct signatures in the
>> LoggedStatement
>> and LoggedPreparedStatement, then wrap the invocations to the wrapped
>> instances in a try->catch, and if there's an NoSuchMethodException, return
>> some default value?
>>
>>
>>
>> >
>> > Derek
>> >
>> > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang
>> > wrote:
>> >
>> >> Is it possible to have a  bridge trait for the Statement interface?
>> >>
>> >>
>> >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> >> dchenbec...@gmail.com> wrote:
>> >>
>> >>> No. I hadn't foreseen this issue, but I understand the importance of
>> >>> have
>> >>> Java 5 support. I'm fine with writing and maintaining multiple
>> >>> versions of
>> >>> the impls for the various versions, but I wonder if there's any clean
>> >>> way to
>> >>> manage this with Maven.
>> >>>
>> >>> Derek
>> >>>
>> >>>
>> >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>> >>> feeder.of.the.be...@gmail.com> wrote:
>> >>>
>>  Crud.  This just isn't going to be easy, is it?
>> 
>> 
>>  On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>>  dchenbec...@gmail.com> wrote:
>> 
>> > Another issue, which may be more problematic, is that in my case I'm
>> > compiling against the java.sql.Statement interface. If I remove the
>> > troublesome methods so that it compiles for 1.5, it no longer
>> > compiles for
>> > 1.6 because of the missing methods:
>> >
>> > [WARNING]
>> >
>> > /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
>> > error: class LoggedStatement needs to be abstract, since method
>> > isPoolable
>> > in trait Statement of type ()Boolean is not defined
>> > [WARNING] class LoggedStatement(underlying : Statement) extends
>> > Statement with DBLog {
>> > [WARNING]       ^
>> > [WARNING]
>> >
>> > /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
>> > error: class LoggedPreparedStatement needs to be abstract, since
>> > method
>> > setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit
>> > is not
>> > defined
>> > [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
>> > PreparedStatement) extends LoggedStatement(underlying) with
>> > PreparedStatement {
>> > [WARNING]       ^
>> >
>> >
>> > Derek
>> >
>> >
>> > On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
>> > feeder.of.the.be...@gmail.com> wrote:
>> >
>> >>
>> >>
>> >> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> >> dchenbec...@gmail.com> wrote:
>> >>
>> >>> The issue (and I may be overthinking this) is that we need 1.5
>> >>> class
>> >>> libraries to compile against if we want to be able to verify that
>> >>> the code
>> >>> compiles under 1.5. If I, say, delete my JDK 5 install and decide
>> >>> to
>> >>> reinstall it down the road, it's not going to be available without
>> >>> a
>> >>> purchased license.
>> >>>
>> >>
>> >> I can stash away a bunch of different copies of the JDK and give
>> >> them
>> >> to you when you need them.
>> >>
>> >> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
>> >> builds with.
>> >>
>> >>
>> >>>
>> >>> Derek
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>> >>> feeder.of.the.be...@gmail.com> wrote:
>> >>>
>> 
>> 
>>  On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>>  dchenbec...@gmail.com> wrote:
>> 
>> > My main concern is that after October 30, Java 5 costs money
>> > (I'm
>> > guessing not a trivial amount, either). I can get the JDK right
>> > now, but if
>> > some bug in the Java libraries pops up that would prevent things
>> > from
>> > working, I don't know how we'll work around that.
>> >
>> 
>>  I don't see the condition under which that could happen.  When we
>>  compile 

[Lift] Re: CometActor timeout problem

[Jack Widman]

Thanks. I will adapt these changes and if its still not working I will post
the code so you can run it. Also, I admit, I have a ways to go in the art of
functional programming.

On Tue, Sep 29, 2009 at 12:50 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

>
>
> On Mon, Sep 28, 2009 at 7:29 PM, Jack Widman wrote:
>
>> Thanks David so much for this example. It is very cool to accomplish this
>> in such a small amount of code! I am trying to adapt my code to work like
>> this and it would help me if you could look at this (short) piece of code
>> and tell me whats wrong with it. This code is supposed to display a list of
>> pages and then actors in the background process each page. As each page is
>> processed, the processed page is put into a Queue called PageQueue, and as
>> each new page occurs in the Queue, the main page is rerendered. When I run
>> it, the following happens:
>>
>>1. The initial list of pages is successfully displayed
>>2. The actors in the background do their thing but the main page never
>>shows the modified pages
>>3. If I wait awhile and then refresh the main page, the modified pages
>>do appear.
>>4. Then I see the following exception:
>>
>> This page contains the following errors: error on line 14 at column 16:
>> Namespace prefix auth on score is not defined
>> Below is a rendering of the page up to the first error.
>>
>
> Without a complete running (or failing) example, I can't really help out a
> lot... but I have put a few comments inline.
>
>
>> Here is the code:
>>
>> package com.authoritude.comet
>>
>> import net.liftweb.http.SHtml
>> import net.liftweb.http.S
>> import _root_.net.liftweb.http.js.JE._
>> import _root_.net.liftweb.http.js.JsCmds._
>> import scala.xml._
>> import net.liftweb.http.S
>> import net.liftweb.http.CometActor
>> import net.liftweb.http.SessionVar
>> import net.liftweb.util._
>> import _root_.scala.xml._
>> import _root_.net.liftweb.util.Helpers._
>> import scala.actors._
>> import scala.collection.mutable.Queue
>>
>>
>> class BlogComet extends CometActor {
>>
>>   override def defaultPrefix = Full("auth")
>>
>>   var pages:List[Page] = PageManager.getPages
>>
>
> state should be private to the Actor, not public.
>
>
>>
>>   def createDisplay(pages:List[Page]):NodeSeq = {
>>
>> var output:String=""
>> for (page<-pages) {
>>   output += {page.render}
>> }
>> XML.loadString(output+"")
>>   }
>>
>
> Why String + XML -> XML?
> Why intermediate mutable state?
>
> How about
> 
> {
>   for {page <- pages} yield  href={page.url}>{page.render>
> }
> 
>
>
>
>
>>
>>   def render = bind("score" -> listOfPages)
>>
>>   //new Page objects are arriving in the PageQueue from other threads
>>   def listOfPages = {
>> var page = PageQueue.getLatest
>> //modifyPage takes page.getID, finds this page in
>> // pages, and modifies it.
>> pages = PageManager.modifyPage(page,pages)
>> createDisplay(pages)
>>   }
>>
>>   ActorPing.schedule(this, Tick, 1000L)
>>
>>   override def lowPriority : PartialFunction[Any, Unit] = {
>>
>> case Tick => {
>>   partialUpdate(SetHtml("score", createDisplay(pages)))
>>
>
> Why partialUpdate rather than just doing a reRender?  You're only saving a
>  which is not much of a savings.
>
>
>>ActorPing.schedule(this,Tick, 1000L)
>>
>
> Why do this once a second?  Why not send a message from PageQueue when
> things change?
>
>
>> }
>>   }
>> }
>>
>> case object Tick
>>
>>
>> I hope this is not to much to ask...
>>
>>
>>
>> On Mon, Sep 28, 2009 at 12:36 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Jack,
>>> Here's a working example.
>>>
>>> Here's the source for the CometActor:
>>>
>>>
>>> package com.liftcode.comet
>>> import net.liftweb._
>>> import http._
>>> import util._
>>>
>>> class Background extends CometActor {
>>>   private val values = new Array[Box[Int]](100)
>>>
>>>   // render the information
>>>   def render =
>>>   
>>> 
>>>   {
>>> values.zipWithIndex.map{
>>>   case (Full(v), idx) => Item: {idx} is {v}
>>>   case (_, idx) => Item: {idx} Calculating
>>> }
>>>   }
>>> 
>>>   
>>>
>>>   // receive the update and re-render
>>>   override def lowPriority = {
>>> case (idx: Int, value: Int) =>
>>>   values(idx) = Full(value)
>>>   reRender(false)
>>>   }
>>>
>>>   // fork 100 thread
>>>   override def localSetup() {
>>> super.localSetup()
>>> values.zipWithIndex.foreach {
>>>   case (_, idx) =>
>>> (new Thread(
>>> new Runnable {
>>>   def run() {
>>> Thread.sleep(1 + Helpers.randomLong(1))
>>> Background.this ! (idx, Helpers.randomInt(1000))
>>>   }
>>> }
>>> )).start()
>>> }
>>>   }
>>> }
>>>
>>>
>>> Note that the render method cannot block.  You must always render the
>>> page and put placeholders where you will be updating values.
>>>
>>> Note

[Lift] Re: Unwarranted dependencies in lift-record

[Timothy Perrett]

Tim, I couldnt agree more!

However, Record also has a dep on lift-webkit from S.funcMap which we  
really need to refactor / remove. Likewise for asJS methods which pull  
a dep on lift-webkit.

Cheers, Tim

On 29 Sep 2009, at 14:39, Tim Nelson wrote:

> Aren't most of the dependencies that Record relies on coming from  
> the RDBMS code?
>
> Would it make sense to move that code to a separate module (lift- 
> record-rdbms)?
>
> I don't like all of the dependencies that Record relies on because  
> I'm not using the RDBMS code, I'm using a custom Record back end.
>
> It would be nice to have Record a completely separate module, but I  
> think at least moving the RDBMS and therefore the Mapper dependency  
> to a separate module would be very easy and remove most of the  
> dependencies.
>
> Tim
>
> On Tue, Sep 29, 2009 at 8:01 AM, Timothy Perrett  > wrote:
>
> This is my point - record should be more abstract... we dont want it
> depending on all that stuff its pointless.
>
> @dpp or @marius... what are your thoughts?
>
> Cheers, Tim
>
> On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote:
>
> >
> > lift-record depends on lift-mapper and since lift-mapper is heavily
> > dependent on lift-webkit, lift-record ends up depending on lift- 
> webkit
> > as well.
> >
> > So at the moment, lift-record would end up depending on lift-webkit
> > (and
> > lift-widget!) indirectly even if you remove reference to lift-webkit
> > (superfluous) from lift-record pom.
> >
> > lift-widget part is simpler (just one reference in MappedInt, intend
> > to
> > take up later if somebody else don't beat me) but lift-webkit looks
> > lot
> > of work.
> >
> > Cheers, Indrajit
> >
> >
> > On 29/09/09 3:12 PM, Timothy Perrett wrote:
> >>
> >> Guys,
> >>
> >> I just noticed that lift-record depends on lift-webket because of
> >> some
> >> calls to S... IMHO, we need to remove this because thats simply too
> >> tight a coupling between the webkit and an abstract persistence
> >> interface like record.
> >>
> >> For instance, one record abstraction I wrote isn't even used in
> >> webapps...
> >>
> >> 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: Java 5 support?

[Naftoli Gugenheim]

Another option: Java has a way to dynamically implement an interface. I forgot 
what the classes are called. You supply a delegate and you can pattern match on 
which method is being invoked. In Java 5 the nonexistent method will simply 
never be invoked, but it won't break code. 

-
Viktor Klang wrote:

On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker wrote:

> Can you elaborate on what you mean? I was actually going to look at how
> log4jdbc does it and see if I could replicate it.
>

I haven't really tried this, but if you do:

if you implement methods with the correct signatures in the LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try->catch, and if there's an NoSuchMethodException, return
some default value?



>
> Derek
>
> On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang wrote:
>
>> Is it possible to have a  bridge trait for the Statement interface?
>>
>>
>> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> No. I hadn't foreseen this issue, but I understand the importance of have
>>> Java 5 support. I'm fine with writing and maintaining multiple versions of
>>> the impls for the various versions, but I wonder if there's any clean way to
>>> manage this with Maven.
>>>
>>> Derek
>>>
>>>
>>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
 Crud.  This just isn't going to be easy, is it?


 On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> Another issue, which may be more problematic, is that in my case I'm
> compiling against the java.sql.Statement interface. If I remove the
> troublesome methods so that it compiles for 1.5, it no longer compiles for
> 1.6 because of the missing methods:
>
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> error: class LoggedStatement needs to be abstract, since method isPoolable
> in trait Statement of type ()Boolean is not defined
> [WARNING] class LoggedStatement(underlying : Statement) extends
> Statement with DBLog {
> [WARNING]   ^
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> error: class LoggedPreparedStatement needs to be abstract, since method
> setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is 
> not
> defined
> [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
> PreparedStatement) extends LoggedStatement(underlying) with
> PreparedStatement {
> [WARNING]   ^
>
>
> Derek
>
>
> On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> The issue (and I may be overthinking this) is that we need 1.5 class
>>> libraries to compile against if we want to be able to verify that the 
>>> code
>>> compiles under 1.5. If I, say, delete my JDK 5 install and decide to
>>> reinstall it down the road, it's not going to be available without a
>>> purchased license.
>>>
>>
>> I can stash away a bunch of different copies of the JDK and give them
>> to you when you need them.
>>
>> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
>> builds with.
>>
>>
>>>
>>> Derek
>>>
>>>
>>>
>>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>


 On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> My main concern is that after October 30, Java 5 costs money (I'm
> guessing not a trivial amount, either). I can get the JDK right now, 
> but if
> some bug in the Java libraries pops up that would prevent things from
> working, I don't know how we'll work around that.
>

 I don't see the condition under which that could happen.  When we
 compile against Java 1.5, we are simply defining the contract between 
 our
 classes and the library classes.  None of the library "seeps" into our 
 code
 (this is not true of Scala traits).  So, as long as the running 
 library has
 the classes/methods that we are calling, we're fine.  Compiling 
 against 1.5
 simply means that we have fewer calls that we can make.  If there is an
 issue in 1.5 that a user is experiencing, that is the user's issue, not
 ours.  If the code compiles (and runs tests) against 1.5 and does not
 generate the particular issue that the user is seeing under 

[Lift] Re: Java 5 support?

[Viktor Klang]

On Tue, Sep 29, 2009 at 4:44 PM, Naftoli Gugenheim wrote:

>
> Another option: Java has a way to dynamically implement an interface. I
> forgot what the classes are called. You supply a delegate and you can
> pattern match on which method is being invoked. In Java 5 the nonexistent
> method will simply never be invoked, but it won't break code.
>

Dynamic proxy?


>
> -
> Viktor Klang wrote:
>
> On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker  >wrote:
>
> > Can you elaborate on what you mean? I was actually going to look at how
> > log4jdbc does it and see if I could replicate it.
> >
>
> I haven't really tried this, but if you do:
>
> if you implement methods with the correct signatures in the LoggedStatement
> and LoggedPreparedStatement, then wrap the invocations to the wrapped
> instances in a try->catch, and if there's an NoSuchMethodException, return
> some default value?
>
>
>
> >
> > Derek
> >
> > On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang  >wrote:
> >
> >> Is it possible to have a  bridge trait for the Statement interface?
> >>
> >>
> >> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
> >> dchenbec...@gmail.com> wrote:
> >>
> >>> No. I hadn't foreseen this issue, but I understand the importance of
> have
> >>> Java 5 support. I'm fine with writing and maintaining multiple versions
> of
> >>> the impls for the various versions, but I wonder if there's any clean
> way to
> >>> manage this with Maven.
> >>>
> >>> Derek
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
> >>> feeder.of.the.be...@gmail.com> wrote:
> >>>
>  Crud.  This just isn't going to be easy, is it?
> 
> 
>  On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>  dchenbec...@gmail.com> wrote:
> 
> > Another issue, which may be more problematic, is that in my case I'm
> > compiling against the java.sql.Statement interface. If I remove the
> > troublesome methods so that it compiles for 1.5, it no longer
> compiles for
> > 1.6 because of the missing methods:
> >
> > [WARNING]
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> > error: class LoggedStatement needs to be abstract, since method
> isPoolable
> > in trait Statement of type ()Boolean is not defined
> > [WARNING] class LoggedStatement(underlying : Statement) extends
> > Statement with DBLog {
> > [WARNING]   ^
> > [WARNING]
> >
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> > error: class LoggedPreparedStatement needs to be abstract, since
> method
> > setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit
> is not
> > defined
> > [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
> > PreparedStatement) extends LoggedStatement(underlying) with
> > PreparedStatement {
> > [WARNING]   ^
> >
> >
> > Derek
> >
> >
> > On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> > feeder.of.the.be...@gmail.com> wrote:
> >
> >>
> >>
> >> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
> >> dchenbec...@gmail.com> wrote:
> >>
> >>> The issue (and I may be overthinking this) is that we need 1.5
> class
> >>> libraries to compile against if we want to be able to verify that
> the code
> >>> compiles under 1.5. If I, say, delete my JDK 5 install and decide
> to
> >>> reinstall it down the road, it's not going to be available without
> a
> >>> purchased license.
> >>>
> >>
> >> I can stash away a bunch of different copies of the JDK and give
> them
> >> to you when you need them.
> >>
> >> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
> >> builds with.
> >>
> >>
> >>>
> >>> Derek
> >>>
> >>>
> >>>
> >>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
> >>> feeder.of.the.be...@gmail.com> wrote:
> >>>
> 
> 
>  On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>  dchenbec...@gmail.com> wrote:
> 
> > My main concern is that after October 30, Java 5 costs money (I'm
> > guessing not a trivial amount, either). I can get the JDK right
> now, but if
> > some bug in the Java libraries pops up that would prevent things
> from
> > working, I don't know how we'll work around that.
> >
> 
>  I don't see the condition under which that could happen.  When we
>  compile against Java 1.5, we are simply defining the contract
> between our
>  classes and the library classes.  None of the library "seeps" into
> our code
>  (this is not true of Scala traits).  So, as long as the running
> library has
>  the classes/methods that we are calling, we're fine.  Compiling
> against 1.5
>  simply m

[Lift] Re: VCard parser...

[Naftoli Gugenheim]

I will also have use for a VCard builder in the near future. Thanks for the 
addition, Marius!

-
Timothy Perrett wrote:

I guess we could let him off this time ;-)

Any plans to add a vCard builder? I could really use that as it happens!

Cheers

Tim

Sent from my iPhone

On 29 Sep 2009, at 14:10, David Pollak   
wrote:

> Marius added it.  He owes the committers a beer for not going  
> through review board.
>
> On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett  > wrote:
>
> Guys,
>
> Who added the VCard parser, who ever made the commit needs to set
> there git username :-)
>
> VCard parsing is very, very cool - are there any plans for a builder
> for VCard?
>
> 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
> Surf the harmonics
>
> >



--~--~-~--~~~---~--~~
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: Java 5 support?

[Viktor Klang]

On Tue, Sep 29, 2009 at 3:47 PM, Derek Chen-Becker wrote:

> Can you elaborate on what you mean? I was actually going to look at how
> log4jdbc does it and see if I could replicate it.
>

I haven't really tried this, but if you do:

if you implement methods with the correct signatures in the LoggedStatement
and LoggedPreparedStatement, then wrap the invocations to the wrapped
instances in a try->catch, and if there's an NoSuchMethodException, return
some default value?



>
> Derek
>
> On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang wrote:
>
>> Is it possible to have a  bridge trait for the Statement interface?
>>
>>
>> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> No. I hadn't foreseen this issue, but I understand the importance of have
>>> Java 5 support. I'm fine with writing and maintaining multiple versions of
>>> the impls for the various versions, but I wonder if there's any clean way to
>>> manage this with Maven.
>>>
>>> Derek
>>>
>>>
>>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
 Crud.  This just isn't going to be easy, is it?


 On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> Another issue, which may be more problematic, is that in my case I'm
> compiling against the java.sql.Statement interface. If I remove the
> troublesome methods so that it compiles for 1.5, it no longer compiles for
> 1.6 because of the missing methods:
>
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> error: class LoggedStatement needs to be abstract, since method isPoolable
> in trait Statement of type ()Boolean is not defined
> [WARNING] class LoggedStatement(underlying : Statement) extends
> Statement with DBLog {
> [WARNING]   ^
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> error: class LoggedPreparedStatement needs to be abstract, since method
> setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is 
> not
> defined
> [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
> PreparedStatement) extends LoggedStatement(underlying) with
> PreparedStatement {
> [WARNING]   ^
>
>
> Derek
>
>
> On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> The issue (and I may be overthinking this) is that we need 1.5 class
>>> libraries to compile against if we want to be able to verify that the 
>>> code
>>> compiles under 1.5. If I, say, delete my JDK 5 install and decide to
>>> reinstall it down the road, it's not going to be available without a
>>> purchased license.
>>>
>>
>> I can stash away a bunch of different copies of the JDK and give them
>> to you when you need them.
>>
>> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
>> builds with.
>>
>>
>>>
>>> Derek
>>>
>>>
>>>
>>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>


 On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> My main concern is that after October 30, Java 5 costs money (I'm
> guessing not a trivial amount, either). I can get the JDK right now, 
> but if
> some bug in the Java libraries pops up that would prevent things from
> working, I don't know how we'll work around that.
>

 I don't see the condition under which that could happen.  When we
 compile against Java 1.5, we are simply defining the contract between 
 our
 classes and the library classes.  None of the library "seeps" into our 
 code
 (this is not true of Scala traits).  So, as long as the running 
 library has
 the classes/methods that we are calling, we're fine.  Compiling 
 against 1.5
 simply means that we have fewer calls that we can make.  If there is an
 issue in 1.5 that a user is experiencing, that is the user's issue, not
 ours.  If the code compiles (and runs tests) against 1.5 and does not
 generate the particular issue that the user is seeing under 1.6, then 
 that
 use has to contact Sun, not us.


>
> Derek
>
> On Mon, Sep 28, 2009 at 12:29 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker <
>> dchenbec

[Lift] Re: VCard parser...

[marius d.]

Oh Tim ... a VCard builder should be easier then the parser. I'll add
it hopefully in the next days/week ... and will go thru the review
board.

Damn I'm really sorry about not following the process ...

Br's,
Marius

On Sep 29, 8:50 am, "marius d."  wrote:
> Hly cow !  I owe the committers more than a
> beer. I totally forgot about review board.
>
> All, please accept my apologies.
>
> Br's,
> Marius
>
> On Sep 29, 8:27 am, Timothy Perrett  wrote:
>
> > I guess we could let him off this time ;-)
>
> > Any plans to add a vCard builder? I could really use that as it happens!
>
> > Cheers
>
> > Tim
>
> > Sent from my iPhone
>
> > On 29 Sep 2009, at 14:10, David Pollak   
> > wrote:
>
> > > Marius added it.  He owes the committers a beer for not going  
> > > through review board.
>
> > > On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett  > > > wrote:
>
> > > Guys,
>
> > > Who added the VCard parser, who ever made the commit needs to set
> > > there git username :-)
>
> > > VCard parsing is very, very cool - are there any plans for a builder
> > > for VCard?
>
> > > Cheers, Tim
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
--~--~-~--~~~---~--~~
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: VCard parser...

[marius d.]

Hly cow !  I owe the committers more than a
beer. I totally forgot about review board.

All, please accept my apologies.

Br's,
Marius

On Sep 29, 8:27 am, Timothy Perrett  wrote:
> I guess we could let him off this time ;-)
>
> Any plans to add a vCard builder? I could really use that as it happens!
>
> Cheers
>
> Tim
>
> Sent from my iPhone
>
> On 29 Sep 2009, at 14:10, David Pollak   
> wrote:
>
> > Marius added it.  He owes the committers a beer for not going  
> > through review board.
>
> > On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett  > > wrote:
>
> > Guys,
>
> > Who added the VCard parser, who ever made the commit needs to set
> > there git username :-)
>
> > VCard parsing is very, very cool - are there any plans for a builder
> > for VCard?
>
> > Cheers, Tim
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
--~--~-~--~~~---~--~~
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: Java 5 support?

[Derek Chen-Becker]

Argh. log4jdbc has two source trees, one for JDK 1.4 and one for JDK 6 :(

On Tue, Sep 29, 2009 at 7:47 AM, Derek Chen-Becker wrote:

> Can you elaborate on what you mean? I was actually going to look at how
> log4jdbc does it and see if I could replicate it.
>
> Derek
>
>
> On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang wrote:
>
>> Is it possible to have a  bridge trait for the Statement interface?
>>
>>
>> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> No. I hadn't foreseen this issue, but I understand the importance of have
>>> Java 5 support. I'm fine with writing and maintaining multiple versions of
>>> the impls for the various versions, but I wonder if there's any clean way to
>>> manage this with Maven.
>>>
>>> Derek
>>>
>>>
>>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>
 Crud.  This just isn't going to be easy, is it?


 On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> Another issue, which may be more problematic, is that in my case I'm
> compiling against the java.sql.Statement interface. If I remove the
> troublesome methods so that it compiles for 1.5, it no longer compiles for
> 1.6 because of the missing methods:
>
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
> error: class LoggedStatement needs to be abstract, since method isPoolable
> in trait Statement of type ()Boolean is not defined
> [WARNING] class LoggedStatement(underlying : Statement) extends
> Statement with DBLog {
> [WARNING]   ^
> [WARNING]
> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
> error: class LoggedPreparedStatement needs to be abstract, since method
> setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is 
> not
> defined
> [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
> PreparedStatement) extends LoggedStatement(underlying) with
> PreparedStatement {
> [WARNING]   ^
>
>
> Derek
>
>
> On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> The issue (and I may be overthinking this) is that we need 1.5 class
>>> libraries to compile against if we want to be able to verify that the 
>>> code
>>> compiles under 1.5. If I, say, delete my JDK 5 install and decide to
>>> reinstall it down the road, it's not going to be available without a
>>> purchased license.
>>>
>>
>> I can stash away a bunch of different copies of the JDK and give them
>> to you when you need them.
>>
>> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
>> builds with.
>>
>>
>>>
>>> Derek
>>>
>>>
>>>
>>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>


 On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> My main concern is that after October 30, Java 5 costs money (I'm
> guessing not a trivial amount, either). I can get the JDK right now, 
> but if
> some bug in the Java libraries pops up that would prevent things from
> working, I don't know how we'll work around that.
>

 I don't see the condition under which that could happen.  When we
 compile against Java 1.5, we are simply defining the contract between 
 our
 classes and the library classes.  None of the library "seeps" into our 
 code
 (this is not true of Scala traits).  So, as long as the running 
 library has
 the classes/methods that we are calling, we're fine.  Compiling 
 against 1.5
 simply means that we have fewer calls that we can make.  If there is an
 issue in 1.5 that a user is experiencing, that is the user's issue, not
 ours.  If the code compiles (and runs tests) against 1.5 and does not
 generate the particular issue that the user is seeing under 1.6, then 
 that
 use has to contact Sun, not us.


>
> Derek
>
> On Mon, Sep 28, 2009 at 12:29 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> I was just about to work on issue #67 (build breaks on Java 5),
>>> but when I went to get a Java 5 JDK to compile/test with, Sun says 
>>> that it's

[Lift] Re: Java 5 support?

[Derek Chen-Becker]

Can you elaborate on what you mean? I was actually going to look at how
log4jdbc does it and see if I could replicate it.

Derek

On Tue, Sep 29, 2009 at 5:22 AM, Viktor Klang wrote:

> Is it possible to have a  bridge trait for the Statement interface?
>
>
> On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker  > wrote:
>
>> No. I hadn't foreseen this issue, but I understand the importance of have
>> Java 5 support. I'm fine with writing and maintaining multiple versions of
>> the impls for the various versions, but I wonder if there's any clean way to
>> manage this with Maven.
>>
>> Derek
>>
>>
>> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Crud.  This just isn't going to be easy, is it?
>>>
>>>
>>> On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
 Another issue, which may be more problematic, is that in my case I'm
 compiling against the java.sql.Statement interface. If I remove the
 troublesome methods so that it compiles for 1.5, it no longer compiles for
 1.6 because of the missing methods:

 [WARNING]
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
 error: class LoggedStatement needs to be abstract, since method isPoolable
 in trait Statement of type ()Boolean is not defined
 [WARNING] class LoggedStatement(underlying : Statement) extends
 Statement with DBLog {
 [WARNING]   ^
 [WARNING]
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
 error: class LoggedPreparedStatement needs to be abstract, since method
 setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
 defined
 [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
 PreparedStatement) extends LoggedStatement(underlying) with
 PreparedStatement {
 [WARNING]   ^


 Derek


 On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
 feeder.of.the.be...@gmail.com> wrote:

>
>
> On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
> dchenbec...@gmail.com> wrote:
>
>> The issue (and I may be overthinking this) is that we need 1.5 class
>> libraries to compile against if we want to be able to verify that the 
>> code
>> compiles under 1.5. If I, say, delete my JDK 5 install and decide to
>> reinstall it down the road, it's not going to be available without a
>> purchased license.
>>
>
> I can stash away a bunch of different copies of the JDK and give them
> to you when you need them.
>
> A 32 bit Linux JDK 1.5 should be enough to at least do smoke test
> builds with.
>
>
>>
>> Derek
>>
>>
>>
>> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
 My main concern is that after October 30, Java 5 costs money (I'm
 guessing not a trivial amount, either). I can get the JDK right now, 
 but if
 some bug in the Java libraries pops up that would prevent things from
 working, I don't know how we'll work around that.

>>>
>>> I don't see the condition under which that could happen.  When we
>>> compile against Java 1.5, we are simply defining the contract between 
>>> our
>>> classes and the library classes.  None of the library "seeps" into our 
>>> code
>>> (this is not true of Scala traits).  So, as long as the running library 
>>> has
>>> the classes/methods that we are calling, we're fine.  Compiling against 
>>> 1.5
>>> simply means that we have fewer calls that we can make.  If there is an
>>> issue in 1.5 that a user is experiencing, that is the user's issue, not
>>> ours.  If the code compiles (and runs tests) against 1.5 and does not
>>> generate the particular issue that the user is seeing under 1.6, then 
>>> that
>>> use has to contact Sun, not us.
>>>
>>>

 Derek

 On Mon, Sep 28, 2009 at 12:29 PM, David Pollak <
 feeder.of.the.be...@gmail.com> wrote:

>
>
> On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker <
> dchenbec...@gmail.com> wrote:
>
>> I was just about to work on issue #67 (build breaks on Java 5),
>> but when I went to get a Java 5 JDK to compile/test with, Sun says 
>> that it's
>> EOL as of October 30, 2009. I don't have a problem fixing things to 
>> work
>> with Java 5, but I don't want to do work that's going to be tossed 
>> out in a
>> month.
>>
>>
> Lift will be JDK 1.5 compatible for at least 1 year (and pro

[Lift] Re: Unwarranted dependencies in lift-record

[Tim Nelson]

Aren't most of the dependencies that Record relies on coming from the RDBMS
code?

Would it make sense to move that code to a separate module
(lift-record-rdbms)?

I don't like all of the dependencies that Record relies on because I'm not
using the RDBMS code, I'm using a custom Record back end.

It would be nice to have Record a completely separate module, but I think at
least moving the RDBMS and therefore the Mapper dependency to a separate
module would be very easy and remove most of the dependencies.

Tim

On Tue, Sep 29, 2009 at 8:01 AM, Timothy Perrett wrote:

>
> This is my point - record should be more abstract... we dont want it
> depending on all that stuff its pointless.
>
> @dpp or @marius... what are your thoughts?
>
> Cheers, Tim
>
> On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote:
>
> >
> > lift-record depends on lift-mapper and since lift-mapper is heavily
> > dependent on lift-webkit, lift-record ends up depending on lift-webkit
> > as well.
> >
> > So at the moment, lift-record would end up depending on lift-webkit
> > (and
> > lift-widget!) indirectly even if you remove reference to lift-webkit
> > (superfluous) from lift-record pom.
> >
> > lift-widget part is simpler (just one reference in MappedInt, intend
> > to
> > take up later if somebody else don't beat me) but lift-webkit looks
> > lot
> > of work.
> >
> > Cheers, Indrajit
> >
> >
> > On 29/09/09 3:12 PM, Timothy Perrett wrote:
> >>
> >> Guys,
> >>
> >> I just noticed that lift-record depends on lift-webket because of
> >> some
> >> calls to S... IMHO, we need to remove this because thats simply too
> >> tight a coupling between the webkit and an abstract persistence
> >> interface like record.
> >>
> >> For instance, one record abstraction I wrote isn't even used in
> >> webapps...
> >>
> >> 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: VCard parser...

[Timothy Perrett]

I guess we could let him off this time ;-)

Any plans to add a vCard builder? I could really use that as it happens!

Cheers

Tim

Sent from my iPhone

On 29 Sep 2009, at 14:10, David Pollak   
wrote:

> Marius added it.  He owes the committers a beer for not going  
> through review board.
>
> On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett  > wrote:
>
> Guys,
>
> Who added the VCard parser, who ever made the commit needs to set
> there git username :-)
>
> VCard parsing is very, very cool - are there any plans for a builder
> for VCard?
>
> 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
> Surf the harmonics
>
> >

--~--~-~--~~~---~--~~
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: VCard parser...

[David Pollak]

Marius added it.  He owes the committers a beer for not going through review
board.

On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett wrote:

>
> Guys,
>
> Who added the VCard parser, who ever made the commit needs to set
> there git username :-)
>
> VCard parsing is very, very cool - are there any plans for a builder
> for VCard?
>
> 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
Surf the harmonics

--~--~-~--~~~---~--~~
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: Can we deploy lift webapp on Google App Engine?

[TylerWeir]

http://lift-example.appspot.com

There are caveats though, the major one is the lack of actors.

On Sep 29, 8:53 am, justss  wrote:
> Hi All,
>
> I'm brand new to Scala and lift framework. I have created a very
> simple hello world web app in lift framework and deployed it
> successfully on tomcat.
> Now I want to know whether I can deploy the same lift application on
> Google app engine or not? I have the war ready, so in I thought that
> it should have been as simple as deploying any war on tomcat or
> websphere!!! But I see it is not ;-(
> Can anyone please guide me as to how I can deploy my mini lift app on
> GAE?
>
> Thanks in advance.
> A Newbie
--~--~-~--~~~---~--~~
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] Error reporting when snippet method not found

[Kjetil Valstadsve]

Hi, I know I just raved about #liftweb error reporting on Twitter,
but... now that I found out what was wrong, I still have a gripe about
it. I am very unforgiving on error reporting logic, but most of the
time people's error handling is so hopeless that I just throw up my
arms and emit some mock Italian. When I bother to post this complaint,
it's because I think lift is doing great and I want to help improve
it.

The case occurs when a  tag fails to match the bar
method in Foo. The rendered red box (which is very nice) tells me that
the method was not found. However, it would be very handy if it
handled the special case of "method found but the signature is wrong".
As it is, I got the same message when I definitely had the method, per
se. Before I knew it, I was on a quest to find the outdated class
file, rebuilding here and there to make sure I had the war file in
synch with my code.

In my case, I hadn't specified the return type, and I was mistakenly
using foreach instead of flatMap inside the method, implicitly giving
Unit as return type. So lift was completely right, the method could
not be found. However, this is siding with the compiler against the
human, if you know what I mean. Also, since you cannot overload a
method by varying only the return type, it is a pretty safe assumption
that the mis-typed method is the one the user meant to use, especially
if it takes the correct argument list, too.

Kjetil

--~--~-~--~~~---~--~~
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] Can we deploy lift webapp on Google App Engine?

[justss]

Hi All,

I'm brand new to Scala and lift framework. I have created a very
simple hello world web app in lift framework and deployed it
successfully on tomcat.
Now I want to know whether I can deploy the same lift application on
Google app engine or not? I have the war ready, so in I thought that
it should have been as simple as deploying any war on tomcat or
websphere!!! But I see it is not ;-(
Can anyone please guide me as to how I can deploy my mini lift app on
GAE?

Thanks in advance.
A Newbie

--~--~-~--~~~---~--~~
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: Unwarranted dependencies in lift-record

[Timothy Perrett]

This is my point - record should be more abstract... we dont want it  
depending on all that stuff its pointless.

@dpp or @marius... what are your thoughts?

Cheers, Tim

On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote:

>
> lift-record depends on lift-mapper and since lift-mapper is heavily
> dependent on lift-webkit, lift-record ends up depending on lift-webkit
> as well.
>
> So at the moment, lift-record would end up depending on lift-webkit  
> (and
> lift-widget!) indirectly even if you remove reference to lift-webkit
> (superfluous) from lift-record pom.
>
> lift-widget part is simpler (just one reference in MappedInt, intend  
> to
> take up later if somebody else don't beat me) but lift-webkit looks  
> lot
> of work.
>
> Cheers, Indrajit
>
>
> On 29/09/09 3:12 PM, Timothy Perrett wrote:
>>
>> Guys,
>>
>> I just noticed that lift-record depends on lift-webket because of  
>> some
>> calls to S... IMHO, we need to remove this because thats simply too
>> tight a coupling between the webkit and an abstract persistence
>> interface like record.
>>
>> For instance, one record abstraction I wrote isn't even used in
>> webapps...
>>
>> 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] Beginner question, how to run Javascript from function?

[philip]

Hi, I want to run some javascript to initialize my component which is
a YUI richtexteditor.
Can help? This seems to be the wrong way to do it.

Thanks, Philip

class RichEditor
{
  def show = 


{ JsCmds.Run("alert('hi')") }

}

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Stuart Roebuck]

Okay, I think I've now found the reference I was looking for...



Stuart.

On Sep 29, 10:35 am, Stuart Roebuck  wrote:
> Apologies if I've missed something obvious but my web search hasn't
> turned anything up...
>
> What are the Scala Actors instability issues? I'm in the process of
> doing some major Scala development work and this comment raises
> concerns that I'd like to understand.
>
> Best,
>
> Stuart
>
> On Sep 29, 3:30 am, David Pollak 
> wrote:
>
>
>
> > Folks,
>
> > Given the continued instability of Scala Actors, I've decided to remove them
> > from Lift.
>
> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
> > But, you'll also be able to use Akka Actors to power Lift's CometActors.
> > Specifically, I'm working with Jonas to make sure that we share a common
> > interface to Actors.
>
> > I've gotten Lift nearly completely migrated over to Lift's Actors on the
> > dpp_wip_actorize branch.  
> > Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> > There will be some breaking changes to your applications.  Specifically:
>
> >    - Box will be moved to a new package, net.liftweb.base (this is where the
> >    interface for Actors will live as well)
> >    - If you make any assumptions about your CometActors being Scala Actors
> >    (e.g., using linking), you will have to rewrite this code
> >    - Some methods in Lift that currently take Scala Actors as parameters
> >    will take Lift Actors (e.g., ActorPing)
>
> > There will be a parallel Maven repository with the new Lift Actor stuff in
> > it so you will be able to build you apps against the new code before the
> > official switch-over.
>
> > Milestone 6 (which should be out next week) will be based on the existing
> > Actor model.  After we get feedback from the community about the new Actor
> > stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>
> > Questions, thoughts, or comments?
>
> > Thanks,
>
> > David
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics

--~--~-~--~~~---~--~~
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: Removing Scala Actors from Lift

[Stefan Langer]

Has this been communicated? And if is there a bug number associated with
this issue?

Regards
Stefan

--~--~-~--~~~---~--~~
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: Unwarranted dependencies in lift-record

[Indrajit Raychaudhuri]

lift-record depends on lift-mapper and since lift-mapper is heavily 
dependent on lift-webkit, lift-record ends up depending on lift-webkit 
as well.

So at the moment, lift-record would end up depending on lift-webkit (and 
lift-widget!) indirectly even if you remove reference to lift-webkit 
(superfluous) from lift-record pom.

lift-widget part is simpler (just one reference in MappedInt, intend to 
take up later if somebody else don't beat me) but lift-webkit looks lot 
of work.

Cheers, Indrajit


On 29/09/09 3:12 PM, Timothy Perrett wrote:
>
> Guys,
>
> I just noticed that lift-record depends on lift-webket because of some
> calls to S... IMHO, we need to remove this because thats simply too
> tight a coupling between the webkit and an abstract persistence
> interface like record.
>
> For instance, one record abstraction I wrote isn't even used in
> webapps...
>
> 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: Java 5 support?

[Viktor Klang]

Is it possible to have a  bridge trait for the Statement interface?

On Tue, Sep 29, 2009 at 12:16 AM, Derek Chen-Becker
wrote:

> No. I hadn't foreseen this issue, but I understand the importance of have
> Java 5 support. I'm fine with writing and maintaining multiple versions of
> the impls for the various versions, but I wonder if there's any clean way to
> manage this with Maven.
>
> Derek
>
>
> On Mon, Sep 28, 2009 at 4:00 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Crud.  This just isn't going to be easy, is it?
>>
>>
>> On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker > > wrote:
>>
>>> Another issue, which may be more problematic, is that in my case I'm
>>> compiling against the java.sql.Statement interface. If I remove the
>>> troublesome methods so that it compiles for 1.5, it no longer compiles for
>>> 1.6 because of the missing methods:
>>>
>>> [WARNING]
>>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
>>> error: class LoggedStatement needs to be abstract, since method isPoolable
>>> in trait Statement of type ()Boolean is not defined
>>> [WARNING] class LoggedStatement(underlying : Statement) extends Statement
>>> with DBLog {
>>> [WARNING]   ^
>>> [WARNING]
>>> /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
>>> error: class LoggedPreparedStatement needs to be abstract, since method
>>> setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
>>> defined
>>> [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
>>> PreparedStatement) extends LoggedStatement(underlying) with
>>> PreparedStatement {
>>> [WARNING]   ^
>>>
>>>
>>> Derek
>>>
>>>
>>> On Mon, Sep 28, 2009 at 2:29 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>


 On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> The issue (and I may be overthinking this) is that we need 1.5 class
> libraries to compile against if we want to be able to verify that the code
> compiles under 1.5. If I, say, delete my JDK 5 install and decide to
> reinstall it down the road, it's not going to be available without a
> purchased license.
>

 I can stash away a bunch of different copies of the JDK and give them to
 you when you need them.

 A 32 bit Linux JDK 1.5 should be enough to at least do smoke test builds
 with.


>
> Derek
>
>
>
> On Mon, Sep 28, 2009 at 1:33 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker <
>> dchenbec...@gmail.com> wrote:
>>
>>> My main concern is that after October 30, Java 5 costs money (I'm
>>> guessing not a trivial amount, either). I can get the JDK right now, 
>>> but if
>>> some bug in the Java libraries pops up that would prevent things from
>>> working, I don't know how we'll work around that.
>>>
>>
>> I don't see the condition under which that could happen.  When we
>> compile against Java 1.5, we are simply defining the contract between our
>> classes and the library classes.  None of the library "seeps" into our 
>> code
>> (this is not true of Scala traits).  So, as long as the running library 
>> has
>> the classes/methods that we are calling, we're fine.  Compiling against 
>> 1.5
>> simply means that we have fewer calls that we can make.  If there is an
>> issue in 1.5 that a user is experiencing, that is the user's issue, not
>> ours.  If the code compiles (and runs tests) against 1.5 and does not
>> generate the particular issue that the user is seeing under 1.6, then 
>> that
>> use has to contact Sun, not us.
>>
>>
>>>
>>> Derek
>>>
>>> On Mon, Sep 28, 2009 at 12:29 PM, David Pollak <
>>> feeder.of.the.be...@gmail.com> wrote:
>>>


 On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker <
 dchenbec...@gmail.com> wrote:

> I was just about to work on issue #67 (build breaks on Java 5), but
> when I went to get a Java 5 JDK to compile/test with, Sun says that 
> it's EOL
> as of October 30, 2009. I don't have a problem fixing things to work 
> with
> Java 5, but I don't want to do work that's going to be tossed out in a
> month.
>
>
 Lift will be JDK 1.5 compatible for at least 1 year (and probably
 longer).  LinkedIn and SAP are both 1.5 shops.  There are tons of 
 other Bay
 Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.  
 For the
 next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks == 
 1.5.

 It will not be lost work.


> Derek
>>>

[Lift] Re: Removing Scala Actors from Lift

[Timothy Perrett]

Basically there are parts of lift where we are doing high volume  
creation and destruction of actors and over time, they leak memory  
ever-so-slightly which increases heap size incrementally. Of course,  
leaking memory is a bad thing for long-running processes and until  
EPFL fix there implementation we've decided to go and fix it ourselves.

Does that clear it up for you?

Cheers, Tim

On 29 Sep 2009, at 10:35, Stuart Roebuck wrote:

>
> Apologies if I've missed something obvious but my web search hasn't
> turned anything up...
>
> What are the Scala Actors instability issues? I'm in the process of
> doing some major Scala development work and this comment raises
> concerns that I'd like to understand.
>
> Best,
>
> Stuart
>
> On Sep 29, 3:30 am, David Pollak 
> wrote:
>> Folks,
>>
>> Given the continued instability of Scala Actors, I've decided to  
>> remove them
>> from Lift.
>>
>> Specifically, I'm migrating CometActors to sit on top of Lift's  
>> Actors.
>> But, you'll also be able to use Akka Actors to power Lift's  
>> CometActors.
>> Specifically, I'm working with Jonas to make sure that we share a  
>> common
>> interface to Actors.
>>
>> I've gotten Lift nearly completely migrated over to Lift's Actors  
>> on the
>> dpp_wip_actorize branch.  
>> Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
>>
>> There will be some breaking changes to your applications.   
>> Specifically:
>>
>>- Box will be moved to a new package, net.liftweb.base (this is  
>> where the
>>interface for Actors will live as well)
>>- If you make any assumptions about your CometActors being Scala  
>> Actors
>>(e.g., using linking), you will have to rewrite this code
>>- Some methods in Lift that currently take Scala Actors as  
>> parameters
>>will take Lift Actors (e.g., ActorPing)
>>
>> There will be a parallel Maven repository with the new Lift Actor  
>> stuff in
>> it so you will be able to build you apps against the new code  
>> before the
>> official switch-over.
>>
>> Milestone 6 (which should be out next week) will be based on the  
>> existing
>> Actor model.  After we get feedback from the community about the  
>> new Actor
>> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>>
>> Questions, thoughts, or comments?
>>
>> Thanks,
>>
>> David
>>
>> --
>> Lift, the simply functional web frameworkhttp://liftweb.net
>> Beginning Scalahttp://www.apress.com/book/view/1430219890
>> Follow me:http://twitter.com/dpp
>> Surf the harmonics
>
> >
>


--~--~-~--~~~---~--~~
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] Unwarranted dependencies in lift-record

[Timothy Perrett]

Guys,

I just noticed that lift-record depends on lift-webket because of some
calls to S... IMHO, we need to remove this because thats simply too
tight a coupling between the webkit and an abstract persistence
interface like record.

For instance, one record abstraction I wrote isn't even used in
webapps...

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: Removing Scala Actors from Lift

[Stuart Roebuck]

Apologies if I've missed something obvious but my web search hasn't
turned anything up...

What are the Scala Actors instability issues? I'm in the process of
doing some major Scala development work and this comment raises
concerns that I'd like to understand.

Best,

Stuart

On Sep 29, 3:30 am, David Pollak 
wrote:
> Folks,
>
> Given the continued instability of Scala Actors, I've decided to remove them
> from Lift.
>
> Specifically, I'm migrating CometActors to sit on top of Lift's Actors.
> But, you'll also be able to use Akka Actors to power Lift's CometActors.
> Specifically, I'm working with Jonas to make sure that we share a common
> interface to Actors.
>
> I've gotten Lift nearly completely migrated over to Lift's Actors on the
> dpp_wip_actorize branch.  
> Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> There will be some breaking changes to your applications.  Specifically:
>
>    - Box will be moved to a new package, net.liftweb.base (this is where the
>    interface for Actors will live as well)
>    - If you make any assumptions about your CometActors being Scala Actors
>    (e.g., using linking), you will have to rewrite this code
>    - Some methods in Lift that currently take Scala Actors as parameters
>    will take Lift Actors (e.g., ActorPing)
>
> There will be a parallel Maven repository with the new Lift Actor stuff in
> it so you will be able to build you apps against the new code before the
> official switch-over.
>
> Milestone 6 (which should be out next week) will be based on the existing
> Actor model.  After we get feedback from the community about the new Actor
> stuff, we will switch -SNAPSHOT over to the new Actor stuff.
>
> Questions, thoughts, or comments?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--~--~-~--~~~---~--~~
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: Seeking for Simple Sample .scala and .html that mimics CRUDify/Seam-Gen

[Randinn]

Also make sure to take a look at the wiki for Lift on Github there are
some good info there as well

http://wiki.github.com/dpp/liftweb


--~--~-~--~~~---~--~~
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] VCard parser...

[Timothy Perrett]

Guys,

Who added the VCard parser, who ever made the commit needs to set
there git username :-)

VCard parsing is very, very cool - are there any plans for a builder
for VCard?

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: Removing Scala Actors from Lift

[Timothy Perrett]

David,

I'm not 100% clear on having Box not in lift-util? Lift-util then  
depends on lift-base which appears to be dependency bloat to me

I use lift-util in several non-lift apps and libs - none of those  
would need lift-actors

Cheers, Tim

Sent from my iPhone

On 29 Sep 2009, at 03:30, David Pollak   
wrote:

> Folks,
>
> Given the continued instability of Scala Actors, I've decided to  
> remove them from Lift.
>
> Specifically, I'm migrating CometActors to sit on top of Lift's  
> Actors.  But, you'll also be able to use Akka Actors to power Lift's  
> CometActors.  Specifically, I'm working with Jonas to make sure that  
> we share a common interface to Actors.
>
> I've gotten Lift nearly completely migrated over to Lift's Actors on  
> the dpp_wip_actorize branch.  See 
> http://github.com/dpp/liftweb/tree/dpp_wip_actorize
>
> There will be some breaking changes to your applications.   
> Specifically:
> Box will be moved to a new package, net.liftweb.base (this is where  
> the interface for Actors will live as well)
> If you make any assumptions about your CometActors being Scala  
> Actors (e.g., using linking), you will have to rewrite this code
> Some methods in Lift that currently take Scala Actors as parameters  
> will take Lift Actors (e.g., ActorPing)
> There will be a parallel Maven repository with the new Lift Actor  
> stuff in it so you will be able to build you apps against the new  
> code before the official switch-over.
>
> Milestone 6 (which should be out next week) will be based on the  
> existing Actor model.  After we get feedback from the community  
> about the new Actor stuff, we will switch -SNAPSHOT over to the new  
> Actor stuff.
>
> Questions, thoughts, or comments?
>
> Thanks,
>
> David
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---