[Lift] Re: Creating calculated fields in mapper

2009-10-19 Thread Jeppe Nejsum Madsen

On Thu, Oct 15, 2009 at 9:14 PM, Naftoli Gugenheim naftoli...@gmail.com wrote:

 Have you made any progress?

Sorry for the late reply. No, I've been sidetracked, but hope to look
into it this week

/Jeppe

--~--~-~--~~~---~--~~
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] Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread Neil.Lv

Hi all,

   Why the liftweb doesn't use MySQL as the default database ?

   Thanks very much !

Cheers,
  Neil

--~--~-~--~~~---~--~~
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: Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread Timothy Perrett

Because MySQL is not embedable - with derby its a true out of the box  
experience. Switching to mysql is easy and in the examples...

Cheers, Tim

On 19 Oct 2009, at 09:10, Neil.Lv wrote:


 Hi all,

   Why the liftweb doesn't use MySQL as the default database ?

   Thanks very much !

 Cheers,
  Neil

 



--~--~-~--~~~---~--~~
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: Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread Margaret

GPL


-
mawei...@gmail.com
13585201588
http://maweis.com




On Mon, Oct 19, 2009 at 4:10 PM, Neil.Lv anim...@gmail.com wrote:

 Hi all,

   Why the liftweb doesn't use MySQL as the default database ?

   Thanks very much !

 Cheers,
  Neil

 


--~--~-~--~~~---~--~~
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: Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread opyate

Hi Neil,

Lift as a web framework is agnostic of the underlying database type.
That allows you, the developer, to choose which database type to use,
e.g. PostgresQL (far superior ;-) or even Oracle, MSSQL.

Thanks,
Juan

On Oct 19, 9:10 am, Neil.Lv anim...@gmail.com wrote:
 Hi all,

    Why the liftweb doesn't use MySQL as the default database ?

    Thanks very much !

 Cheers,
   Neil

--~--~-~--~~~---~--~~
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] reverse-Schemifier: generating BaseMapper instances from schema/SQL/JPA

2009-10-19 Thread opyate

Hello Lifters,

Related:
http://groups.google.com/group/liftweb/browse_thread/thread/20051762b58f0083/b3329f33e8f3dc73?lnk=gstq=existing+database#b3329f33e8f3dc73

I would like to generate (at run-time) BaseMapper instances of a
schema. I know I can generate the JPA beans from a schema (using
Hibernate3 tools - thanks to Greg Meredith for pointing this out), but
then I'd like to convert these to BaseMapper instances so I can use
the .toForm: NodeSeq functionality. Or schema to BaseMapper directly?
Schemifier in reverse, perhaps.

Use case: I'm building an open source tool with which you can define
external databases to manage. I wouldn't know the details of these
databases at design/compile time, and thusly would like to be able to
just point to a database, point to a table (related tables if foreign
key exists), dynamically generate a form for the table/row, edit,
save. I know this sounds really far-fetched, and fragile. I just want
to see if it's viable :-)

With javax.sql I can generate the form, hence the SQL and then call an
insert/update on the target DB, but I'd prefer a Mapper solution.

CODE-START
Class.forName (com.mysql.jdbc.Driver).newInstance() // could be any
db type
val sConnection = jdbc:mysql://host:3306/dbname // some DB known at
run-time
val conn: Connection = DriverManager.getConnection(sConnection,
db_user, db_password)
val sqlStatement: Statement = conn.createStatement()
val rs: ResultSet = sqlStatement.executeQuery(select * from  +
someRuntimeTable +  limit 1)
val rsm: ResultSetMetaData = rs.getMetaData()
// now we have a slew of methods at our disposal which tells us things
about the table, for example:
rsm.isAutoIncrement(1) // example
for (i - 1 to rsm.getColumnCount()) {
  rsm.getColumnLabel(i) // example
  rsm.getColumnTypeName(i) // example
}
CODE-END

Thanks,
Juan

--~--~-~--~~~---~--~~
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: Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread Viktor Klang
Hi Neil,

I'd also like to add that MySQL is GPL.

On Mon, Oct 19, 2009 at 10:10 AM, Neil.Lv anim...@gmail.com wrote:


 Hi all,

   Why the liftweb doesn't use MySQL as the default database ?

   Thanks very much !

 Cheers,
  Neil

 



-- 
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.kl...@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

--~--~-~--~~~---~--~~
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: Including the class name in the JSON field

2009-10-19 Thread Joni Freeman

Added a way to change how 'type hints' are processed. The default is
NoTypeHints which will never output 'jsonClass' field. Then there's
ShortTypeHints and FullTypeHints.

implicit val formats = Serialization.formats(ShortTypeHints(classOf
[Fish] :: classOf[Dog] :: Nil))

- { jsonClass:Fish, ... }

implicit val formats = Serialization.formats(FullTypeHints(classOf
[Animal] :: Nil))

- { jsonClass:com.example.Fish, ... }

TypeHints trait can be used to reduce couplings (as suggested by
Steve).

Cheers Joni

On 18 loka, 23:46, Joni Freeman freeman.j...@gmail.com wrote:
 There's now some support to deserialize parameterized types in that
 experimental branch. For instance, these all work:

   implicit val formats = Serialization.formats(TypeHints(classOf
 [Animal] :: Nil))

   case class Animals(animals: List[Animal])
   trait Animal
   case class Dog(name: String) extends Animal
   case class Fish(weight: Double) extends Animal

   case class Objs(objects: List[Obj[_]])
   case class Obj[A](a: A)

   val animals = Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
 Nil)
   val ser = swrite(animals)
   read[Animals](ser) mustEqual animals

   val objs = Objs(Obj(Fish(1.2)) :: Obj(Dog(pluto)) :: Nil)
   val ser = swrite(objs)
   read[Objs](ser) mustEqual objs

   val t: (Animal, Animal) = (Fish(1.5), Dog(pluto))
   val ser = swrite(t)
   read[(Animal, Animal)](ser) mustEqual t

 The first line (implicit val formats ...) configures the serialization
 to output type hint (jsonClass field) for all instances of class
 Animal. This is required since above examples use Animal's in
 polymorphic way. Comments?

 Cheers Joni

 On 18 loka, 01:27, David Pollak feeder.of.the.be...@gmail.com wrote:

  On Sat, Oct 17, 2009 at 7:54 AM, Joni Freeman freeman.j...@gmail.comwrote:

   I've been thinking this feature today a bit too. Marius raises an
   important point. Adding type information and more complex
   serialization scheme will introduce couplings, making it for instance
   more difficult to deserializeJSONusing a different language or
   toolkit. On a positive side, we might get support for other
   parameterized types too (tuples for instance).

   I pushed an experimental branch (joni_issue_108) which contains
   serialization part of this feature (the easy part really). It adds
   'jsonClass' field to objects.

    case class Animals(animals: List[Animal])
    trait Animal
    case class Dog(name: String) extends Animal
    case class Fish(weight: Double) extends Animal

    scala write(Animals(Dog(pluto) :: Fish(1.2) :: Dog(devil) ::
   Nil))
    res0: String = {jsonClass:Animals,animals:
   [{jsonClass:Dog,name:pluto},{jsonClass:Fish,weight:1.2},
   {jsonClass:Dog,name:devil}]}

   Possible actions:

   * Do not support parameterized types (status quo)

    + Simple scheme, easy to serialize in language agnostic way
    - Limited

  I like this option.  I'm not looking for a full Java serialization style
  solution.  But having hints as to the type of the particularJSONobject
  would be helpful.  Being able to register a jsonClass - Scala class
  deserializer makes sense.  Being able to specify a Scala class - class name
  is a good thing (with the default being the actual class name without the
  package).

   * Add full type information when serializing/deserializing

    + Opens possibility to deserialize polymorphic types
    + Deserialization can be done without any explicit type information
   (read(...) vs. read[ExpectedType](...))
    - Introduces couplings
    - This is still not a generic serialization solution, there's still
   a lot of Scala classes which can't be deserialized

   * Support both schemes

    + Moar choice
    - Choice it not necessarily a good thing (adds complexity etc.)

   Cheers Joni

   On 17 loka, 11:40, Marius marius.dan...@gmail.com wrote:
Hmmm ... I wonder if heterogeneous lists should be supported. I also
wonder if type knowledge inJSONis a good thing to do as it seems to
me that we're bringing knowledge from another domain creating
couplings. I'm not sure if there is a different way to solve this ...
it just doesn't feel completely right to me ... but this doesn't
necessarily mean it is not right :)

Br's,
Marius

On Oct 15, 1:47 am, David Pollak feeder.of.the.be...@gmail.com
wrote:

 Folks,
 What are thoughts on including (perhaps optionally) the name of the
   case
 class in an additionalJSONfield so that one can reconstruct a list
   that
 contains many different types?

 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 frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics

[Lift] Re: Nested 'react'

2009-10-19 Thread Philipp

 so when I'm running load test I see that number of threads that used
 by dispatcher is growing (so far up to 200) and performance is going
 down. Most of them are always in blocked state
 Dispatcher's Actor queue never should be more that few messages as I'm
 using QoS = 5 on channel and sending ack only when worker picks up
 message, also I have just a few workers
 When I'm looking to heap, I can see that more than 80% (up to 95%) are
 scala.actors.FJTaskRunner$VolatileTaskRef objects and number of
 those is quickly growing (have 1'000'000 right now).

 What can be a cause of spawning so many threads and large number of
 'scala.actors.FJTaskRunner$VolatileTaskRef' objects (GC doesn't kill
 them)?

The pool resizing logic was creating new threads too eagerly. This has
been fixed in Scala 2.7.7.RC1 (it also replaces `FJTaskRunner` with
`java.util.concurrent.ThreadPoolExecutor`).

Philipp

--~--~-~--~~~---~--~~
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: edit: What happened to JsonCmd?

2009-10-19 Thread Chris

So I'm all fixed now wrt JsonCmd's new location.  I noticed that this
change isn't documented on the github wiki.  Is there a process for
doing that, or can I just edit the page?

Thanks

