[Lift] Re: Creating calculated fields in mapper
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 ?
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 ?
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 ?
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 ?
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
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 ?
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
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'
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?
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?
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 ?
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?
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
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?
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
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
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
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
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
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
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?
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?
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
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?
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
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
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?
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?
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?
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?
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?
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?
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
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?
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?
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
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
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
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
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?
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
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?
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?
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
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?
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?
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?
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
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?
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
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?
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
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
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?
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?
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
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 -~--~~~~--~~--~--~---