[Lift] Re: date management
Box is the base class. What you want is Full("2").
Derek
On Wed, Jun 3, 2009 at 8:53 PM, g-man wrote:
>
> Very good!
>
> I did a little homework, rearranged some things, and am getting some
> nice results with the 'manual method'...
>
> Since I am following the PocketChange app now rather than the ToDo
> example, there is no 'todo' val in scope to bind, so the
> todo.priority.toForm method will not work.
>
> I have SHtml.select working with a mapping for my choices, and I can
> use Empty for my default, but how do I get a Box["2"] as my default?
>
>
> On Jun 3, 7:21 am, Derek Chen-Becker wrote:
> > The only issue I would mention is that there's currently an open ticket
> > because MappedDateTime won't save the time portion when you use Derby. I
> > haven't had time to triage this yet.
> >
> > Derek
> >
> > On Wed, Jun 3, 2009 at 3:01 AM, Timothy Perrett >wrote:
> >
> >
> >
> > > Greg,
> >
> > > I dont really use toForm; have you explored "doing it manually"? It
> > > seems like that would be able to tell you if there is a problem with
> > > toForm on MappedDateTime.
> >
> > > I use mapped date time quite a bit and have no problems at all
> > > persisting the dates :-)
> >
> > > Cheers, Tim
> >
> > > On Jun 3, 3:09 am, g-man wrote:
> > > > Are there no ideas for my problem?
> >
> > > > I have many more questions saved up, but would like to clear each out
> > > > before starting a new one.
> >
> > > > Thanks again!
> >
> > > > On May 31, 1:57 pm, g-man wrote:
> >
> > > > > As I proceed to enhance the ToDo example, I have added a new field
> to
> > > > > the ToDo.scala model:
> >
> > > > > object dueOn extends MappedDateTime(this) {
> > > > > final val dateFormat = DateFormat.getDateInstance
> > > > > (DateFormat.SHORT)
> > > > > override def asHtml = Text(dateFormat.format(is))}
> >
> > > > > Next, I added a binding in the TD.scala snippet within the add
> method
> > > > > of the TD class:
> >
> > > > > def doBind(form: NodeSeq) = {
> > > > > bind("todo", form, "desc" -> todo.desc.toForm,
> > > > > "priority" -> todo.priority.toForm,
> > > > > "dueOn" -> todo.dueOn.toForm,
> > > > > "submit" -> submit("create new Task",
> > > > > checkAndSave)}
> >
> > > > > Then, the todo.html template gets a bind point:
> >
> > > > >
> > > > > ...
> > > > >
> > > > >
> > > > >
> >
> > > > > When I check the database, the record does save, and all the other
> > > > > fields are OK, but the date itself is .
> >
> > > > > Somehow, it seems the text of the input field is not getting
> changed
> > > > > into a Date object for the database to handle, right?
> >
> > > > > When I look at the PocketChange app from the book, everything is
> done
> > > > > completely differently from the ToDo example (no use of _toForm,
> for
> > > > > instance).
> >
> > > > > I know dates and times are convoluted in Java, so what am I
> missing?
> >
> > > > > 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: Issue #12
On Wed, Jun 3, 2009 at 3:56 PM, Derek Chen-Becker wrote: > I'm looking at issue #12: > > http://github.com/dpp/liftweb/issues#issue/12 > > I think I've tracked it down to an issue with the way Mapper handles date > and time data. Mapper doesn't use setTimestamp anywhere for prepared > statements, only setDate or setObject. The issue is that SQL Dates really > are just dates, not date + time. In particular, MappedDateTime's > jdbcFriendly and real_convertToJDBCFriendly methods are returning > java.sql.Dates, when they really should return java.sql.Timestamps. Also, > DB.runQuery uses a setDate instead of setTimestamp when the passed parameter > type is java.util.Date, and MetaMapper's BySql clause uses java.sql.Date. > The MetaMapper.save method uses st.setObject to set field values when > inserting and/or updating, and passes the java.sql.Types parameter > (TIMESTAMP, for MappedDateTime), but Derby is discarding the time portion. > This may also be a bug in Derby, but I don't think that we should be using > java.sql.Date for a TIMESTAMP field, either. Unless anyone has objections, I > propose that: > > >1. The jdbcFriendly and convert_real... methods on MappedDateTime be >changed to return java.sql.Timestamp instead of java.sql.Date >2. Change the BySQL clause to use a setTimestamp for the parameter if >the passed data is java.sql.Timestamp or java.util.Date, and use setDate >only if the passed data is already java.sql.Date. That way people can be >more explicit about which type they actually want >3. Make a similar change to DB.runQuery's parameter handling >4. Add a MappedDate and MappedTime for people who explicitly only want >a Date or Time respectively > > Thoughts? I'll go ahead and get this done this week unless anyone can > explain why we wouldn't want to do this. Sounds like a great analysis. Looking forward to the fixes. > > > Derek > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: date management
Very good!
I did a little homework, rearranged some things, and am getting some
nice results with the 'manual method'...
Since I am following the PocketChange app now rather than the ToDo
example, there is no 'todo' val in scope to bind, so the
todo.priority.toForm method will not work.
I have SHtml.select working with a mapping for my choices, and I can
use Empty for my default, but how do I get a Box["2"] as my default?
On Jun 3, 7:21 am, Derek Chen-Becker wrote:
> The only issue I would mention is that there's currently an open ticket
> because MappedDateTime won't save the time portion when you use Derby. I
> haven't had time to triage this yet.
>
> Derek
>
> On Wed, Jun 3, 2009 at 3:01 AM, Timothy Perrett
> wrote:
>
>
>
> > Greg,
>
> > I dont really use toForm; have you explored "doing it manually"? It
> > seems like that would be able to tell you if there is a problem with
> > toForm on MappedDateTime.
>
> > I use mapped date time quite a bit and have no problems at all
> > persisting the dates :-)
>
> > Cheers, Tim
>
> > On Jun 3, 3:09 am, g-man wrote:
> > > Are there no ideas for my problem?
>
> > > I have many more questions saved up, but would like to clear each out
> > > before starting a new one.
>
> > > Thanks again!
>
> > > On May 31, 1:57 pm, g-man wrote:
>
> > > > As I proceed to enhance the ToDo example, I have added a new field to
> > > > the ToDo.scala model:
>
> > > > object dueOn extends MappedDateTime(this) {
> > > > final val dateFormat = DateFormat.getDateInstance
> > > > (DateFormat.SHORT)
> > > > override def asHtml = Text(dateFormat.format(is))}
>
> > > > Next, I added a binding in the TD.scala snippet within the add method
> > > > of the TD class:
>
> > > > def doBind(form: NodeSeq) = {
> > > > bind("todo", form, "desc" -> todo.desc.toForm,
> > > > "priority" -> todo.priority.toForm,
> > > > "dueOn" -> todo.dueOn.toForm,
> > > > "submit" -> submit("create new Task",
> > > > checkAndSave)}
>
> > > > Then, the todo.html template gets a bind point:
>
> > > >
> > > > ...
> > > >
> > > >
> > > >
>
> > > > When I check the database, the record does save, and all the other
> > > > fields are OK, but the date itself is .
>
> > > > Somehow, it seems the text of the input field is not getting changed
> > > > into a Date object for the database to handle, right?
>
> > > > When I look at the PocketChange app from the book, everything is done
> > > > completely differently from the ToDo example (no use of _toForm, for
> > > > instance).
>
> > > > I know dates and times are convoluted in Java, so what am I missing?
>
> > > > 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] Issue #12
I'm looking at issue #12: http://github.com/dpp/liftweb/issues#issue/12 I think I've tracked it down to an issue with the way Mapper handles date and time data. Mapper doesn't use setTimestamp anywhere for prepared statements, only setDate or setObject. The issue is that SQL Dates really are just dates, not date + time. In particular, MappedDateTime's jdbcFriendly and real_convertToJDBCFriendly methods are returning java.sql.Dates, when they really should return java.sql.Timestamps. Also, DB.runQuery uses a setDate instead of setTimestamp when the passed parameter type is java.util.Date, and MetaMapper's BySql clause uses java.sql.Date. The MetaMapper.save method uses st.setObject to set field values when inserting and/or updating, and passes the java.sql.Types parameter (TIMESTAMP, for MappedDateTime), but Derby is discarding the time portion. This may also be a bug in Derby, but I don't think that we should be using java.sql.Date for a TIMESTAMP field, either. Unless anyone has objections, I propose that: 1. The jdbcFriendly and convert_real... methods on MappedDateTime be changed to return java.sql.Timestamp instead of java.sql.Date 2. Change the BySQL clause to use a setTimestamp for the parameter if the passed data is java.sql.Timestamp or java.util.Date, and use setDate only if the passed data is already java.sql.Date. That way people can be more explicit about which type they actually want 3. Make a similar change to DB.runQuery's parameter handling 4. Add a MappedDate and MappedTime for people who explicitly only want a Date or Time respectively Thoughts? I'll go ahead and get this done this week unless anyone can explain why we wouldn't want to do this. Derek --~--~-~--~~~---~--~~ 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: Switch to Scala 2.7.5 for 1.1 ?
On Wed, Jun 3, 2009 at 3:32 PM, Timothy Perrett wrote: > > +1 > > This seems like the most sensible suggestion as a lot of people will > only want to run apps in production against releases or milestones, > not snapshots. We have not finalized 1.0.1... I'm cool with building it against 2.7.5. Who wants to own it? > > > Cheers, Tim > > On Jun 3, 10:32 pm, Jorge Ortiz wrote: > > In general I thought the plan for 1.1 was to compile against 2.8. > > > > If anything we might want a 1.0.1 against 2.7.5. > > > > --j > > > > On Wed, Jun 3, 2009 at 1:26 PM, Heiko Seeberger < > > > > > > > > heiko.seeber...@googlemail.com> wrote: > > > Hi, > > > I wonder if we should switch to Scala 2.7.5. I do not know whether the > > > actor fixes are relevant as Lift has got its own actor library now. But > for > > > users of the Scala IDE for Eclipse (like me) it might be beneficial, > because > > > the Scala IDE ships with 2.7.5. > > > > > Cheers > > > Heiko > > > -- > > > My blog: heikoseeberger.name > > > Follow me: twitter.com/hseeberger > > > OSGi on Scala:www.scalamodules.org > > > Lift, the simply functional web framework: liftweb.net > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Switch to Scala 2.7.5 for 1.1 ?
+1 This seems like the most sensible suggestion as a lot of people will only want to run apps in production against releases or milestones, not snapshots. Cheers, Tim On Jun 3, 10:32 pm, Jorge Ortiz wrote: > In general I thought the plan for 1.1 was to compile against 2.8. > > If anything we might want a 1.0.1 against 2.7.5. > > --j > > On Wed, Jun 3, 2009 at 1:26 PM, Heiko Seeberger < > > > > heiko.seeber...@googlemail.com> wrote: > > Hi, > > I wonder if we should switch to Scala 2.7.5. I do not know whether the > > actor fixes are relevant as Lift has got its own actor library now. But for > > users of the Scala IDE for Eclipse (like me) it might be beneficial, because > > the Scala IDE ships with 2.7.5. > > > Cheers > > Heiko > > -- > > My blog: heikoseeberger.name > > Follow me: twitter.com/hseeberger > > OSGi on Scala:www.scalamodules.org > > Lift, the simply functional web framework: liftweb.net --~--~-~--~~~---~--~~ 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: Switch to Scala 2.7.5 for 1.1 ?
In general I thought the plan for 1.1 was to compile against 2.8. If anything we might want a 1.0.1 against 2.7.5. --j On Wed, Jun 3, 2009 at 1:26 PM, Heiko Seeberger < heiko.seeber...@googlemail.com> wrote: > Hi, > I wonder if we should switch to Scala 2.7.5. I do not know whether the > actor fixes are relevant as Lift has got its own actor library now. But for > users of the Scala IDE for Eclipse (like me) it might be beneficial, because > the Scala IDE ships with 2.7.5. > > Cheers > Heiko > -- > My blog: heikoseeberger.name > Follow me: twitter.com/hseeberger > OSGi on Scala: www.scalamodules.org > Lift, the simply functional web framework: liftweb.net > > > > --~--~-~--~~~---~--~~ 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: Switch to Scala 2.7.5 for 1.1 ?
On Wed, Jun 3, 2009 at 9:26 PM, Heiko Seeberger wrote: > I wonder if we should switch to Scala 2.7.5. I do not know whether the actor > fixes are relevant as Lift has got its own actor library now. But for users > of the Scala IDE for Eclipse (like me) it might be beneficial, because the > Scala IDE ships with 2.7.5. Other than the change to the Scala distribution that's bundled with the IDE there are no changes in 2.7.5, so the only thing you'd be missing out on would be the actors changes (tho' I think that's enough of a reason to want to upgrade). Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://twitter.com/milessabin --~--~-~--~~~---~--~~ 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: Switch to Scala 2.7.5 for 1.1 ?
On Wed, Jun 3, 2009 at 1:26 PM, Heiko Seeberger < heiko.seeber...@googlemail.com> wrote: > Hi, > I wonder if we should switch to Scala 2.7.5. I do not know whether the > actor fixes are relevant as Lift has got its own actor library now. But for > users of the Scala IDE for Eclipse (like me) it might be beneficial, because > the Scala IDE ships with 2.7.5. > It should not make a difference to the IDE if you're on 2.7.4 or 2.7.5 unless they made other changes to the libraries. Has anyone looked at the changeset between the 2.7.4 and 2.7.5 tags? In terms of the Actor changes, I won't believe them until I see them. I've been burned many times between Scala 2.7.2 and 2.7.4 with spending days testing the new Actor stuff, finding minor issues, reporting issues, battling over issues, blah blah blah. I'm currently about a week behind and don't plan to spend a day testing the new Actor stuff. Maybe after the Open Source bridge, I'll play more with it. If someone else wants to put together a hard-core comprehensive test of the 2.7.5 Actor code such that the tests cause memory leaks in the 2.7.4 code, but don't in the 2.7.5 code, that would help a lot. Thanks, David > > Cheers > Heiko > -- > My blog: heikoseeberger.name > Follow me: twitter.com/hseeberger > OSGi on Scala: www.scalamodules.org > Lift, the simply functional web framework: liftweb.net > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Switch to Scala 2.7.5 for 1.1 ?
Hi, I wonder if we should switch to Scala 2.7.5. I do not know whether the actor fixes are relevant as Lift has got its own actor library now. But for users of the Scala IDE for Eclipse (like me) it might be beneficial, because the Scala IDE ships with 2.7.5. Cheers Heiko -- My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~-~--~~~---~--~~ 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: Comet request exception
I just tested against 6.1.18 and it works just fine. Can you post the source of your failing app and a link to your version of Jetty and I'll track it down? Thanks, David On Wed, Jun 3, 2009 at 12:19 PM, feelgood wrote: > > I just copied comet sample named "Clock" from the p. 142 of the > liftbook into my app. It doesn't work. First time it renders timestamp > normally, but since 10 seconds: > > WARN - Request for /comet_request/58946720417/1ha35q9iqp4el failed > Bail > java.lang.Exception: Bail >at net.liftweb.http.LiftRules$.doContinuation(LiftRules.scala:436) >at net.liftweb.http.LiftServlet.setupContinuation(LiftServlet.scala: > 352) >at net.liftweb.http.LiftServlet.handleComet(LiftServlet.scala:363) >at net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ > $dispatchStatefulRequest(LiftServlet.scala:232) >at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: > 155) >at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: > 155) >at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:908) >at > net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ > $anonfun$apply$18.apply(S.scala:1026) >at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:845) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply > (S.scala:846) >at net.liftweb.mapper.DB$$anon$1.net > $liftweb$mapper$DB$$anon$$doWith > (DB.scala:117) >at > net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ > $doWith$1.apply(DB.scala:118) >at > net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ > $doWith$1.apply(DB.scala:118) >at net.liftweb.mapper.DB$.use(DB.scala:305) >at net.liftweb.mapper.DB$$anon$1.net > $liftweb$mapper$DB$$anon$$doWith > (DB.scala:118) >at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:124) >at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:846) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit > $1.apply(S.scala:1024) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala: > 1023) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24$$anonfun$apply$25$$anonfun$apply$26.apply(S.scala:1044) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24$$anonfun$apply$25.apply(S.scala:1043) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24.apply(S.scala:1042) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23.apply(S.scala: > 1041) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21$$anonfun$apply$22.apply(S.scala:1040) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ > $anonfun$apply$21.apply(S.scala:1039) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at > net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply > (S.scala:1038) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1037) >at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun > $apply$30$$anonfun$apply$31$$anonfun$apply$32.apply(S.scala:1068) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun > $apply$30$$anonfun$apply$31.apply(S.scala:1067) >at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:191) >at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun > $apply$30.apply(S.scala:1066) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29.apply > (S.scala:1065) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1064) >at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) >at net.liftweb.http.S$._init(S.scala:1063) >at net.liftweb.http.S$.init(S.scala:779) >at net.liftweb.http.LiftServlet.doService(LiftServlet.scala:154) >at net.liftw
[Lift] Re: Useless error messages if template parsing fails?
On 3 Jun 2009, Derek Chen-Becker wrote: > Improving error messages is something we're working on. I'll have to > look at the source, but if there's a more meaningful exception that's > somehow getting swallowed then I'd say that that's a bug. Let me dig > and see what's going on. If my analysis is correct, scala.io.Source.getLine always fails with an IllegalArgumentException when used with an InputStream (as is the case when Lift parses the templates). I think the reset method is wrong in this case. /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] Comet request exception
I just copied comet sample named "Clock" from the p. 142 of the liftbook into my app. It doesn't work. First time it renders timestamp normally, but since 10 seconds: WARN - Request for /comet_request/58946720417/1ha35q9iqp4el failed Bail java.lang.Exception: Bail at net.liftweb.http.LiftRules$.doContinuation(LiftRules.scala:436) at net.liftweb.http.LiftServlet.setupContinuation(LiftServlet.scala: 352) at net.liftweb.http.LiftServlet.handleComet(LiftServlet.scala:363) at net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:232) at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: 155) at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: 155) at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:908) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ $anonfun$apply$18.apply(S.scala:1026) at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:845) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply (S.scala:846) at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith (DB.scala:117) at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ $doWith$1.apply(DB.scala:118) at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ $doWith$1.apply(DB.scala:118) at net.liftweb.mapper.DB$.use(DB.scala:305) at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith (DB.scala:118) at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:124) at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:846) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit $1.apply(S.scala:1024) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala: 1023) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24$$anonfun$apply$25$$anonfun$apply$26.apply(S.scala:1044) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24$$anonfun$apply$25.apply(S.scala:1043) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24.apply(S.scala:1042) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23.apply(S.scala: 1041) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22.apply(S.scala:1040) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21.apply(S.scala:1039) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply (S.scala:1038) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1037) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30$$anonfun$apply$31$$anonfun$apply$32.apply(S.scala:1068) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30$$anonfun$apply$31.apply(S.scala:1067) at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:191) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30.apply(S.scala:1066) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29.apply (S.scala:1065) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1064) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$._init(S.scala:1063) at net.liftweb.http.S$.init(S.scala:779) at net.liftweb.http.LiftServlet.doService(LiftServlet.scala:154) at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply (LiftServlet.scala:83) at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply (LiftServlet.scala:83) at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241) at net.liftweb.util.Helpers$.calcTime(Helpers.scala:29) at net.liftweb.util.TimeHelpers$class.logTime(TimeHel
[Lift] Re: Useless error messages if template parsing fails?
On Wed, Jun 3, 2009 at 12:10 PM, David Pollak wrote: > > > On Wed, Jun 3, 2009 at 12:05 PM, Derek Chen-Becker > wrote: > >> Improving error messages is something we're working on. I'll have to look >> at the source, but if there's a more meaningful exception that's somehow >> getting swallowed then I'd say that that's a bug. Let me dig and see what's >> going on. > > > I'm working on it and generally improving error reporting for XML parsing > Okay... the line and character of the parsing problem will be reported on the console. Additionally, if you're in development mode, you'll see a much nicer display in your browser of the template that has the error and the location of the error. > > > >> >> >> Derek >> >> >> On Wed, Jun 3, 2009 at 12:42 PM, Joe Wass wrote: >> >>> >>> I'm getting this too (on Ubuntu). I thought it was standard behaviour >>> to see a stack trace... obviously not! >>> >>> On Jun 3, 7:23 pm, Jeppe Nejsum Madsen wrote: >>> > I'm curious: Am I the only one getting rather useless error messages in >>> > the browser when Lift fails to parse the templates? Something a long >>> > these lines: >>> > >>> > Exception occured while processing / >>> > >>> > Message: java.lang.IllegalArgumentException: line 15 does not exist >>> > scala.io.Source.getLine(Source.scala:280) >>> > scala.io.Source.report(Source.scala:368) >>> > >>> > It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I >>> > did a little digging in scala.io.Source and found what seems to be a >>> bug >>> > (more details here, never mind the subject :-) >>> http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td2... >>> > ) >>> > >>> > Running in debug mode I saw that the original exception was "'<' not >>> > allowed in attrib value" which seems much more helpful :-) >>> > >>> > Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the >>> > only one seeing this behaviour. >>> > >>> > /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 > Git some: http://github.com/dpp > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Useless error messages if template parsing fails?
Cool beans :) On Wed, Jun 3, 2009 at 1:10 PM, David Pollak wrote: > > > On Wed, Jun 3, 2009 at 12:05 PM, Derek Chen-Becker > wrote: > >> Improving error messages is something we're working on. I'll have to look >> at the source, but if there's a more meaningful exception that's somehow >> getting swallowed then I'd say that that's a bug. Let me dig and see what's >> going on. > > > I'm working on it and generally improving error reporting for XML parsing > > >> >> >> Derek >> >> >> On Wed, Jun 3, 2009 at 12:42 PM, Joe Wass wrote: >> >>> >>> I'm getting this too (on Ubuntu). I thought it was standard behaviour >>> to see a stack trace... obviously not! >>> >>> On Jun 3, 7:23 pm, Jeppe Nejsum Madsen wrote: >>> > I'm curious: Am I the only one getting rather useless error messages in >>> > the browser when Lift fails to parse the templates? Something a long >>> > these lines: >>> > >>> > Exception occured while processing / >>> > >>> > Message: java.lang.IllegalArgumentException: line 15 does not exist >>> > scala.io.Source.getLine(Source.scala:280) >>> > scala.io.Source.report(Source.scala:368) >>> > >>> > It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I >>> > did a little digging in scala.io.Source and found what seems to be a >>> bug >>> > (more details here, never mind the subject :-) >>> http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td2... >>> > ) >>> > >>> > Running in debug mode I saw that the original exception was "'<' not >>> > allowed in attrib value" which seems much more helpful :-) >>> > >>> > Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the >>> > only one seeing this behaviour. >>> > >>> > /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 > Git some: http://github.com/dpp > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Useless error messages if template parsing fails?
On Wed, Jun 3, 2009 at 12:05 PM, Derek Chen-Becker wrote: > Improving error messages is something we're working on. I'll have to look > at the source, but if there's a more meaningful exception that's somehow > getting swallowed then I'd say that that's a bug. Let me dig and see what's > going on. I'm working on it and generally improving error reporting for XML parsing > > > Derek > > > On Wed, Jun 3, 2009 at 12:42 PM, Joe Wass wrote: > >> >> I'm getting this too (on Ubuntu). I thought it was standard behaviour >> to see a stack trace... obviously not! >> >> On Jun 3, 7:23 pm, Jeppe Nejsum Madsen wrote: >> > I'm curious: Am I the only one getting rather useless error messages in >> > the browser when Lift fails to parse the templates? Something a long >> > these lines: >> > >> > Exception occured while processing / >> > >> > Message: java.lang.IllegalArgumentException: line 15 does not exist >> > scala.io.Source.getLine(Source.scala:280) >> > scala.io.Source.report(Source.scala:368) >> > >> > It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I >> > did a little digging in scala.io.Source and found what seems to be a bug >> > (more details here, never mind the subject :-) >> http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td2... >> > ) >> > >> > Running in debug mode I saw that the original exception was "'<' not >> > allowed in attrib value" which seems much more helpful :-) >> > >> > Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the >> > only one seeing this behaviour. >> > >> > /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 Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Problem with Menu.builder & li_path/li_item
On 3 Jun 2009, David Pollak wrote: > I've pushed up a fix Excellent, thanks! When I finally figured out how to use the li_* attributes I thought it was a very nice way to make the snippets configurable. Great was the dismay when I found it didn't work :-( /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: Useless error messages if template parsing fails?
Improving error messages is something we're working on. I'll have to look at the source, but if there's a more meaningful exception that's somehow getting swallowed then I'd say that that's a bug. Let me dig and see what's going on. Derek On Wed, Jun 3, 2009 at 12:42 PM, Joe Wass wrote: > > I'm getting this too (on Ubuntu). I thought it was standard behaviour > to see a stack trace... obviously not! > > On Jun 3, 7:23 pm, Jeppe Nejsum Madsen wrote: > > I'm curious: Am I the only one getting rather useless error messages in > > the browser when Lift fails to parse the templates? Something a long > > these lines: > > > > Exception occured while processing / > > > > Message: java.lang.IllegalArgumentException: line 15 does not exist > > scala.io.Source.getLine(Source.scala:280) > > scala.io.Source.report(Source.scala:368) > > > > It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I > > did a little digging in scala.io.Source and found what seems to be a bug > > (more details here, never mind the subject :-) > http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td2... > > ) > > > > Running in debug mode I saw that the original exception was "'<' not > > allowed in attrib value" which seems much more helpful :-) > > > > Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the > > only one seeing this behaviour. > > > > /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: Useless error messages if template parsing fails?
I'm getting this too (on Ubuntu). I thought it was standard behaviour to see a stack trace... obviously not! On Jun 3, 7:23 pm, Jeppe Nejsum Madsen wrote: > I'm curious: Am I the only one getting rather useless error messages in > the browser when Lift fails to parse the templates? Something a long > these lines: > > Exception occured while processing / > > Message: java.lang.IllegalArgumentException: line 15 does not exist > scala.io.Source.getLine(Source.scala:280) > scala.io.Source.report(Source.scala:368) > > It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I > did a little digging in scala.io.Source and found what seems to be a bug > (more details here, never mind the subject > :-)http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td2... > ) > > Running in debug mode I saw that the original exception was "'<' not > allowed in attrib value" which seems much more helpful :-) > > Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the > only one seeing this behaviour. > > /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] Useless error messages if template parsing fails?
I'm curious: Am I the only one getting rather useless error messages in the browser when Lift fails to parse the templates? Something a long these lines: Exception occured while processing / Message: java.lang.IllegalArgumentException: line 15 does not exist scala.io.Source.getLine(Source.scala:280) scala.io.Source.report(Source.scala:368) It may just be my setup (Scala 2.7.4, Lift 1.1-SNAPSHOT, OS X), but I did a little digging in scala.io.Source and found what seems to be a bug (more details here, never mind the subject :-) http://www.nabble.com/Bug-in-java.io.Source-with-FileInputStream--td23840934.html ) Running in debug mode I saw that the original exception was "'<' not allowed in attrib value" which seems much more helpful :-) Anyway, since I'm new to Scala/Lift I just wanted to verify if I'm the only one seeing this behaviour. /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 Menu.builder & li_path/li_item
I've pushed up a fix On Wed, Jun 3, 2009 at 9:01 AM, David Pollak wrote: > This is a bug in the Scala XML parser... I'll fix (work around) the bug > today. > > > On Wed, Jun 3, 2009 at 7:20 AM, Jeppe Nejsum Madsen wrote: > >> >> On 3 Jun 2009, marius d. wrote: >> >> >> > attribute with the same name but different prefixes should be ok as >> > long as the prefixes are bound to namespace URL's. >> >> But the problem here is that the attributes are in an inner template, >> which, I presume, will be read before the outer template (with the >> namespace URLs). Parsing the inner template fails as shown previously. >> >> On a conceptual level I don't think the li_path, li_item namespaces >> should be declared in the resulting page produced by lift. It is used >> solely by Lift for the rendering. But it seems these kind of prefixes in >> xml fragments are not supported by the Scala XML parser. >> >> /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 > Git some: http://github.com/dpp > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Future of the Lift wiki
That's fantastic we have a couple of folks willing to contribute to the wiki! I'm cc-ing Debby as she's great with organizing things (in case she doesn't watch this thread). Debby any thoughts ? Br's, Marius On Jun 2, 5:16 pm, "Bryan." wrote: > I too am willing to help. > > I really like the format of the django > documentation:http://docs.djangoproject.com/en/dev/. Any other > recommendations out > there? > > Thanks, > Bryan > > On Jun 2, 6:57 am, Kevin Wright wrote: > > > Mark me down :) > > > On Tue, Jun 2, 2009 at 9:36 AM, marius d. wrote: > > > > I believe Debbie was asking the community for a few folks willing to > > > "garden" the wiki. Anyone interested? > > > > Br's, > > > Marius > > > > On Jun 2, 11:07 am, Timothy Perrett wrote: > > > > Guys, > > > > > I know you chaps are quite new on this lift, so just to add a bit of > > > > background - we've been here many, many times before with various > > > > people pledging to fix and cleanup the wiki (myself included!) > > > > > After much discussion we decided that what was needed were gardeners - > > > > not perhaps to write the articles themselves (as they may not be able > > > > to if its about complex lift internals), but rather, to hassle the > > > > commit team into churning out the required information that the > > > > gardeners can distill onto the wiki. This involves going through the > > > > current wiki and removing the old / irrelevant stuff. > > > > > Cheers, Tim > > > > > On Jun 2, 3:36 am, g-man wrote: > > > > > > Having gone through Rails, the Google App Engine with Django, and > > > > > web2py over the last four years, I have seen it all as far as learning > > > > > new frameworks goes, and I have posted a few ideas on that subject > > > > > both here and on the book group. > > > > > > For those of us spoiled by the wealth of learning material on Rails, > > > > > and to a lesser degree Django and web2py, all I can say is: 'Lift is a > > > > > new framework, and a sophisticated one at that, which uses a new > > > > > language derived from a convoluted one, and is at a relatively early > > > > > stage of development, so therefore the designers are forging ahead to > > > > > completion of the foundation, and thus there are few who can devote > > > > > the time to creating the documentation we newcomers need.' > > > > > > My post on the book group defined the three classes of useful > > > > > documents to be the Guidebook, the Encyclopedia, and the Cookbook. My > > > > > role for the wiki is to hold Cookbook recipes which answer the most > > > > > common 'how to' questions we encounter when building a website. > > > > > > In my personal learning quest, I am extending the 'ToDo' app by adding > > > > > pieces of functionality, like many-to-many tagging, date manipulation, > > > > > deletion, an admin interface, etc. > > > > > > As I come across solutions or questions, I post those on the group in > > > > > order to help others and to get improvements and refinements from the > > > > > members. > > > > > > David is right... Lift and Scala together are taking web applications > > > > > to a whole new level of performance, so naturally it will take a > > > > > little time to make things happen. > > > > > > By the way, today my copies of David's and Martin's Scala books > > > > > arrived, and I urge all to purchase them yourselves! > > > > > > On Jun 1, 3:35 pm, "Charles F. Munat" wrote: > > > > > > > Hi, Xavi, > > > > > > > One of my tasks is to come up with a good organization for the wiki > > > and > > > > > > a site map, as well as a list of things we'd like to add to it. > > > > > > Unfortunately, with the coming Scala/Liftoff and OSB conferences, > > > I've > > > > > > been swamped with other things. But I am working on it, albeit > > > slowly. > > > > > > If you have any specific recommendations, please post them. > > > > > > > Thanks! > > > > > > > Chas. > > > > > > > Xavi Ramirez wrote: > > > > > > > Hello, > > > > > > > > I'm a bit confused about the future of the lift wiki. What's the > > > end > > > > > > > goal? In an ideal world is it supposed to be the main repository > > > of > > > > > > > lift knowledge, or just another documentation source? > > > > > > > > I personally feel that having one repository of knowledge is much > > > more > > > > > > > noob friendly. Currently new members have to navigate through > > > started > > > > > > > guides, books, e-mail threads, scala docs, and personal blogs to > > > find > > > > > > > relative information. Though the get started guided and book > > > provide > > > > > > > a good introduction, it's hard to progress from novice to > > > intermediate > > > > > > > with these fragmented resources. > > > > > > > > Thanks, > > > > > > > Xavi --~--~-~--~~~---~--~~ 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, sen
[Lift] Re: Problem with Menu.builder & li_path/li_item
This is a bug in the Scala XML parser... I'll fix (work around) the bug today. On Wed, Jun 3, 2009 at 7:20 AM, Jeppe Nejsum Madsen wrote: > > On 3 Jun 2009, marius d. wrote: > > > > attribute with the same name but different prefixes should be ok as > > long as the prefixes are bound to namespace URL's. > > But the problem here is that the attributes are in an inner template, > which, I presume, will be read before the outer template (with the > namespace URLs). Parsing the inner template fails as shown previously. > > On a conceptual level I don't think the li_path, li_item namespaces > should be declared in the resulting page produced by lift. It is used > solely by Lift for the rendering. But it seems these kind of prefixes in > xml fragments are not supported by the Scala XML parser. > > /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 Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: how to serve html fragments
On Wed, Jun 3, 2009 at 7:40 AM, fatu wrote: > > ...Another question for now :-) > > Does it work for views as well? It should. Views are treated just like static XHTML files... a source of NodeSeq > > > Many thanks. > > Fabio > > On 21 Mag, 15:38, David Pollak wrote: > > On Thu, May 21, 2009 at 12:27 AM, fatu wrote: > > > > > Right, didn't think about that alternative. > > > > > Thanks and best compliments to you and all the active Lift community > > > for this superb Scala framework! I really think (and hope) it's going > > > to have a big impact and a tremendous popularity rise in the next > > > months, especially with more forthcoming books and articles spreading > > > the word. > > > > We ask two things: build cool apps in Lift and be part of this community, > > asking and answering questions. > > > > Thanks! > > > > > > > > > > > > > On 21 Mag, 06:42, David Pollak wrote: > > > > On Wed, May 20, 2009 at 8:38 PM, fatu wrote: > > > > > > > Hi David, > > > > > > > yes it will do, thank you so much for such a lightning-fast > > > > > development in reply! > > > > > > > I'm only thinking about a case that is probably much more of an > > > > > exception than a rule, i.e. when the snippet dynamically decides if > it > > > > > needs to generate a full page or a fragment (which is not a very > good > > > > > design anyway IMHO), for example based on some info passed. But > even > > > > > in that case the snippet will know that and will be able to set > > > > > S.skipDocType = true accordingly, so it should be perfectly fine. > Plus > > > > > it won't be difficult at all to make the processing diverge in the > 2 > > > > > cases by using URL rewrites, redirecting it to a different template > / > > > > > snippet depending on parameters or URL structure, which is probably > a > > > > > better design too. > > > > > > You could also pass a header flag from your AJAX call. If the > header's > > > set, > > > > you don't do the boilerplate surround that'll include all the , > > > > > > > and tags. > > > > > > Anyway, enjoy and thanks for the use case. > > > > > > Party on. > > > > > > > Again many thanks everyone and David especially! > > > > > > > On May 20, 4:05 pm, David Pollak > > > > > wrote: > > > > > > I'm about to commit S.skipDocType = true | false. If you set it > to > > > true, > > > > > > the will be omitted from the response page. This > > > will > > > > > allow > > > > > > your AJAX fragements to pull parts of pages from the server. > Note > > > that > > > > > > someplace in your snippets, you'll have to set S.skipDocType = > true. > > > > > > > > Does this address your issue? > > > > > > > > On Wed, May 20, 2009 at 5:13 AM, fatu wrote: > > > > > > > > > Hi Marius, > > > > > > > > > as I understand them, Jx classes help in generating JS that can > > > itself > > > > > > > generate DOM at the client. Am I wrong? I'd really like to > serve > > > back > > > > > > > an HTML fragment built by using the normal Lift template > pipeline > > > (so > > > > > > > including surround & bind). Is that possible? > > > > > > > > > Thanks > > > > > > > > > On 20 Mag, 13:16, "marius d." wrote: > > > > > > > > As I understood you want to make an Ajax request and serve > back a > > > > > > > > Document Fragment. If so please also take a look at Jx stuff. > We > > > > > > > > discuss Jx classes in a fairly amount of details in the lift > > > book. > > > > > > > > > > Br's, > > > > > > > > Marius > > > > > > > > > > On May 20, 9:32 am, fatu wrote: > > > > > > > > > > > Timothy, > > > > > > > > > > > thanks for the links, I found them useful and I find your > blog > > > in > > > > > > > > > general very interesting. Came across scala-blogs.org and > it > > > looks > > > > > > > > > quite promising as well. > > > > > > > > > > > I knew "bind" already from the "Exploring Lift" book which > I > > > pull > > > > > from > > > > > > > > > git, build with Lyx and keep at hand regularly. In the > doctype > > > > > post, > > > > > > > > > though, I couldn't find a way to specify "no doctype" > which I > > > > > think > > > > > > > > > is necessary to serve a fragment; plus I couldn't find any > > > other > > > > > easy > > > > > > > > > "out-of-the-box" way to do it. Shouldn't this use case > (serving > > > > > > > > > fragments), which I think is quite common, be better / more > > > easily > > > > > > > > > supported by the framework? Can someone post an example of > how > > > to > > > > > do > > > > > > > > > it with raw response handling in the meanwhile? > > > > > > > > > > > Thanks anybody. > > > > > > > > > > > Fabio > > > > > > > > > > > On 26 Apr, 21:49, Timothy Perrett > > > > wrote: > > > > > > > > > > > > George, > > > > > > > > > > > > To tell lift what doctype you want to use see my blog > post > > > here: > > > > > > >http://is.gd/uJ4L > > > > > > > > > > > > Also, you'll want to read another one of my posts in > which I > > > > > discuss > > > > > > > > > > the bind(...) method and how you can stop
[Lift] Re: how to serve html fragments
...Another question for now :-) Does it work for views as well? Many thanks. Fabio On 21 Mag, 15:38, David Pollak wrote: > On Thu, May 21, 2009 at 12:27 AM, fatu wrote: > > > Right, didn't think about that alternative. > > > Thanks and best compliments to you and all the active Lift community > > for this superb Scala framework! I really think (and hope) it's going > > to have a big impact and a tremendous popularity rise in the next > > months, especially with more forthcoming books and articles spreading > > the word. > > We ask two things: build cool apps in Lift and be part of this community, > asking and answering questions. > > Thanks! > > > > > > > On 21 Mag, 06:42, David Pollak wrote: > > > On Wed, May 20, 2009 at 8:38 PM, fatu wrote: > > > > > Hi David, > > > > > yes it will do, thank you so much for such a lightning-fast > > > > development in reply! > > > > > I'm only thinking about a case that is probably much more of an > > > > exception than a rule, i.e. when the snippet dynamically decides if it > > > > needs to generate a full page or a fragment (which is not a very good > > > > design anyway IMHO), for example based on some info passed. But even > > > > in that case the snippet will know that and will be able to set > > > > S.skipDocType = true accordingly, so it should be perfectly fine. Plus > > > > it won't be difficult at all to make the processing diverge in the 2 > > > > cases by using URL rewrites, redirecting it to a different template / > > > > snippet depending on parameters or URL structure, which is probably a > > > > better design too. > > > > You could also pass a header flag from your AJAX call. If the header's > > set, > > > you don't do the boilerplate surround that'll include all the , > > > > > and tags. > > > > Anyway, enjoy and thanks for the use case. > > > > Party on. > > > > > Again many thanks everyone and David especially! > > > > > On May 20, 4:05 pm, David Pollak > > > > wrote: > > > > > I'm about to commit S.skipDocType = true | false. If you set it to > > true, > > > > > the will be omitted from the response page. This > > will > > > > allow > > > > > your AJAX fragements to pull parts of pages from the server. Note > > that > > > > > someplace in your snippets, you'll have to set S.skipDocType = true. > > > > > > Does this address your issue? > > > > > > On Wed, May 20, 2009 at 5:13 AM, fatu wrote: > > > > > > > Hi Marius, > > > > > > > as I understand them, Jx classes help in generating JS that can > > itself > > > > > > generate DOM at the client. Am I wrong? I'd really like to serve > > back > > > > > > an HTML fragment built by using the normal Lift template pipeline > > (so > > > > > > including surround & bind). Is that possible? > > > > > > > Thanks > > > > > > > On 20 Mag, 13:16, "marius d." wrote: > > > > > > > As I understood you want to make an Ajax request and serve back a > > > > > > > Document Fragment. If so please also take a look at Jx stuff. We > > > > > > > discuss Jx classes in a fairly amount of details in the lift > > book. > > > > > > > > Br's, > > > > > > > Marius > > > > > > > > On May 20, 9:32 am, fatu wrote: > > > > > > > > > Timothy, > > > > > > > > > thanks for the links, I found them useful and I find your blog > > in > > > > > > > > general very interesting. Came across scala-blogs.org and it > > looks > > > > > > > > quite promising as well. > > > > > > > > > I knew "bind" already from the "Exploring Lift" book which I > > pull > > > > from > > > > > > > > git, build with Lyx and keep at hand regularly. In the doctype > > > > post, > > > > > > > > though, I couldn't find a way to specify "no doctype" which I > > > > think > > > > > > > > is necessary to serve a fragment; plus I couldn't find any > > other > > > > easy > > > > > > > > "out-of-the-box" way to do it. Shouldn't this use case (serving > > > > > > > > fragments), which I think is quite common, be better / more > > easily > > > > > > > > supported by the framework? Can someone post an example of how > > to > > > > do > > > > > > > > it with raw response handling in the meanwhile? > > > > > > > > > Thanks anybody. > > > > > > > > > Fabio > > > > > > > > > On 26 Apr, 21:49, Timothy Perrett > > wrote: > > > > > > > > > > George, > > > > > > > > > > To tell lift what doctype you want to use see my blog post > > here: > > > > > >http://is.gd/uJ4L > > > > > > > > > > Also, you'll want to read another one of my posts in which I > > > > discuss > > > > > > > > > the bind(...) method and how you can stop putting markup into > > > > your > > > > > > > > > snippets:http://is.gd/sfyT > > > > > > > > > > Cheers, Tim > > > > > > > > > > On Apr 26, 1:02 pm, george wrote: > > > > > > > > > > > hello all, > > > > > > > > > > > hopefully someone can help me out here. > > > > > > > > > > > i am trying to port some simple ajax stuff over to lift > > from a > > > > > > rails > > > > > > > > > > app. basically it just loads anhtmlfragmentand puts it into > > the > >
[Lift] Re: Web Service : XmlResponse, xhtml and PrettyPrint
Hi Thimothy !
I totally agree with you, creating a NEW services infrastrucure is easier
with CXF of JAX-WS and this should be the prefered option.
This is a "special" case where I'm connecting an existing enterprise bus
(MOM) to SOAP clients. All you have to do is extracting the message content
; the message structure is already defined and documented by xml-schema ;
and forward it via JMS. Scala / Liftweb makes the system very simple /
secure / quick to develop / quick to deploy.
I tried first a CXF solution but had some stability (and then) scalability
issues due to the DOM XML "synchronize it yourself" paradigm. I don't know
if it's the best link to describe the problem, but you'll see the picture :
http://www.nabble.com/Making-Xerces-DOM-thread-safe-for-read-td14230584.html
The key issue is not making the soap message envelope but tune the
hand-crafted WSDL in order to solve the interoperability issues with .NET /
JAVA / PHP / (and other weird platforms)
2009/6/2 Timothy Perrett
>
> Jean-Luc, are you manually making these soap messages? Any reason your not
> using JAX-WS or CXF etc?
>
> Cheers, Tim
>
>
> On 02/06/2009 17:11, "Jean-Luc" wrote:
>
> Lifted, Scalads,
>
> I'm currently developing a Web Service which can generate xhtml content.
>
> 1. The xml output of the service has the following format :
> [...]
> http://www.w3.org/xhtml";
> xmlns:d="myUndisclosedURL">
> Here is my xhtml content with *
> *
> [...]
>
>
> 2. I generate the output with an XmlResponse( myXmlNodeAsParam )
>
> Is there a convenient method to pretty print the xhtml content so that
> empty xml node ("" or "") is rendered this way : =>
> ( and not => ) ?
>
>
> >
>
--
Jean-Luc Canela
jlcane...@gmail.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Web Service : XmlResponse, xhtml and PrettyPrint
Thank you David for the AltXML.toXML method ! Using AltXML.toXML(xml, false, true) produces a nice "the message " ;-) After verifying all my code : I had a test issue due to the fact that I parsed my xml byte stream back to a scala.xml.Node structure and used the Node.toString (which uses the default xml format ...) to trace it. I finally use an XmlResponse(xml) which set the headers and format correctly the xml stuff (checked with Fiddler2). 2009/6/2 David Pollak > Please try (this is on 1.1-SNAPSHOT... code I just checked in): > import net.liftweb.util._ > > AltXML.toXML(soapXML, false, true) > > Thanks, > > David > > -- Jean-Luc Canela jlcane...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Future of the Lift wiki
That's a great way of putting. In my opinion, here's how lift's current documentation fits into those three categories: the Guidebook: the Get Started Guided and the Exploring Lift book the Cookbook: blogs and various git repositories the Encyclopedia: the mailing list, scala docs, and of course the source code I think the lift wiki can quickly (6 months) become the repository for cookbook/recipe articles. Eventually (1.5+ years) it could even become the lift encyclopedia. Are these worthwhile goals? Please don't view these e-mail as just a bunch of noobs complaining about documentation. I'm just trying to align my expectation with the community's ideals. Thanks, Xavi On Mon, Jun 1, 2009 at 10:36 PM, g-man wrote: > > Having gone through Rails, the Google App Engine with Django, and > web2py over the last four years, I have seen it all as far as learning > new frameworks goes, and I have posted a few ideas on that subject > both here and on the book group. > > For those of us spoiled by the wealth of learning material on Rails, > and to a lesser degree Django and web2py, all I can say is: 'Lift is a > new framework, and a sophisticated one at that, which uses a new > language derived from a convoluted one, and is at a relatively early > stage of development, so therefore the designers are forging ahead to > completion of the foundation, and thus there are few who can devote > the time to creating the documentation we newcomers need.' > > My post on the book group defined the three classes of useful > documents to be the Guidebook, the Encyclopedia, and the Cookbook. My > role for the wiki is to hold Cookbook recipes which answer the most > common 'how to' questions we encounter when building a website. > > In my personal learning quest, I am extending the 'ToDo' app by adding > pieces of functionality, like many-to-many tagging, date manipulation, > deletion, an admin interface, etc. > > As I come across solutions or questions, I post those on the group in > order to help others and to get improvements and refinements from the > members. > > David is right... Lift and Scala together are taking web applications > to a whole new level of performance, so naturally it will take a > little time to make things happen. > > By the way, today my copies of David's and Martin's Scala books > arrived, and I urge all to purchase them yourselves! > > > On Jun 1, 3:35 pm, "Charles F. Munat" wrote: >> Hi, Xavi, >> >> One of my tasks is to come up with a good organization for the wiki and >> a site map, as well as a list of things we'd like to add to it. >> Unfortunately, with the coming Scala/Liftoff and OSB conferences, I've >> been swamped with other things. But I am working on it, albeit slowly. >> If you have any specific recommendations, please post them. >> >> Thanks! >> >> Chas. >> >> Xavi Ramirez wrote: >> > Hello, >> >> > I'm a bit confused about the future of the lift wiki. What's the end >> > goal? In an ideal world is it supposed to be the main repository of >> > lift knowledge, or just another documentation source? >> >> > I personally feel that having one repository of knowledge is much more >> > noob friendly. Currently new members have to navigate through started >> > guides, books, e-mail threads, scala docs, and personal blogs to find >> > relative information. Though the get started guided and book provide >> > a good introduction, it's hard to progress from novice to intermediate >> > with these fragmented resources. >> >> > Thanks, >> > Xavi > > > > --~--~-~--~~~---~--~~ 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: date management
The only issue I would mention is that there's currently an open ticket
because MappedDateTime won't save the time portion when you use Derby. I
haven't had time to triage this yet.
Derek
On Wed, Jun 3, 2009 at 3:01 AM, Timothy Perrett wrote:
>
> Greg,
>
> I dont really use toForm; have you explored "doing it manually"? It
> seems like that would be able to tell you if there is a problem with
> toForm on MappedDateTime.
>
> I use mapped date time quite a bit and have no problems at all
> persisting the dates :-)
>
> Cheers, Tim
>
> On Jun 3, 3:09 am, g-man wrote:
> > Are there no ideas for my problem?
> >
> > I have many more questions saved up, but would like to clear each out
> > before starting a new one.
> >
> > Thanks again!
> >
> > On May 31, 1:57 pm, g-man wrote:
> >
> >
> >
> > > As I proceed to enhance the ToDo example, I have added a new field to
> > > the ToDo.scala model:
> >
> > > object dueOn extends MappedDateTime(this) {
> > > final val dateFormat = DateFormat.getDateInstance
> > > (DateFormat.SHORT)
> > > override def asHtml = Text(dateFormat.format(is))}
> >
> > > Next, I added a binding in the TD.scala snippet within the add method
> > > of the TD class:
> >
> > > def doBind(form: NodeSeq) = {
> > > bind("todo", form, "desc" -> todo.desc.toForm,
> > > "priority" -> todo.priority.toForm,
> > > "dueOn" -> todo.dueOn.toForm,
> > > "submit" -> submit("create new Task",
> > > checkAndSave)}
> >
> > > Then, the todo.html template gets a bind point:
> >
> > >
> > > ...
> > >
> > >
> > >
> >
> > > When I check the database, the record does save, and all the other
> > > fields are OK, but the date itself is .
> >
> > > Somehow, it seems the text of the input field is not getting changed
> > > into a Date object for the database to handle, right?
> >
> > > When I look at the PocketChange app from the book, everything is done
> > > completely differently from the ToDo example (no use of _toForm, for
> > > instance).
> >
> > > I know dates and times are convoluted in Java, so what am I missing?
> >
> > > 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: Problem with Menu.builder & li_path/li_item
On 3 Jun 2009, marius d. wrote: > attribute with the same name but different prefixes should be ok as > long as the prefixes are bound to namespace URL's. But the problem here is that the attributes are in an inner template, which, I presume, will be read before the outer template (with the namespace URLs). Parsing the inner template fails as shown previously. On a conceptual level I don't think the li_path, li_item namespaces should be declared in the resulting page produced by lift. It is used solely by Lift for the rendering. But it seems these kind of prefixes in xml fragments are not supported by the Scala XML parser. /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 Menu.builder & li_path/li_item
attribute with the same name but different prefixes should be ok as
long as the prefixes are bound to namespace URL's.
Br's,
Marius
On Jun 3, 12:24 am, Derek Chen-Becker wrote:
> I think that this has been discussed on the list before. It's definitely an
> issue with having the same attribute name with different prefixes. I don't
> know that using proper namespace declarations will fix it. It seems that
> this is a bug in the Scala XML parser.
>
> Derek
>
> On Tue, Jun 2, 2009 at 2:55 PM, Jeppe Nejsum Madsen wrote:
>
>
>
> > On 2 Jun 2009, David Pollak wrote:
>
> > > This is an XML parsing error. Something in your XML is non-parsable.
> > > It's not Lift, but the underlying XML parsing library.
>
> > Yes, it would seem so. It looks like a bug/non-implemented feature that
> > the parser is unable to read two attributes with the same name but in
> > different name spaces. Not sure if this is because the fragment doesn't
> > contain any name space decls?
>
> > Unfortunately this renders the Menu.builder less useful since it is not
> > possible to assign CSS classes to both the path items and the selected
> > item (which, imho, is an obvious use case). Being a Lift newbie, I'm
> > wondering if there are other parts of Lift that is influenced by this.
>
> > Here's a very small test case that illustrates the problem:
>
> > Given this program:
>
> > import _root_.net.liftweb.util._
> > import _root_.java.io._
>
> > object ReadXML extends Application {
> > val xml= PCDataXmlParser(new FileInputStream("test.xml"))
> > }
>
> > This XML fragment fails to parse:
> >
> >
> >
>
> > But this parses ok (note the slight change in attribute names):
> >
> >
> >
>
> > Accidentally, I think there's a problem with the error reporting when
> > parsing fails. Looking at the code to scala.io.Source, the original
> > exception is a "double attribute" syntax error, but due to what I think
> > is a bug in Source.getLine, I always get errors reported as
> > java.lang.IllegalArgumentException: line 1 does not exist
>
> > Am I the only one seeing this?
>
> > /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: date management
Greg,
I dont really use toForm; have you explored "doing it manually"? It
seems like that would be able to tell you if there is a problem with
toForm on MappedDateTime.
I use mapped date time quite a bit and have no problems at all
persisting the dates :-)
Cheers, Tim
On Jun 3, 3:09 am, g-man wrote:
> Are there no ideas for my problem?
>
> I have many more questions saved up, but would like to clear each out
> before starting a new one.
>
> Thanks again!
>
> On May 31, 1:57 pm, g-man wrote:
>
>
>
> > As I proceed to enhance the ToDo example, I have added a new field to
> > the ToDo.scala model:
>
> > object dueOn extends MappedDateTime(this) {
> > final val dateFormat = DateFormat.getDateInstance
> > (DateFormat.SHORT)
> > override def asHtml = Text(dateFormat.format(is))}
>
> > Next, I added a binding in the TD.scala snippet within the add method
> > of the TD class:
>
> > def doBind(form: NodeSeq) = {
> > bind("todo", form, "desc" -> todo.desc.toForm,
> > "priority" -> todo.priority.toForm,
> > "dueOn" -> todo.dueOn.toForm,
> > "submit" -> submit("create new Task",
> > checkAndSave)}
>
> > Then, the todo.html template gets a bind point:
>
> >
> > ...
> >
> >
> >
>
> > When I check the database, the record does save, and all the other
> > fields are OK, but the date itself is .
>
> > Somehow, it seems the text of the input field is not getting changed
> > into a Date object for the database to handle, right?
>
> > When I look at the PocketChange app from the book, everything is done
> > completely differently from the ToDo example (no use of _toForm, for
> > instance).
>
> > I know dates and times are convoluted in Java, so what am I missing?
>
> > 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: Is something up with applying By to a MappedBoolean?
Is there an exception? If so could you post the entire trace? Cheers, Tim On Jun 3, 3:24 am, "E. Biggs" wrote: > When I try to apply By to a MappedBoolean like so: > > Table.findAll(By(Table.booleanField, false)); derby is unhappy and > bombs out on some sql with this kind of where clause: > > WHERE Table.booleanfield = ? > > Is this a bug or am I doing something wrong? I'm using 1.1-SNAPSHOT --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