On Oct 15, 8:16 pm, Ross Mellgren dri...@gmail.com wrote:
 The class file names in the jar are determined by the class name /  
 scope / access modifiers and other such nonsense, so unlike java  
 there's not even a vague 1 : 1 correlation between source file names  
 and class file names.

 So,JsonCmdis in Misc.scala, but it will be emitted asJsonCmd.class  
 (along with HasParams.class, etc).

 -Ross

 On Oct 15, 2009, at 10:46 PM, Chris wrote:



  Well, I pulled all the files from

 http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M6/

  and I do see Misc.scala in lift-util-1.1-M6-sources.jar  but not in
  lift-util-1.1-M6.jar.  The SHA1 sum matches what was on the server for
  that JAR.  Could it have been packaged wrong?

  Thanks

  On Oct 15, 7:55 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
  Ying-Kwang's got it right.

  On Wed, Oct 14, 2009 at 9:15 PM, Chris coldfusio...@gmail.com  
  wrote:

  I get

  error: Misc is not a member of net.liftweb.util

  when I try that.  I don't see the Misc class/object in the API docs
  either.  Is there anything else I should try?

  Thanks

--~--~-~--~~~---~--~~
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: edit: What happened to JsonCmd?

2009-10-19 Thread David Pollak
On Mon, Oct 19, 2009 at 9:04 AM, Chris coldfusio...@gmail.com wrote:


 So I'm all fixed now wrt JsonCmd's new location.  I noticed that this
 change isn't documented on the github wiki.  Is there a process for
 doing that, or can I just edit the page?


You can edit the page



 Thanks

 On Oct 15, 8:16 pm, Ross Mellgren dri...@gmail.com wrote:
  The class file names in the jar are determined by the class name /
  scope / access modifiers and other such nonsense, so unlike java
  there's not even a vague 1 : 1 correlation between source file names
  and class file names.
 
  So,JsonCmdis in Misc.scala, but it will be emitted asJsonCmd.class
  (along with HasParams.class, etc).
 
  -Ross
 
  On Oct 15, 2009, at 10:46 PM, Chris wrote:
 
 
 
   Well, I pulled all the files from
 
  http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M6/
 
   and I do see Misc.scala in lift-util-1.1-M6-sources.jar  but not in
   lift-util-1.1-M6.jar.  The SHA1 sum matches what was on the server for
   that JAR.  Could it have been packaged wrong?
 
   Thanks
 
   On Oct 15, 7:55 am, David Pollak feeder.of.the.be...@gmail.com
   wrote:
   Ying-Kwang's got it right.
 
   On Wed, Oct 14, 2009 at 9:15 PM, Chris coldfusio...@gmail.com
   wrote:
 
   I get
 
   error: Misc is not a member of net.liftweb.util
 
   when I try that.  I don't see the Misc class/object in the API docs
   either.  Is there anything else I should try?
 
   Thanks

 



-- 
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: Why the liftweb doesn't use mysql as the default database ?

2009-10-19 Thread David Pollak
On Mon, Oct 19, 2009 at 1:10 AM, Neil.Lv anim...@gmail.com wrote:


 Hi all,

   Why the liftweb doesn't use MySQL as the default database ?


In addition to the reasons listed in this thread (most importantly, Lift
default apps just work with just Java and Maven installed), I recommend
against using MySQL.

Both PostgreSQL and H2 are higher performance and PostgreSQL has far more
features.

I have a personal bond with the MySQL folks and really wish that I could say
different, but I've also been involved with some of the highest volume
MySQL-based sites around and seen the benchmarks of MySQL vs. PostgreSQL.
It's pretty simple, if you have a choice between the two, use PostgeSQL.



   Thanks very much !

 Cheers,
  Neil

 



-- 
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread rstradling

Take my input or vote of confidence with a grain of salt...
 I had to use java.util.Calendar recently and noticed some of the
issues with it that you mention.  For my case, I created a light
wrapper for my use of java.util.Calendar that redefined the relevant
statics (Monday, Tuesday, etc) as Scala enumerations and then
provided some implicit conversions to go from DayOfWeek.Monday to
java.util.Calendar.Monday.  My hope is that client code never knows
that they are using java.util.Calendar and that they will also get
some level of type-safety by using my wrapper.


In summary, I do not like the design of java.util.Calendar because of
its inconsistencies and think that creating a more consistent way of
doing things is a good thing.





On Oct 18, 10:58 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
 OK, I've run into an issue that makes me really uncomfortable.
 java.util.Calender is generally 1-based for fields, except for month of
 year, which is zero-based. This inconsistency has bled through to the
 TimeHelpers API. I can't just change this, because that would break a lot of
 code, possibly at runtime. What I would like to do is make a corresponding
 set of field accessor methods (day, month, year) in the JodaTimeHelpers
 trait that behave just like TimeHelpers, and then I'm building an extender
 class that will wrap a DateTime to provide functionality very similar to
 what Scala Time does (it's mostly pretty simple). The other inconsistency in
 the API is that some fields are UTC relative (day, month, year), but others
 aren't (currentYear). To address this, I would like to make all of my
 extender class methods use the local timezone, and provide a utc method that
 will return an extender relative to UTC. That way you could do things like:

 now.days // day of month relative to local timezone
 now.utc.days // day of month relative to UTC

 Thoughts?

 Derek

 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak feeder.of.the.be...@gmail.com

  wrote:
  I'd prefer not the break the apis without deprecating them first

  On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker 
  dchenbec...@gmail.comwrote:

  Just asking, since I'm looking at bolting a lot of java.util.Date methods
  onto the innards of TimeHelpers so that the specs pass.

  Derek

  --
  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] javascript with an ajaxbutton

2009-10-19 Thread caw1461

I figured this was a simple problem, but have spent way too much time
on this issue.


$.saveFunc   = function() { saveT(); };


function saveT () {
print(save function executing)
tinyMCE.activeEditor.save()
print(save completed)
};


button id=Save onclick=saveT() class=ui-state-default
title=Save, only save the html, doesn't mark the claim ready for
publishging.Save/button

as a pure javascript/html, this works as intended, the button saves/
submits the form.


   save1 - SHtml.ajaxButton(
 Fixed,
 {
   () = {
println(Jenn is on crack.);
saveClaimStatus(EDITED)
JsRaw($.saveFunc();).cmd;
}
 }, (class, ui-state-default ), (title, Save and
marks the claim ready for publishing.), (id, fixed)),
save2 - SHtml.ajaxButton(
yes,
  () = {println(Rhode Island Destroyed)
 JsRaw($.saveFunc();).cmd})

I used your example in the other thread about ajaxbutton and
javascript, but I can't get the functionality I am looking for.

save2 is just a test button to check functionality.  It does run the
println, but it does not run the saveT function.


13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
AJAX Request: 182kyt8t8rjdz Map(F527240256671NZ2 - List(true))
Rhode Island Destroyed
13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
AJAX Response: 182kyt8t8rjdz InMemoryResponse(
$.saveFunc();;, List((Content-Length,15), (Content-Type,text/
javascript; charset=utf-8)), List(), 200)


I'm just trying to run a javascript function followed by my
saveClaimStatus(EDITED) function.

I just think i'm either not going about this correctly or not
understanding my problem correctly.

Any help would be a godsend.

Thanks,

Christopher



--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jim Barrows
I've been thinking a lot about the issue of backwards compatibility, and the
trade off with good architecture.
I've come to the conclusion that the only real answer is that you have to
take each instance on a case by case basis and ask yourself this question:
Do you want to write a thunking layer between the better architecture and
worse architecture for the next 20 years, and what is that going to cost the
sanity of everyone who comes after?
I think in this case, given the mind numbingly idiotic date and calendar
handling in java, I would answer Dear God, I'd rather dive into a pool
filled with double edged razor blades then ever have to deal java.util.Date
or Calendar again.
I say this because Date and Calendar have been broken since 1.0.1, when I
started working with Java.  Sun/Oracle obviously has no intention of giving
us anything better, so it's up to us to do it.  Doing it now, while the
existing code base of lift is small, is much better then doing it on down
the line.  Ideally I'd like to see this abomination fixed at the Scala
level, rather then the Lift level, but I'll take my sanity savers where I
can.

On Mon, Oct 19, 2009 at 10:17 AM, rstradling ryanstradl...@gmail.comwrote:


 Take my input or vote of confidence with a grain of salt...
  I had to use java.util.Calendar recently and noticed some of the
 issues with it that you mention.  For my case, I created a light
 wrapper for my use of java.util.Calendar that redefined the relevant
 statics (Monday, Tuesday, etc) as Scala enumerations and then
 provided some implicit conversions to go from DayOfWeek.Monday to
 java.util.Calendar.Monday.  My hope is that client code never knows
 that they are using java.util.Calendar and that they will also get
 some level of type-safety by using my wrapper.


 In summary, I do not like the design of java.util.Calendar because of
 its inconsistencies and think that creating a more consistent way of
 doing things is a good thing.





 On Oct 18, 10:58 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
  OK, I've run into an issue that makes me really uncomfortable.
  java.util.Calender is generally 1-based for fields, except for month of
  year, which is zero-based. This inconsistency has bled through to the
  TimeHelpers API. I can't just change this, because that would break a lot
 of
  code, possibly at runtime. What I would like to do is make a
 corresponding
  set of field accessor methods (day, month, year) in the JodaTimeHelpers
  trait that behave just like TimeHelpers, and then I'm building an
 extender
  class that will wrap a DateTime to provide functionality very similar to
  what Scala Time does (it's mostly pretty simple). The other inconsistency
 in
  the API is that some fields are UTC relative (day, month, year), but
 others
  aren't (currentYear). To address this, I would like to make all of my
  extender class methods use the local timezone, and provide a utc method
 that
  will return an extender relative to UTC. That way you could do things
 like:
 
  now.days // day of month relative to local timezone
  now.utc.days // day of month relative to UTC
 
  Thoughts?
 
  Derek
 
  On Thu, Oct 15, 2009 at 5:18 PM, David Pollak 
 feeder.of.the.be...@gmail.com
 
   wrote:
   I'd prefer not the break the apis without deprecating them first
 
   On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:
 
   Just asking, since I'm looking at bolting a lot of java.util.Date
 methods
   onto the innards of TimeHelpers so that the specs pass.
 
   Derek
 
   --
   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
 



-- 
James A Barrows

--~--~-~--~~~---~--~~
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] maintaining logged in user longer outside of SessionVar

2009-10-19 Thread harryh

