Does lift have any way to specify a unique constraint on a field, via schemify
(or validation)?
If not, how complex would it be to implement?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to
Hey Jevgeni,
Thats strange, I mailed you from my gmail account to your gmail, so
perhaps it got spammed or something?
Probably the best thing to do then would be for us to remove the
current .lic from the lift installer - perhaps i'll include the latest
JAR and then display a screen saying if
ps found a nice code framework to help with my initial setup here from
Ted Neward
http://www.ibm.com/developerworks/java/library/j-scala06029.html
Will use some of those classes/objects to get started (Ted's cool with
it as long as I show him how it ends up)
On Jul 1, 6:28 pm, Naftoli Gugenhem
Yeah Naftoli it was m2eclipse. May have been my failure to set
SCALA_HOME and the path properly.
I'll review it next time I do an eclipse setup (hopefully not for a
while now that netbeans is cooking with scala/lift)
Seriously, thanks much for all the feedback and help gents.
On Jul 1, 6:28 pm,
Corrected and pushed. Please do an update and give it a try.
Br's,
Marius
On Jul 2, 8:56 am, marius d. marius.dan...@gmail.com wrote:
On Jul 2, 12:40 am, Kris Nuttycombe kris.nuttyco...@gmail.com wrote:
To answer my own question, looking over the commit log 28595307 looks
extremely
On Wed, Jul 1, 2009 at 10:43 PM, g-man gregor...@gmail.com wrote:
I'm getting a Null Pointer: 'Trying to open an empty box', from S.attr
(todos).open_!
Don't use open_! It's dangerous.
That's why Boxes exist. They contain (or don't) something that may or may
not exist. If you use open_!
The open_! came right from the 'Getting Started' Todo tutorial I am
enhancing:
Listing 17: list method in TD class
def list(html: NodeSeq) = {
val id = S.attr(all_id).open_!
Nevertheless, the question remains: How can I filter the Todo items by
a Tag and render the list?
I guess I could
On Thu, Jul 2, 2009 at 6:55 AM, Timothy Perrett timo...@getintheloop.euwrote:
We really ought to get around to writing a “guides for boxes” - its easily
one of the most confusing concepts in lift (a magnitude less confusing
than when it was called Can[T])
I'm working on an app that allows users to enter their own form
templates, which are rendered to HTML forms and filled out. The results
are then captured and encoded for later rendering. So the user might
input something like:
pName: form:text name=name required=true/br/
Is this your first
But of course I know this :-)
Thinking back to when I first started scala a couple of years ago I just
couldn¹t understand why you wanted to put something in a box... Your article
does a good job of explaining, but I think we could do with some specific
documentation.
Cheers, Tim
On
We really ought to get around to writing a ³guides for boxes² - its easily
one of the most confusing concepts in lift (a magnitude less confusing
than when it was called Can[T])
Cheers, Tim
On 02/07/2009 14:46, David Pollak feeder.of.the.be...@gmail.com wrote:
On Wed, Jul 1, 2009 at
I actually had the same question last night. I didn't see the
valUnique on mapped string. However, it seems like a better way to do
this would be to change the Schemifier::ensureIndexes (line 260 in
Schemifier.scala) to do CREATE UNIQUE INDEX on request. Is there a
known reason why this is hard,
Marius, that fix appears to work fine, thank you!
Bloody nulls. :)
Kris
On Thu, Jul 2, 2009 at 7:17 AM, marius d.marius.dan...@gmail.com wrote:
Corrected and pushed. Please do an update and give it a try.
Br's,
Marius
On Jul 2, 8:56 am, marius d. marius.dan...@gmail.com wrote:
On Jul
Hi,
Having taken the first baby steps and gotten a Lift app running, it's
time to bring back some of the old engineering practices to make sure
things keep running when new features are added at a rapid pace :-)
I'm interested in how people are testing their Lift apps, both at the
unit test
Hi ph,
If you end up needing to use JUnit, you can import Assertions or
ShouldMatchers or MustMatchers from ScalaTest to get a nicer
scala-like assertion syntax inside JUnit tests. JUnit won't care it
was written in Scala or used ScalaTest assertions and will run it and
generate JUnit-compatible
I'm running Ubuntu 9.04.
$ mvn -v
Maven version: 2.0.9
Java version: 1.6.0_0
OS name: linux version: 2.6.28-13-generic arch: i386 Family: unix
I get the same errors using scala 2.7.4 and 2.7.5
-Cale
On Thu, Jul 2, 2009 at 12:24 AM, David
Pollakfeeder.of.the.be...@gmail.com wrote:
I've
On Thu, Jul 2, 2009 at 4:09 PM, Calen Pennington calen.penning...@gmail.com
wrote:
I'm running Ubuntu 9.04.
The only difference between your setup and mine is that I'm using Sun's 1.6
JDK rather than OpenJDK.
$ mvn -v
Maven version: 2.0.9
Java version: 1.6.0_0
OS name: linux
Hi Bill and ph,
Using specs matchers inside a JUnit test class is also possible using
the org.specs.SpecsMatchers trait.
However, I realize that both ScalaTest and specs suffer from the same
issue in that scenario.
When expectations are failing an exception is thrown but it is
interpreted by
18 matches
Mail list logo
