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
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,
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
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
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. W
+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 m
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
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
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 mi
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: heikoseeberg
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
> lif
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
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.Lift
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 t
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
>> gettin
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.
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
--~--~-~--~~--
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
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 l
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(Sourc
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
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
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 namespac
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, 200
...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 communit
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
;
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 def
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 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 expl
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
na
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 n
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
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:
>
>
33 matches
Mail list logo