I want users to stay logged into my site for extended periods of time
(through server restarts, and browser restarts).  By default Lift
stores a User in a SessionVar so this doesn't get me there.  I've
configured jetty so the session cookie doesn't time out for 30 days,
and I have a database table with a session id - user id mapping, but
keeping this up to date has proven to be kind of a pain as the session
id can change from time to time (like when I restart my servers to
push a new website version) and it's a bit more tricky than I would
like to handle all of this correctly.

Are any other lift users trying to accomplish the same goal?  How have
you gone about it?  Would it be a good feature for the framework to
have something to do this a bit more built in?

-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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread Ross Mellgren

Why not use a SessionVar that initializes from the database?

object myVar extends SessionVar[MyObj] 
(loadValueFromDatabaseOrMakeANewOne)

-Ross

On Oct 19, 2009, at 2:12 PM, harryh wrote:


 I want users to stay logged into my site for extended periods of time
 (through server restarts, and browser restarts).  By default Lift
 stores a User in a SessionVar so this doesn't get me there.  I've
 configured jetty so the session cookie doesn't time out for 30 days,
 and I have a database table with a session id - user id mapping, but
 keeping this up to date has proven to be kind of a pain as the session
 id can change from time to time (like when I restart my servers to
 push a new website version) and it's a bit more tricky than I would
 like to handle all of this correctly.

 Are any other lift users trying to accomplish the same goal?  How have
 you gone about it?  Would it be a good feature for the framework to
 have something to do this a bit more built in?

 -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: javascript with an ajaxbutton

2009-10-19 Thread Marius

I think you can simply return  JsRaw($.saveFunc();) without using
JsRaw($.saveFunc();).cmd

Do you see any errors in the browser? ... try using firebug addon in
firefox and see if it complains about anything. What does
saveClaimStatus(EDITED) do?

Regarding I'm just trying to run a javascript function followed by my
saveClaimStatus(EDITED) function.  ... when you press the button
that ajax function on the server side gets executed and it returns a
JavaScript back to browser where $.saveFunc() suppose to be executed.
In your code saveClaimStatus is run before running  $saveFunc() in the
case of the save1 button which seems to be the other way around. What
is your actual use case?

Br's,
Marius

On Oct 19, 8:29 pm, caw1461 caw1...@gmail.com wrote:
 I figured this was a simple problem, but have spent way too much time
 on this issue.

     $.saveFunc   = function() { saveT(); };

     function saveT () {
         print(save function executing)
         tinyMCE.activeEditor.save()
         print(save completed)
     };

     button id=Save onclick=saveT() class=ui-state-default
 title=Save, only save the html, doesn't mark the claim ready for
 publishging.Save/button

 as a pure javascript/html, this works as intended, the button saves/
 submits the form.

            save1 - SHtml.ajaxButton(
              Fixed,
              {
                () = {
                 println(Jenn is on crack.);
                 saveClaimStatus(EDITED)
                 JsRaw($.saveFunc();).cmd;
                 }
              }, (class, ui-state-default ), (title, Save and
 marks the claim ready for publishing.), (id, fixed)),
             save2 - SHtml.ajaxButton(
                 yes,
                   () = {println(Rhode Island Destroyed)
                          JsRaw($.saveFunc();).cmd})

 I used your example in the other thread about ajaxbutton and
 javascript, but I can't get the functionality I am looking for.

 save2 is just a test button to check functionality.  It does run the
 println, but it does not run the saveT function.

 13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
 AJAX Request: 182kyt8t8rjdz Map(F527240256671NZ2 - List(true))
 Rhode Island Destroyed
 13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
 AJAX Response: 182kyt8t8rjdz InMemoryResponse(
 $.saveFunc();;, List((Content-Length,15), (Content-Type,text/
 javascript; charset=utf-8)), List(), 200)

 I'm just trying to run a javascript function followed by my
 saveClaimStatus(EDITED) function.

 I just think i'm either not going about this correctly or not
 understanding my problem correctly.

 Any help would be a godsend.

 Thanks,

 Christopher
--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread David Pollak
See ProtoExtendedSession

We use it in ESME and it's worked flawlessly for us.  If you need a link to
the ESME code (it's Apache 2.0 licensed, so use it all you want, we'll write
more), lemme know.

On Mon, Oct 19, 2009 at 11:12 AM, harryh har...@gmail.com wrote:


 I want users to stay logged into my site for extended periods of time
 (through server restarts, and browser restarts).  By default Lift
 stores a User in a SessionVar so this doesn't get me there.  I've
 configured jetty so the session cookie doesn't time out for 30 days,
 and I have a database table with a session id - user id mapping, but
 keeping this up to date has proven to be kind of a pain as the session
 id can change from time to time (like when I restart my servers to
 push a new website version) and it's a bit more tricky than I would
 like to handle all of this correctly.

 Are any other lift users trying to accomplish the same goal?  How have
 you gone about it?  Would it be a good feature for the framework to
 have something to do this a bit more built in?

 -harryh
 



-- 
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: javascript with an ajaxbutton

2009-10-19 Thread caw1461

My saveClaimSatus() function saves the passed value to the
database.
Firebug is not giving me any errors and prints the line to the
console.

The order in which the two updates happen is important because I need
the status updated before the form is saved.

I am using two different versions of saving to keep a temporary save
and then a finalized For Publish version.

so I need both of them to save the form, which i was trying to use the
saveFunc to do.

and removing the .cmd seems to give a syntax errors:

E:\patentTracker3\prospective_claims_ver_br\patentTrackerUi\src\main
\scala\com\trlr\binpr\snippet\Workflow.scala:473: error: overloaded
method value ajaxButton with alternatives (String,() =
net.liftweb.http.js.JsCmd,(String, String)*)scala.xml.Elem and
(scala.xml.NodeSeq,() = net.liftweb.http.js.JsCmd,(String, String)*)
scala.xml.Elem cannot be applied to (java.lang.String,() =
net.liftweb.http.js.JE.JsRaw,(java.lang.String, java.lang.String),
(java.lang.String, java.lang.String),(java.lang.String,
java.lang.String))
   save1 - SHtml.ajaxButton(




On Oct 19, 2:20 pm, Marius marius.dan...@gmail.com wrote:
 I think you can simply return  JsRaw($.saveFunc();) without using
 JsRaw($.saveFunc();).cmd

 Do you see any errors in the browser? ... try using firebug addon in
 firefox and see if it complains about anything. What does
 saveClaimStatus(EDITED) do?

 Regarding I'm just trying to run ajavascriptfunction followed by my
 saveClaimStatus(EDITED) function.  ... when you press thebutton
 thatajaxfunction on the server side gets executed and it returns 
 aJavaScriptback to browser where $.saveFunc() suppose to be executed.
 In your code saveClaimStatus is run before running  $saveFunc() in the
 case of the save1buttonwhich seems to be the other way around. What
 is your actual use case?

 Br's,
 Marius

 On Oct 19, 8:29 pm, caw1461 caw1...@gmail.com wrote:

  I figured this was a simple problem, but have spent way too much time
  on this issue.

      $.saveFunc   = function() { saveT(); };

      function saveT () {
          print(save function executing)
          tinyMCE.activeEditor.save()
          print(save completed)
      };

      buttonid=Save onclick=saveT() class=ui-state-default
  title=Save, only save the html, doesn't mark the claim ready for
  publishging.Save/button

  as a purejavascript/html, this works as intended, thebuttonsaves/
  submits the form.

             save1 - SHtml.ajaxButton(
               Fixed,
               {
                 () = {
                  println(Jenn is on crack.);
                  saveClaimStatus(EDITED)
                  JsRaw($.saveFunc();).cmd;
                  }
               }, (class, ui-state-default ), (title, Save and
  marks the claim ready for publishing.), (id, fixed)),
              save2 - SHtml.ajaxButton(
                  yes,
                    () = {println(Rhode Island Destroyed)
                           JsRaw($.saveFunc();).cmd})

  I used your example in the other thread about ajaxbutton and
 javascript, but I can't get the functionality I am looking for.

  save2 is just a testbuttonto check functionality.  It does run the
  println, but it does not run the saveT function.

  13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
 AJAXRequest: 182kyt8t8rjdz Map(F527240256671NZ2 - List(true))
  Rhode Island Destroyed
  13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
 AJAXResponse: 182kyt8t8rjdz InMemoryResponse(
  $.saveFunc();;, List((Content-Length,15), (Content-Type,text/
 javascript; charset=utf-8)), List(), 200)

  I'm just trying to run ajavascriptfunction followed by my
  saveClaimStatus(EDITED) function.

  I just think i'm either not going about this correctly or not
  understanding my problem correctly.

  Any help would be a godsend.

  Thanks,

  Christopher



--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread harryh

 See ProtoExtendedSession

Ah, this is perfect!  Just hadn't noticed it before.  Thx.

-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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jim Barrows
On Mon, Oct 19, 2009 at 10:53 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:

 That's pretty much my take. The whole Java Calendar/Date/Timezone impl is
 poorly designed, hence Joda Time.

  Now I've run into another wall, this time with the TimeSpanBuilder. I
 can't mask the implicits from long/int to TimeSpanBuilder, so I can't define
 the same DSL for things like 3 seconds, etc. I tried to provide an
 implicit conversion from TimeSpan to JodaSpan but that won't cover all of
 the cases and this is feeling increasingly ugly as I add more and more
 layers and implicit defs to work around the old API.

 At this point, the only way that this may work is if I create and entirely
 new JodaHelpers object that extends all of the Helpers traits, replacing
 TimeHelpers with my new JodaTimeHelpers trait. This may be the path of least
 pain, but it means two cycles of deprecation: one to deprecate the current
 TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
 JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this sound
 like a reasonable approach, or is this getting too crazy?

  The other option I thought of is to make a new branch just for this and
 just track master with the branch. The big downside is that this doubles the
 release work to have a Joda Lift and non-Joda Lift.

 Thoughts?



I'm always on the side of less work, and less clutter.  What about keeping
the old stuff deprecated (and unmaintained) till 1.5 or 2.0, and encouraging
the use of the JodaTimeHelpers in the mean time.  That gives existing code
time to be transitioned to the new stuff..



 Derek


 On Mon, Oct 19, 2009 at 11:17 AM, rstradling ryanstradl...@gmail.comwrote:


 Take my input or vote of confidence with a grain of salt...
  I had to use java.util.Calendar recently and noticed some of the
 issues with it that you mention.  For my case, I created a light
 wrapper for my use of java.util.Calendar that redefined the relevant
 statics (Monday, Tuesday, etc) as Scala enumerations and then
 provided some implicit conversions to go from DayOfWeek.Monday to
 java.util.Calendar.Monday.  My hope is that client code never knows
 that they are using java.util.Calendar and that they will also get
 some level of type-safety by using my wrapper.


 In summary, I do not like the design of java.util.Calendar because of
 its inconsistencies and think that creating a more consistent way of
 doing things is a good thing.





 On Oct 18, 10:58 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
  OK, I've run into an issue that makes me really uncomfortable.
  java.util.Calender is generally 1-based for fields, except for month of
  year, which is zero-based. This inconsistency has bled through to the
  TimeHelpers API. I can't just change this, because that would break a
 lot of
  code, possibly at runtime. What I would like to do is make a
 corresponding
  set of field accessor methods (day, month, year) in the JodaTimeHelpers
  trait that behave just like TimeHelpers, and then I'm building an
 extender
  class that will wrap a DateTime to provide functionality very similar to
  what Scala Time does (it's mostly pretty simple). The other
 inconsistency in
  the API is that some fields are UTC relative (day, month, year), but
 others
  aren't (currentYear). To address this, I would like to make all of my
  extender class methods use the local timezone, and provide a utc method
 that
  will return an extender relative to UTC. That way you could do things
 like:
 
  now.days // day of month relative to local timezone
  now.utc.days // day of month relative to UTC
 
  Thoughts?
 
  Derek
 
  On Thu, Oct 15, 2009 at 5:18 PM, David Pollak 
 feeder.of.the.be...@gmail.com
 
   wrote:
   I'd prefer not the break the apis without deprecating them first
 
   On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:
 
   Just asking, since I'm looking at bolting a lot of java.util.Date
 methods
   onto the innards of TimeHelpers so that the specs pass.
 
   Derek
 
   --
   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



 



-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jeppe Nejsum Madsen

Derek Chen-Becker dchenbec...@gmail.com writes:

 That's pretty much my take. The whole Java Calendar/Date/Timezone impl is
 poorly designed, hence Joda Time.


  Now I've run into another wall, this time with the TimeSpanBuilder. I can't
 mask the implicits from long/int to TimeSpanBuilder, so I can't define the
 same DSL for things like 3 seconds, etc. I tried to provide an implicit
 conversion from TimeSpan to JodaSpan but that won't cover all of the cases
 and this is feeling increasingly ugly as I add more and more layers and
 implicit defs to work around the old API.

I haven't looked very closely at the current code, so don't really know
what the issues are. but this won't stop me from commenting. I'm
really looking forward to get rid of Calendar and friends

 At this point, the only way that this may work is if I create and entirely
 new JodaHelpers object that extends all of the Helpers traits, replacing
 TimeHelpers with my new JodaTimeHelpers trait. This may be the path of least
 pain, but it means two cycles of deprecation: one to deprecate the current
 TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
 JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this sound
 like a reasonable approach, or is this getting too crazy?

Depending on the cycle-length, this doesn't sound too bad. But if it is
1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
has numerous breaking changes so if a cycle is just a milestone release
then I think it's fine.

  The other option I thought of is to make a new branch just for this and
 just track master with the branch. The big downside is that this doubles the
 release work to have a Joda Lift and non-Joda Lift.

Doesn't sound like a viable approach. We'll be carrying this baggage
forever (unless this was only a temp solution?)

/Jeppe


--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread Jeppe Nejsum Madsen

harryh har...@gmail.com writes:

 I want users to stay logged into my site for extended periods of time
 (through server restarts, and browser restarts).  By default Lift
 stores a User in a SessionVar so this doesn't get me there.  I've
 configured jetty so the session cookie doesn't time out for 30 days,
 and I have a database table with a session id - user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id-user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
I've just looked at the code.

There's nothing that's going to be incompatible moving to JodaTime.  Sure,
the month method will have a different result if you pass it a JodaTime
instance than in you pass it a Date instance.  If this is documented, then
it's not a problem.

Existing methods don't get changed.  For methods that return a Date or
Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
returns a JodaTime instance.

Existing methods that take a Date or Calendar, there'll be parallel methods
that take a JodaTime instance.

Where does this seem unworkable?



On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone impl is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder. I
 can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't define
 the
  same DSL for things like 3 seconds, etc. I tried to provide an implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits, replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path of
 least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   The other option I thought of is to make a new branch just for this and
  just track master with the branch. The big downside is that this doubles
 the
  release work to have a Joda Lift and non-Joda Lift.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe


 



-- 
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: javascript with an ajaxbutton

2009-10-19 Thread Marius

I think with an

import net.liftweb.http.js._
import JsCmds._

the compile problem should go away as there is an implicit defined
there. But this is not important.

Can you send a minimalistic code example that reflects the
problem? ... including the template and Scala code.

Br's,
Marius

On Oct 19, 9:48 pm, caw1461 caw1...@gmail.com wrote:
 My saveClaimSatus() function saves the passed value to the
 database.
 Firebug is not giving me any errors and prints the line to the
 console.

 The order in which the two updates happen is important because I need
 the status updated before the form is saved.

 I am using two different versions of saving to keep a temporary save
 and then a finalized For Publish version.

 so I need both of them to save the form, which i was trying to use the
 saveFunc to do.

 and removing the .cmd seems to give a syntax errors:

 E:\patentTracker3\prospective_claims_ver_br\patentTrackerUi\src\main
 \scala\com\trlr\binpr\snippet\Workflow.scala:473: error: overloaded
 method value ajaxButton with alternatives (String,() =
 net.liftweb.http.js.JsCmd,(String, String)*)scala.xml.Elem and
 (scala.xml.NodeSeq,() = net.liftweb.http.js.JsCmd,(String, String)*)
 scala.xml.Elem cannot be applied to (java.lang.String,() =
 net.liftweb.http.js.JE.JsRaw,(java.lang.String, java.lang.String),
 (java.lang.String, java.lang.String),(java.lang.String,
 java.lang.String))
            save1 - SHtml.ajaxButton(

 On Oct 19, 2:20 pm, Marius marius.dan...@gmail.com wrote:

  I think you can simply return  JsRaw($.saveFunc();) without using
  JsRaw($.saveFunc();).cmd

  Do you see any errors in the browser? ... try using firebug addon in
  firefox and see if it complains about anything. What does
  saveClaimStatus(EDITED) do?

  Regarding I'm just trying to run ajavascriptfunction followed by my
  saveClaimStatus(EDITED) function.  ... when you press thebutton
  thatajaxfunction on the server side gets executed and it returns 
  aJavaScriptback to browser where $.saveFunc() suppose to be executed.
  In your code saveClaimStatus is run before running  $saveFunc() in the
  case of the save1buttonwhich seems to be the other way around. What
  is your actual use case?

  Br's,
  Marius

  On Oct 19, 8:29 pm, caw1461 caw1...@gmail.com wrote:

   I figured this was a simple problem, but have spent way too much time
   on this issue.

       $.saveFunc   = function() { saveT(); };

       function saveT () {
           print(save function executing)
           tinyMCE.activeEditor.save()
           print(save completed)
       };

       buttonid=Save onclick=saveT() class=ui-state-default
   title=Save, only save the html, doesn't mark the claim ready for
   publishging.Save/button

   as a purejavascript/html, this works as intended, thebuttonsaves/
   submits the form.

              save1 - SHtml.ajaxButton(
                Fixed,
                {
                  () = {
                   println(Jenn is on crack.);
                   saveClaimStatus(EDITED)
                   JsRaw($.saveFunc();).cmd;
                   }
                }, (class, ui-state-default ), (title, Save and
   marks the claim ready for publishing.), (id, fixed)),
               save2 - SHtml.ajaxButton(
                   yes,
                     () = {println(Rhode Island Destroyed)
                            JsRaw($.saveFunc();).cmd})

   I used your example in the other thread about ajaxbutton and
  javascript, but I can't get the functionality I am looking for.

   save2 is just a testbuttonto check functionality.  It does run the
   println, but it does not run the saveT function.

   13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
  AJAXRequest: 182kyt8t8rjdz Map(F527240256671NZ2 - List(true))
   Rhode Island Destroyed
   13:19:17.725 [29569...@qtp-6966554-8] DEBUG comet_trace.debug:82 -
  AJAXResponse: 182kyt8t8rjdz InMemoryResponse(
   $.saveFunc();;, List((Content-Length,15), (Content-Type,text/
  javascript; charset=utf-8)), List(), 200)

   I'm just trying to run ajavascriptfunction followed by my
   saveClaimStatus(EDITED) function.

   I just think i'm either not going about this correctly or not
   understanding my problem correctly.

   Any help would be a godsend.

   Thanks,

   Christopher
--~--~-~--~~~---~--~~
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: javascript with an ajaxbutton

2009-10-19 Thread caw1461

edit.html:




script type=text/javascript

tinyMCE.init({
// General options
mode : textareas,
theme : advanced,
plugins :
spellchecker,pagebreak,save,advhr,advimage,advlink,iespell,inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,noneditable,visualchars,nonbreaking,xhtmlxtras,template,
theme_advanced_buttons1 :
styleselect,formatselect,fontselect,fontsizeselect,|,bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull,|,
hr, bullist,numlist, preview, code,
theme_advanced_buttons2 : ,
theme_advanced_buttons3 : ,
theme_advanced_buttons4 : ,

submit_patch : false,

theme_advanced_resizing : true
});

// The save function that actually works.


$.saveFunc = function() { tinyMCE.activeEditor.save() };

function saveT () {
console.log(javascript console 1)
tinyMCE.activeEditor.save()
console.log(javascript console 2)
};


$('#fixed').click(function(e){
tinyMCE.activeEditor.save()
});
/script

editor:text/
br/

!--  NOW WORKS CORRECTLY --
button id=Save onclick=saveT() class=ui-state-default
title=Save, only save the html, doesn't mark the claim ready for
publishging.Save/button

editor:save1/
editor:cancel/
editor:save2/

//*//

Workflow.scala:


  SHtml.ajaxForm(
bind(editor, xhtml,

text - SHtml.textarea(originalOrEditedFileAsString
(selectedClaimWorkQueue.open_!.fileName),
s = {
println(s)
saveClaimHtmlToDB(s)
saveClaimHtml(s,
selectedClaimWorkQueue.open_!.fileName)
S.notice(Submitted.)
redirect(/workflow/claims)
} , (style, height: 500px; width:97%), (id,
mceForm)),

   save - SHtml.ajaxButton(
 Save,
 {() =
   Log.info(Got a 'save' AJAX call)
  saveClaimStatus(EDITED)
  S.notice(Saved.)
  redirect(/workflow/claims)
}, (type, submit),(class, ui-state-default ),
(title, Save, only save the html, does not mark the claim ready for
publishging.), (id, fixed)),
   save1 - SHtml.ajaxButton(

 Fixed,
  { () = {
println(Fixed scala/lift.);
saveClaimStatus(FIXED);
JsRaw($.saveFunc();).cmd);
}
  }, (class, ui-state-default ), (title, Save and
marks the claim ready for publishing.), (id, fixed)),
save2 - SHtml.ajaxButton(
yes, () = {JsRaw($.saveFunc();).cmd })))

}





I'm already importing both of those so that isn't the problem.  If I
put a % (onclick - saveT()) on the button, it saves the way I
want it to, but it does not do any of the println or saveClaimStatus
calls.  I just want it to do both.



On Oct 19, 3:43 pm, Marius marius.dan...@gmail.com wrote:
 I think with an

 import net.liftweb.http.js._
 import JsCmds._

 the compile problem should go away as there is an implicit defined
 there. But this is not important.

 Can you send a minimalistic code example that reflects the
 problem? ... including the template and Scala code.

 Br's,
 Marius

 On Oct 19, 9:48 pm, caw1461 caw1...@gmail.com wrote:

  My saveClaimSatus() function saves the passed value to the
  database.
  Firebug is not giving me any errors and prints the line to the
  console.

  The order in which the two updates happen is important because I need
  the status updated before the form is saved.

  I am using two different versions of saving to keep a temporary save
  and then a finalized For Publish version.

  so I need both of them to save the form, which i was trying to use the
  saveFunc to do.

  and removing the .cmd seems to give a syntax errors:

  E:\patentTracker3\prospective_claims_ver_br\patentTrackerUi\src\main
  \scala\com\trlr\binpr\snippet\Workflow.scala:473: error: overloaded
  method value ajaxButton with alternatives (String,() =
  net.liftweb.http.js.JsCmd,(String, String)*)scala.xml.Elem and
  (scala.xml.NodeSeq,() = net.liftweb.http.js.JsCmd,(String, String)*)
  scala.xml.Elem cannot be applied to (java.lang.String,() =
  net.liftweb.http.js.JE.JsRaw,(java.lang.String, java.lang.String),
  (java.lang.String, java.lang.String),(java.lang.String,
  java.lang.String))
             save1 - SHtml.ajaxButton(

  On Oct 19, 2:20 pm, Marius marius.dan...@gmail.com wrote:

   I think you can simply return  JsRaw($.saveFunc();) without using
   JsRaw($.saveFunc();).cmd

   Do you see any errors in the browser? ... try using firebug addon in
   firefox and see if it complains about anything. What does
   saveClaimStatus(EDITED) do?

   Regarding I'm just trying to run ajavascriptfunction followed by my
   saveClaimStatus(EDITED) 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
The major issue is the time DSL. Everything else works fine by masking the
definitions with a later import, e.g.

import Helpers._
import JodaTimeHelpers._

The problem is that implicit defs (views) don't mask, so I can't override or
mask it so that 3 seconds returns a Joda Time Duration, which is a cleaner
way of representing time durations in milliseconds. In order to get a better
discussion going, I'll go ahead and comment out my refactored DSL and put up
the code that does work this afternoon and we can discuss it from there.

Derek

On Mon, Oct 19, 2009 at 1:37 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.  Sure,
 the month method will have a different result if you pass it a JodaTime
 instance than in you pass it a Date instance.  If this is documented, then
 it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel methods
 that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone impl
 is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder. I
 can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't define
 the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits, replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path of
 least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   The other option I thought of is to make a new branch just for this and
  just track master with the branch. The big downside is that this doubles
 the
  release work to have a Joda Lift and non-Joda Lift.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






 --
 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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
I spoke too soon. If I try to do masking imports, I get errors about
ambiguous defs:

[WARNING]
/home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
error: reference to now is ambiguous;
[WARNING] it is imported twice in the same scope by
[WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
[WARNING] and import _root_.net.liftweb.util.TimeHelpers._
[WARNING]   3.seconds.later.millis must beCloseTo((now +
3.seconds).millis, 100L)

Since TimeHelpers is automatically part of Helpers, and import Helpers._
is a pretty common import, it's going to require some other mechanism to get
the proper import into scope. Any solution which results in now returning
a java.util.Date essentially defeats the purpose of moving to Joda Time,
since you can just do

  /** transforms a java.util.Date to a org.joda.time.DateTime */
  implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

  /** transforms an org.joda.time.DateTime to a java.util.Date */
  implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

in your code and get most of it for free. What I'm trying to achieve here is
a refactoring of Lift's time formatting and processing API that lends itself
to clean usage of JodaTime.

Derek

On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 The major issue is the time DSL. Everything else works fine by masking the
 definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't override
 or mask it so that 3 seconds returns a Joda Time Duration, which is a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.  Sure,
 the month method will have a different result if you pass it a JodaTime
 instance than in you pass it a Date instance.  If this is documented, then
 it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dkwrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone impl
 is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder. I
 can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't define
 the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits,
 replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path of
 least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   The other option I thought of is to make a new branch just for this
 and
  just track master with the branch. The big downside is that this
 doubles the
  release work to have a Joda Lift and non-Joda Lift.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






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

[Lift] Re: does this look ok?

2009-10-19 Thread Derek Chen-Becker
Just my 2 cents, but if you're having a problem with some code it helps to
explain what the problem is along with the code that you're sending.
Otherwise, it's like an interview question :)

On Sun, Oct 18, 2009 at 5:12 PM, jack jack.wid...@gmail.com wrote:


 Does this code look ok?

 def createDisplay(blogs:List[Blog]):NodeSeq = {
   span id=scoretable
{
  for {blog - blogs} yield trtda href={blog.url}{blog.url}/
 a/tdtd {blog.displayScore}/td/tr
}
/table/span
  }

  def render  = { bind(joop - createDisplay(blogs)) }
 


--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
What branch is the code on?

On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import Helpers._
 is a pretty common import, it's going to require some other mechanism to get
 the proper import into scope. Any solution which results in now returning
 a java.util.Date essentially defeats the purpose of moving to Joda Time,
 since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 The major issue is the time DSL. Everything else works fine by masking the
 definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't override
 or mask it so that 3 seconds returns a Joda Time Duration, which is a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dkwrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone impl
 is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder. I
 can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't define
 the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers
 and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits,
 replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path of
 least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   The other option I thought of is to make a new branch just for this
 and
  just track master with the branch. The big downside is that this
 doubles the
  release work to have a Joda Lift and non-Joda Lift.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






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

[Lift] Problem with default Connection pool/CP for use with lift?

2009-10-19 Thread Jeppe Nejsum Madsen

Hi,

We ran into an issue today. Basically, our postgres volume went into
readonly mode, making database access...hmmm lets say less than perfect
:-)

We quickly revived the db server, but this surfaced a problem which I
think is in the default connection pool of the generated Lift archetypes
(which I haven't got around to changing...yet!):

The connections created to the db are always put back into the pool and
never tested for validity. So if the db server crashes and connections
are already in the pool, it seems like they are reused but they'll fail
when a new db server instance is started. Only recourse seems to be to
restart the container (Jetty in our case)

Most J2EE servers has some built-in connection pool functionality that
will test connections etc and create new if needed.

What are people using for their Lift apps in the simpler container-only
setup (e.g. Jetty?)

/Jeppe

--~--~-~--~~~---~--~~
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: Problem with default Connection pool/CP for use with lift?

2009-10-19 Thread David Pollak
At least the most recent version of Boot.scala has reasonable testing of
connection validity:

case x :: xs = try {
  x.setAutoCommit(false)
  Full(x)
} catch {
  case e = try {
pool = xs
poolSize = poolSize - 1
x.close
newConnection(name)
  } catch {
case e = newConnection(name)
  }
}

If the setAutoCommit(false) line fails, the connection is returned to the
pool.  You can put other logic here.

On Mon, Oct 19, 2009 at 2:10 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


 Hi,

 We ran into an issue today. Basically, our postgres volume went into
 readonly mode, making database access...hmmm lets say less than perfect
 :-)

 We quickly revived the db server, but this surfaced a problem which I
 think is in the default connection pool of the generated Lift archetypes
 (which I haven't got around to changing...yet!):

 The connections created to the db are always put back into the pool and
 never tested for validity. So if the db server crashes and connections
 are already in the pool, it seems like they are reused but they'll fail
 when a new db server instance is started. Only recourse seems to be to
 restart the container (Jetty in our case)

 Most J2EE servers has some built-in connection pool functionality that
 will test connections etc and create new if needed.

 What are people using for their Lift apps in the simpler container-only
 setup (e.g. Jetty?)

 /Jeppe

 



-- 
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: reverse-Schemifier: generating BaseMapper instances from schema/SQL/JPA

2009-10-19 Thread Derek Chen-Becker
As far as I know, nothing like this exists. I wouldn't say that it's
trivial, but I would expect that writing something to generate it would be
relatively straightforward in design terms.

On Mon, Oct 19, 2009 at 2:17 AM, opyate opy...@gmail.com wrote:


 Hello Lifters,

 Related:

 http://groups.google.com/group/liftweb/browse_thread/thread/20051762b58f0083/b3329f33e8f3dc73?lnk=gstq=existing+database#b3329f33e8f3dc73

 I would like to generate (at run-time) BaseMapper instances of a
 schema. I know I can generate the JPA beans from a schema (using
 Hibernate3 tools - thanks to Greg Meredith for pointing this out), but
 then I'd like to convert these to BaseMapper instances so I can use
 the .toForm: NodeSeq functionality. Or schema to BaseMapper directly?
 Schemifier in reverse, perhaps.

 Use case: I'm building an open source tool with which you can define
 external databases to manage. I wouldn't know the details of these
 databases at design/compile time, and thusly would like to be able to
 just point to a database, point to a table (related tables if foreign
 key exists), dynamically generate a form for the table/row, edit,
 save. I know this sounds really far-fetched, and fragile. I just want
 to see if it's viable :-)

 With javax.sql I can generate the form, hence the SQL and then call an
 insert/update on the target DB, but I'd prefer a Mapper solution.

 CODE-START
 Class.forName (com.mysql.jdbc.Driver).newInstance() // could be any
 db type
 val sConnection = jdbc:mysql://host:3306/dbname // some DB known at
 run-time
 val conn: Connection = DriverManager.getConnection(sConnection,
 db_user, db_password)
 val sqlStatement: Statement = conn.createStatement()
 val rs: ResultSet = sqlStatement.executeQuery(select * from  +
 someRuntimeTable +  limit 1)
 val rsm: ResultSetMetaData = rs.getMetaData()
 // now we have a slew of methods at our disposal which tells us things
 about the table, for example:
 rsm.isAutoIncrement(1) // example
 for (i - 1 to rsm.getColumnCount()) {
  rsm.getColumnLabel(i) // example
  rsm.getColumnTypeName(i) // example
 }
 CODE-END

 Thanks,
 Juan

 


--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
wip-dcb-issue-89-jodatime. I just checked in everything I have, which means
that branch currently doesn't compile. Maybe I'm overthinking it, but
TimeHelpers does define some nice convenience methods and my goal is to
replicate and extend that with Joda Time.

Derek

On Mon, Oct 19, 2009 at 3:13 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import Helpers._
 is a pretty common import, it's going to require some other mechanism to get
 the proper import into scope. Any solution which results in now returning
 a java.util.Date essentially defeats the purpose of moving to Joda Time,
 since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 The major issue is the time DSL. Everything else works fine by masking
 the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't override
 or mask it so that 3 seconds returns a Joda Time Duration, which is a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dk
  wrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone
 impl is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder.
 I can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't
 define the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers
 and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits,
 replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path
 of least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1
 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   The other option I thought of is to make a new branch just for this
 and
  just track master with the branch. The big downside is that this
 doubles the
  release work to have a Joda Lift and non-Joda Lift.

 Doesn't sound like a viable approach. We'll be 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
Please take a look at
http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

I think I've got JodaTime and the existing code playing nicely together.

On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which means
 that branch currently doesn't compile. Maybe I'm overthinking it, but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by masking
 the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, which
 is a cleaner way of representing time durations in milliseconds. In order 
 to
 get a better discussion going, I'll go ahead and comment out my refactored
 DSL and put up the code that does work this afternoon and we can discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone
 impl is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the TimeSpanBuilder.
 I can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't
 define the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of the
 cases
  and this is feeling increasingly ugly as I add more and more layers
 and
  implicit defs to work around the old API.

 I haven't looked very closely at the current code, so don't really
 know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  At this point, the only way that this may work is if I create and
 entirely
  new JodaHelpers object that extends all of the Helpers traits,
 replacing
  TimeHelpers with my new JodaTimeHelpers trait. This may be the path
 of least
  pain, but it means two cycles of deprecation: one to deprecate the
 current
  TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
  JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this
 sound
  like a reasonable approach, or is this getting too crazy?

 Depending on the cycle-length, this doesn't sound too bad. But if it
 is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1
 already
 has numerous breaking changes so if a cycle is just a milestone
 release
 then I think it's 

[Lift] Re: reverse-Schemifier: generating BaseMapper instances from schema/SQL/JPA

2009-10-19 Thread Naftoli Gugenheim

Actuall I think someone mentioned a while ago that he had a limited tool to 
generate source code for Mappers from SQL. Maybe such source code could be 
compiled using a technique like the REPL uses.

-
Derek Chen-Beckerdchenbec...@gmail.com wrote:

As far as I know, nothing like this exists. I wouldn't say that it's
trivial, but I would expect that writing something to generate it would be
relatively straightforward in design terms.

On Mon, Oct 19, 2009 at 2:17 AM, opyate opy...@gmail.com wrote:


 Hello Lifters,

 Related:

 http://groups.google.com/group/liftweb/browse_thread/thread/20051762b58f0083/b3329f33e8f3dc73?lnk=gstq=existing+database#b3329f33e8f3dc73

 I would like to generate (at run-time) BaseMapper instances of a
 schema. I know I can generate the JPA beans from a schema (using
 Hibernate3 tools - thanks to Greg Meredith for pointing this out), but
 then I'd like to convert these to BaseMapper instances so I can use
 the .toForm: NodeSeq functionality. Or schema to BaseMapper directly?
 Schemifier in reverse, perhaps.

 Use case: I'm building an open source tool with which you can define
 external databases to manage. I wouldn't know the details of these
 databases at design/compile time, and thusly would like to be able to
 just point to a database, point to a table (related tables if foreign
 key exists), dynamically generate a form for the table/row, edit,
 save. I know this sounds really far-fetched, and fragile. I just want
 to see if it's viable :-)

 With javax.sql I can generate the form, hence the SQL and then call an
 insert/update on the target DB, but I'd prefer a Mapper solution.

 CODE-START
 Class.forName (com.mysql.jdbc.Driver).newInstance() // could be any
 db type
 val sConnection = jdbc:mysql://host:3306/dbname // some DB known at
 run-time
 val conn: Connection = DriverManager.getConnection(sConnection,
 db_user, db_password)
 val sqlStatement: Statement = conn.createStatement()
 val rs: ResultSet = sqlStatement.executeQuery(select * from  +
 someRuntimeTable +  limit 1)
 val rsm: ResultSetMetaData = rs.getMetaData()
 // now we have a slew of methods at our disposal which tells us things
 about the table, for example:
 rsm.isAutoIncrement(1) // example
 for (i - 1 to rsm.getColumnCount()) {
  rsm.getColumnLabel(i) // example
  rsm.getColumnTypeName(i) // example
 }
 CODE-END

 Thanks,
 Juan

 




--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread Naftoli Gugenheim

Is it more dangerous to store the user's uniqueId in a cookie than to store 
another uniqueId that's associated with the user's uniqueId?

-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


harryh har...@gmail.com writes:

 I want users to stay logged into my site for extended periods of time
 (through server restarts, and browser restarts).  By default Lift
 stores a User in a SessionVar so this doesn't get me there.  I've
 configured jetty so the session cookie doesn't time out for 30 days,
 and I have a database table with a session id - user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id-user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe



--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread Naftoli Gugenheim

MetaMegaProtoUser has hooks -- onLogIn, onLogOut, and autologinFunc -- that you 
can use. autologinFunc is called when loggedIn_? is called and no user is 
logged in, to give you a chance to log one in.
So you can create a cookie in onLogIn, delete it in onLogOut, and read it in 
autologinFunc.
-
Jeppe Nejsum Madsenje...@ingolfs.dk wrote:


harryh har...@gmail.com writes:

 I want users to stay logged into my site for extended periods of time
 (through server restarts, and browser restarts).  By default Lift
 stores a User in a SessionVar so this doesn't get me there.  I've
 configured jetty so the session cookie doesn't time out for 30 days,
 and I have a database table with a session id - user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id-user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe



--~--~-~--~~~---~--~~
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: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread harryh

 Is it more dangerous to store the user's uniqueId in a cookie than to store 
 another uniqueId that's associated with the
 user's uniqueId?

It is if your site has URLs like http://harryh.org/user/[uid]

-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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Well, yes. I actually had similar code working, but what I was trying to
avoid is a situation where someone has code like:

import Helpers._
..

val someTime = now + ( 3 minutes)

and then to use this code with JodaTime they need to change it to

val someTime = jtNow + (3 minutes)

and then when we remove the current java.util impl they would have to switch
back to the original code. Also, because of all of these issues I haven't
fully worked out things like JodaSpanBuilder, which should really be using
JodaTime's Periods instead of Durations since those take into account things
like daylight savings time and leap years (none of the current code does
that right now, java.util or JodaTime). If this is the best compromise we
can come up with I'll just make a new branch to finish working on the
JodaTime side of things.

Thanks,

Derek

On Mon, Oct 19, 2009 at 4:57 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 Please take a look at
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

 I think I've got JodaTime and the existing code playing nicely together.


 On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which
 means that branch currently doesn't compile. Maybe I'm overthinking it, but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results 
 in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by masking
 the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, 
 which
 is a cleaner way of representing time durations in milliseconds. In order 
 to
 get a better discussion going, I'll go ahead and comment out my refactored
 DSL and put up the code that does work this afternoon and we can discuss 
 it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone
 impl is
  poorly designed, hence Joda Time.


   Now I've run into another wall, this time with the
 TimeSpanBuilder. I can't
  mask the implicits from long/int to TimeSpanBuilder, so I can't
 define the
  same DSL for things like 3 seconds, etc. I tried to provide an
 implicit
  conversion from TimeSpan to JodaSpan but that won't cover all of
 the cases
  and this is feeling increasingly ugly as I add more and more layers
 and
  implicit defs to work around the old API.

 I haven't looked very 

[Lift] Re: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread David Pollak
On Mon, Oct 19, 2009 at 5:02 PM, harryh har...@gmail.com wrote:


  Is it more dangerous to store the user's uniqueId in a cookie than to
 store another uniqueId that's associated with the
  user's uniqueId?


An opaque identifier that can be revoked and is not exposed outside of a
given user's session is a lot more secure than a global identifier that
cannot be revoked or replaced.  For example, it would be possible to cycle
the long term session identifier each time it was accessed.  That cannot be
done with some sort of unqueId that's associated with the user.  Plus a
browser-by-browser identifier is something that can be changed/deleted
without impacting the other browsers.



 It is if your site has URLs like http://harryh.org/user/[uid]

 -harryh
 



-- 
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to remove
it any time soon (in the next year +).  Personally, I don't see a compelling
reason to remove it from the code base (there may be people who would prefer
not to use JodaTime).  So, we might need better names than jtNow, etc., but
I'm not expecting to make now return a DateTime.

On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Well, yes. I actually had similar code working, but what I was trying to
 avoid is a situation where someone has code like:

 import Helpers._
 ..

 val someTime = now + ( 3 minutes)

 and then to use this code with JodaTime they need to change it to

 val someTime = jtNow + (3 minutes)

 and then when we remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Please take a look at
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

 I think I've got JodaTime and the existing code playing nicely together.


 On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which
 means that branch currently doesn't compile. Maybe I'm overthinking it, but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results 
 in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by masking
 the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, 
 which
 is a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can discuss 
 it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date
 or Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


 Derek Chen-Becker dchenbec...@gmail.com writes:

  That's pretty much my take. The whole Java Calendar/Date/Timezone
 impl is
  poorly designed, hence Joda Time.



[Lift] how to use JqKeypress?

2009-10-19 Thread harryh

It seems like I ought to be able to use JqKeypress so that if a user
presses enter when a text input has focus an associated ajaxButton is
submitted.  I can't get it to work though.  Help?

Basically I have a bunch of little form like so

[  text input   ] [go!]

that I want to submit (ajax style) when the user presses enter.

-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] Setting Table Border

2009-10-19 Thread sunanda

Hi,
I need to display the table with border.
Following is the sample code.
But it is not displaying the border.Is this the correct way of setting
the border.

Sunanda


def displayColDef(selectedname:String):NodeSeq={

val coldef = getColDef(selectedname)
   table border=2
   tr
   td bDisplay Name/b/td
   td{coldef.displayname}/td
   /tr
   tr
   tdbColumn Type/b /td
   td {coldef.coltype}/td
   /tr
/table
}
--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
What I was thinking earlier is that we can simply make a JodaHelpers object
that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code changes
to move to Joda Time would mostly just be an import change instead of having
to alter every instance of now ⇒ jtNow.

Derek

On Mon, Oct 19, 2009 at 6:12 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
 remove it any time soon (in the next year +).  Personally, I don't see a
 compelling reason to remove it from the code base (there may be people who
 would prefer not to use JodaTime).  So, we might need better names than
 jtNow, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Well, yes. I actually had similar code working, but what I was trying to
 avoid is a situation where someone has code like:

 import Helpers._
 ..

 val someTime = now + ( 3 minutes)

 and then to use this code with JodaTime they need to change it to

 val someTime = jtNow + (3 minutes)

 and then when we remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Please take a look at
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

 I think I've got JodaTime and the existing code playing nicely together.


 On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which
 means that branch currently doesn't compile. Maybe I'm overthinking it, but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by
 masking the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, 
 which
 is a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can 
 discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to JodaTime.
 Sure, the month method will have a different result if you pass it a
 JodaTime instance than in you pass it a Date instance.  If this is
 documented, then it's not a problem.

 Existing methods don't get changed.  For methods that return a Date
 or Calendar, there'll be a parallel method (e.g., jNow or somesuch) 
 that
 returns a JodaTime instance.

 Existing methods 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Along those same lines, maybe there should be a common trait that doesn't
define an impl, and then have separate Joda and java.util impl traits that
don't mix directly into Helpers.

On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 What I was thinking earlier is that we can simply make a JodaHelpers object
 that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code changes
 to move to Joda Time would mostly just be an import change instead of having
 to alter every instance of now ⇒ jtNow.

 Derek


 On Mon, Oct 19, 2009 at 6:12 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
 remove it any time soon (in the next year +).  Personally, I don't see a
 compelling reason to remove it from the code base (there may be people who
 would prefer not to use JodaTime).  So, we might need better names than
 jtNow, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Well, yes. I actually had similar code working, but what I was trying to
 avoid is a situation where someone has code like:

 import Helpers._
 ..

 val someTime = now + ( 3 minutes)

 and then to use this code with JodaTime they need to change it to

 val someTime = jtNow + (3 minutes)

 and then when we remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Please take a look at
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

 I think I've got JodaTime and the existing code playing nicely together.


 On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which
 means that branch currently doesn't compile. Maybe I'm overthinking it, 
 but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new
 DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by
 masking the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, 
 which
 is a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can 
 discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 I've just looked at the code.

 There's nothing that's going to be incompatible moving to
 JodaTime.  Sure, the month method will have a different result if you 
 pass
 it a JodaTime instance than 

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Naftoli Gugenheim

Since there are anyway minor breaking changes in 1.1, maybe it's worth it to 
take TimeHelpers out of Helpers. This way, it will simply require an extra 
import, of either TimeHelpers or JodaHelpers, which can be chosen by the 
individual developer.
Whenever someone is ready to migrate, they will be able to do so on a 
file-by-file (or import-scope-by-import-scope) basis.
Eventually JodaHelpers could be included in Helpers.


-
Derek Chen-Beckerdchenbec...@gmail.com wrote:

Along those same lines, maybe there should be a common trait that doesn't
define an impl, and then have separate Joda and java.util impl traits that
don't mix directly into Helpers.

On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 What I was thinking earlier is that we can simply make a JodaHelpers object
 that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code changes
 to move to Joda Time would mostly just be an import change instead of having
 to alter every instance of now ⇒ jtNow.

 Derek


 On Mon, Oct 19, 2009 at 6:12 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
 remove it any time soon (in the next year +).  Personally, I don't see a
 compelling reason to remove it from the code base (there may be people who
 would prefer not to use JodaTime).  So, we might need better names than
 jtNow, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 Well, yes. I actually had similar code working, but what I was trying to
 avoid is a situation where someone has code like:

 import Helpers._
 ..

 val someTime = now + ( 3 minutes)

 and then to use this code with JodaTime they need to change it to

 val someTime = jtNow + (3 minutes)

 and then when we remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Please take a look at
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7

 I think I've got JodaTime and the existing code playing nicely together.


 On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 wip-dcb-issue-89-jodatime. I just checked in everything I have, which
 means that branch currently doesn't compile. Maybe I'm overthinking it, 
 but
 TimeHelpers does define some nice convenience methods and my goal is to
 replicate and extend that with Joda Time.

 Derek


 On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I spoke too soon. If I try to do masking imports, I get errors about
 ambiguous defs:

 [WARNING]
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
 error: reference to now is ambiguous;
 [WARNING] it is imported twice in the same scope by
 [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new
 DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 The major issue is the time DSL. Everything else works fine by
 masking the definitions with a later import, e.g.

 import Helpers._
 import JodaTimeHelpers._

 The problem is that implicit defs (views) don't mask, so I can't
 override or mask it so that 3 seconds returns a Joda Time Duration, 
 which
 is a cleaner way of 

[Lift] Re: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread harryh

 See ProtoExtendedSession

It might be kind of annoying to change at this point, but experation
is a misspelling in this trait.

-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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
That was pretty much what I was trying to communicate with my last email,
just not very effectively.

Derek

On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 Since there are anyway minor breaking changes in 1.1, maybe it's worth it
 to take TimeHelpers out of Helpers. This way, it will simply require an
 extra import, of either TimeHelpers or JodaHelpers, which can be chosen by
 the individual developer.
 Whenever someone is ready to migrate, they will be able to do so on a
 file-by-file (or import-scope-by-import-scope) basis.
 Eventually JodaHelpers could be included in Helpers.


 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 Along those same lines, maybe there should be a common trait that doesn't
 define an impl, and then have separate Joda and java.util impl traits that
 don't mix directly into Helpers.

 On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker dchenbec...@gmail.com
 wrote:

  What I was thinking earlier is that we can simply make a JodaHelpers
 object
  that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code
 changes
  to move to Joda Time would mostly just be an import change instead of
 having
  to alter every instance of now ⇒ jtNow.
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 6:12 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
  remove it any time soon (in the next year +).  Personally, I don't see a
  compelling reason to remove it from the code base (there may be people
 who
  would prefer not to use JodaTime).  So, we might need better names than
  jtNow, etc., but I'm not expecting to make now return a DateTime.
 
 
  On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
   wrote:
 
  Well, yes. I actually had similar code working, but what I was trying
 to
  avoid is a situation where someone has code like:
 
  import Helpers._
  ..
 
  val someTime = now + ( 3 minutes)
 
  and then to use this code with JodaTime they need to change it to
 
  val someTime = jtNow + (3 minutes)
 
  and then when we remove the current java.util impl they would have to
  switch back to the original code. Also, because of all of these issues
 I
  haven't fully worked out things like JodaSpanBuilder, which should
 really be
  using JodaTime's Periods instead of Durations since those take into
 account
  things like daylight savings time and leap years (none of the current
 code
  does that right now, java.util or JodaTime). If this is the best
 compromise
  we can come up with I'll just make a new branch to finish working on
 the
  JodaTime side of things.
 
  Thanks,
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  Please take a look at
 
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7
 
  I think I've got JodaTime and the existing code playing nicely
 together.
 
 
  On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
  dchenbec...@gmail.com wrote:
 
  wip-dcb-issue-89-jodatime. I just checked in everything I have, which
  means that branch currently doesn't compile. Maybe I'm overthinking
 it, but
  TimeHelpers does define some nice convenience methods and my goal is
 to
  replicate and extend that with Joda Time.
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  What branch is the code on?
 
 
  On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
  dchenbec...@gmail.com wrote:
 
  I spoke too soon. If I try to do masking imports, I get errors
 about
  ambiguous defs:
 
  [WARNING]
 
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
  error: reference to now is ambiguous;
  [WARNING] it is imported twice in the same scope by
  [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
  [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
  [WARNING]   3.seconds.later.millis must beCloseTo((now +
  3.seconds).millis, 100L)
 
  Since TimeHelpers is automatically part of Helpers, and import
  Helpers._ is a pretty common import, it's going to require some
 other
  mechanism to get the proper import into scope. Any solution which
 results in
  now returning a java.util.Date essentially defeats the purpose of
 moving
  to Joda Time, since you can just do
 
/** transforms a java.util.Date to a org.joda.time.DateTime */
implicit def dateToDateTime(in : Date) : DateTime = new
  DateTime(in)
 
/** transforms an org.joda.time.DateTime to a java.util.Date */
implicit def dateTimeToDate(in : DateTime) : Date = in.toDate
 
  in your code and get most of it for free. What I'm trying to
 achieve
  here is a refactoring of Lift's time formatting and processing API
 that
  lends itself to clean usage of JodaTime.
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
  dchenbec...@gmail.com wrote:
 
  The 

[Lift] Re: maintaining logged in user longer outside of SessionVar

2009-10-19 Thread Naftoli Gugenheim

It shouldn't be such a problem. All that's needed is to rename it, and add a 
def with the misspelling that points to it, deprecated. Something like
@deprecated def experation = expiration
I guess you could file a ticket and someone will eventually get to it.

-
harryhhar...@gmail.com wrote:


 See ProtoExtendedSession

It might be kind of annoying to change at this point, but experation
is a misspelling in this trait.

-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: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Oh, that was a sidetrack. I was thinking that it could help enforce the
common contract, but return types are different for the same method names so
that really wouldn't work. I really just want to try and separate them out,
or provide a different Helpers that provides JodaTime stuff under the same
method names. My goal is really to minimize code changes, so one or two
imports instead of a lot of find/replace (as simple as that may be) would be
preferable in my book.

Derek

On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 That was pretty much what I was trying to communicate with my last email,
 just not very effectively.

 Derek

 On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Since there are anyway minor breaking changes in 1.1, maybe it's worth it
  to take TimeHelpers out of Helpers. This way, it will simply require an
  extra import, of either TimeHelpers or JodaHelpers, which can be chosen
 by
  the individual developer.
  Whenever someone is ready to migrate, they will be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  Along those same lines, maybe there should be a common trait that doesn't
  define an impl, and then have separate Joda and java.util impl traits
 that
  don't mix directly into Helpers.
 
  On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
  wrote:
 
   What I was thinking earlier is that we can simply make a JodaHelpers
  object
   that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code
  changes
   to move to Joda Time would mostly just be an import change instead of
  having
   to alter every instance of now ⇒ jtNow.
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 6:12 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
   remove it any time soon (in the next year +).  Personally, I don't see
 a
   compelling reason to remove it from the code base (there may be people
  who
   would prefer not to use JodaTime).  So, we might need better names
 than
   jtNow, etc., but I'm not expecting to make now return a DateTime.
  
  
   On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
  dchenbec...@gmail.com
wrote:
  
   Well, yes. I actually had similar code working, but what I was trying
  to
   avoid is a situation where someone has code like:
  
   import Helpers._
   ..
  
   val someTime = now + ( 3 minutes)
  
   and then to use this code with JodaTime they need to change it to
  
   val someTime = jtNow + (3 minutes)
  
   and then when we remove the current java.util impl they would have to
   switch back to the original code. Also, because of all of these
 issues
  I
   haven't fully worked out things like JodaSpanBuilder, which should
  really be
   using JodaTime's Periods instead of Durations since those take into
  account
   things like daylight savings time and leap years (none of the current
  code
   does that right now, java.util or JodaTime). If this is the best
  compromise
   we can come up with I'll just make a new branch to finish working on
  the
   JodaTime side of things.
  
   Thanks,
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   Please take a look at
  
 
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7
  
   I think I've got JodaTime and the existing code playing nicely
  together.
  
  
   On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   wip-dcb-issue-89-jodatime. I just checked in everything I have,
 which
   means that branch currently doesn't compile. Maybe I'm overthinking
  it, but
   TimeHelpers does define some nice convenience methods and my goal
 is
  to
   replicate and extend that with Joda Time.
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   What branch is the code on?
  
  
   On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   I spoke too soon. If I try to do masking imports, I get errors
  about
   ambiguous defs:
  
   [WARNING]
  
 
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
   error: reference to now is ambiguous;
   [WARNING] it is imported twice in the same scope by
   [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._
   [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
   [WARNING]   3.seconds.later.millis must beCloseTo((now +
   3.seconds).millis, 100L)
  
   Since TimeHelpers is automatically part of Helpers, and 

[Lift] Re: Setting Table Border

2009-10-19 Thread Ross Mellgren

That looks right to me -- it should show a border with a default  
stylesheet. When I throw that table.../table into a HTML file by  
itself, I get a border.

-Ross

On Oct 19, 2009, at 8:47 PM, sunanda wrote:


 Hi,
 I need to display the table with border.
 Following is the sample code.
 But it is not displaying the border.Is this the correct way of setting
 the border.

 Sunanda


 def displayColDef(selectedname:String):NodeSeq={

val coldef = getColDef(selectedname)
   table border=2
   tr
   td bDisplay Name/b/td
   td{coldef.displayname}/td
   /tr
   tr
   tdbColumn Type/b /td
   td {coldef.coltype}/td
   /tr
 /table
 }
 


--~--~-~--~~~---~--~~
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: Setting Table Border

2009-10-19 Thread sunanda

Thats what I wonder. It should work. When I refer to a css file with
the border setting it works,
but not with the setting from the snippet. I need to figure it out.
Thanks for your reply.
Sunanda.

On Oct 20, 2:35 pm, Ross Mellgren dri...@gmail.com wrote:
 That looks right to me -- it should show a border with a default  
 stylesheet. When I throw that table.../table into a HTML file by  
 itself, I get a border.

 -Ross

 On Oct 19, 2009, at 8:47 PM, sunanda wrote:





  Hi,
  I need to display the table with border.
  Following is the sample code.
  But it is not displaying the border.Is this the correct way of setting
  the border.

  Sunanda

  def displayColDef(selectedname:String):NodeSeq={

         val coldef = getColDef(selectedname)
            table border=2
            tr
            td bDisplay Name/b/td
            td{coldef.displayname}/td
            /tr
            tr
            tdbColumn Type/b /td
            td {coldef.coltype}/td
            /tr
  /table
  }- Hide quoted text -

 - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
I have a strong preference not to break the TimeHelpers out of Helpers.  I'm
not seeing the problem with additional methods on TimeHelpers that do the
JodaTime thing.  Can you guys help me understand your point of view.

On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Oh, that was a sidetrack. I was thinking that it could help enforce the
 common contract, but return types are different for the same method names so
 that really wouldn't work. I really just want to try and separate them out,
 or provide a different Helpers that provides JodaTime stuff under the same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 That was pretty much what I was trying to communicate with my last email,
 just not very effectively.

 Derek

 On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim naftoli...@gmail.com
 wrote:

 
  Since there are anyway minor breaking changes in 1.1, maybe it's worth
 it
  to take TimeHelpers out of Helpers. This way, it will simply require an
  extra import, of either TimeHelpers or JodaHelpers, which can be chosen
 by
  the individual developer.
  Whenever someone is ready to migrate, they will be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  Along those same lines, maybe there should be a common trait that
 doesn't
  define an impl, and then have separate Joda and java.util impl traits
 that
  don't mix directly into Helpers.
 
  On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
  wrote:
 
   What I was thinking earlier is that we can simply make a JodaHelpers
  object
   that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code
  changes
   to move to Joda Time would mostly just be an import change instead of
  having
   to alter every instance of now ⇒ jtNow.
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 6:12 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   We'll deprecate the Date/Calendar stuff.  I'm not sure we're going to
   remove it any time soon (in the next year +).  Personally, I don't
 see a
   compelling reason to remove it from the code base (there may be
 people
  who
   would prefer not to use JodaTime).  So, we might need better names
 than
   jtNow, etc., but I'm not expecting to make now return a DateTime.
  
  
   On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
  dchenbec...@gmail.com
wrote:
  
   Well, yes. I actually had similar code working, but what I was
 trying
  to
   avoid is a situation where someone has code like:
  
   import Helpers._
   ..
  
   val someTime = now + ( 3 minutes)
  
   and then to use this code with JodaTime they need to change it to
  
   val someTime = jtNow + (3 minutes)
  
   and then when we remove the current java.util impl they would have
 to
   switch back to the original code. Also, because of all of these
 issues
  I
   haven't fully worked out things like JodaSpanBuilder, which should
  really be
   using JodaTime's Periods instead of Durations since those take into
  account
   things like daylight savings time and leap years (none of the
 current
  code
   does that right now, java.util or JodaTime). If this is the best
  compromise
   we can come up with I'll just make a new branch to finish working on
  the
   JodaTime side of things.
  
   Thanks,
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   Please take a look at
  
 
 http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7
  
   I think I've got JodaTime and the existing code playing nicely
  together.
  
  
   On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   wip-dcb-issue-89-jodatime. I just checked in everything I have,
 which
   means that branch currently doesn't compile. Maybe I'm
 overthinking
  it, but
   TimeHelpers does define some nice convenience methods and my goal
 is
  to
   replicate and extend that with Joda Time.
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 3:13 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   What branch is the code on?
  
  
   On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   I spoke too soon. If I try to do masking imports, I get errors
  about
   ambiguous defs:
  
   [WARNING]
  
 
 /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71:
   error: reference to now is ambiguous;
   [WARNING] 

[Lift] Re: edit: What happened to JsonCmd?

2009-10-19 Thread Chris

Done!

On Oct 19, 9:09 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Mon, Oct 19, 2009 at 9:04 AM, Chris coldfusio...@gmail.com wrote:

  So I'm all fixed now wrt JsonCmd's new location.  I noticed that this
  change isn't documented on the github wiki.  Is there a process for
  doing that, or can I just edit the page?

 You can edit the page





  Thanks

  On Oct 15, 8:16 pm, Ross Mellgren dri...@gmail.com wrote:
   The class file names in the jar are determined by the class name /
   scope / access modifiers and other such nonsense, so unlike java
   there's not even a vague 1 : 1 correlation between source file names
   and class file names.

   So,JsonCmdis in Misc.scala, but it will be emitted asJsonCmd.class
   (along with HasParams.class, etc).

   -Ross

   On Oct 15, 2009, at 10:46 PM, Chris wrote:

Well, I pulled all the files from

   http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M6/

and I do see Misc.scala in lift-util-1.1-M6-sources.jar  but not in
lift-util-1.1-M6.jar.  The SHA1 sum matches what was on the server for
that JAR.  Could it have been packaged wrong?

Thanks

On Oct 15, 7:55 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
Ying-Kwang's got it right.

On Wed, Oct 14, 2009 at 9:15 PM, Chris coldfusio...@gmail.com
wrote:

I get

error: Misc is not a member of net.liftweb.util

when I try that.  I don't see the Misc class/object in the API docs
either.  Is there anything else I should try?

Thanks

 --
 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] How to disable a textfield

2009-10-19 Thread sunanda

Hi,
I need to disable all the textfield and then want to enable the fields
for editing on click of a button.
How can i do this with the following sample  code.
Thanks
Regards,
Sunanda.

bind(add,html,
 displayname-coldef.displayname.toForm,
 columntype-coldef.coltype.toForm,
 sourceview-coldef.sourceview.toForm)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---