Marius wrote:
I'm fully aware of that ... I was just wondering if there were other
rationales behind this approach ...
or we can have
trait Foo[T : Foo[T]]) {
self: T =
def dog(t: T) = t.doSomething
def doSomething
}
Sorry for being clueless... but I'm not sure what the
Lift has a little know feature that makes this kind of thing super simple
and secure.
S.addHighLevelSessionDispatcher(name: String, dispatch:
LiftRules.DispatchPf) allows you to, on a session-by-session basis, specify
what to do with a given URL. This allows you to have a PayPal landing
If you want to tell them to enter a value, I'm sure that you could write (if
it doesn't already exist) a notEmpty validation that would say the right
thing and do something like:
val validations = notEmpty(You must provide an email address) _ ::
valRegex(...
Derek
On Tue, Sep 23, 2008 at 9:41
Tim, you rock :)
On Tue, Sep 23, 2008 at 10:29 AM, Tim Perrett [EMAIL PROTECTED] wrote:
Hey guys,
Ok, i've abstracted it all out into a class which you call a little
like this:
var paypal: PayPal = new PayPal(sandbox)
paypal.transactionToken = S.param(tx).openOr()
Thanks Derek :-) I have commited any code for ages, so its about time
I did!
My plan is this - once I get this roll out of the site im doing now
(which just needs PDT) done, I'll add the IPN functions to it. From
the docs, it looks pretty straight forward.
You can configure a whole bunch of
Hi, all,
I'm muddling about with forms, and am having problems getting a
function called from a form submission. Here's the relevant part of my
snippet code:
class Subscriptions {
def list(xhtml : NodeSeq) : NodeSeq = {
Orders.orderForDisplay.is.openOr(throw new
IllegalStateException(No
Tim,
I like the work, but I tend not to like mutable data structures (stuff
with properties that one sets.) I'd structure things such that the
PayPal object's setters return a new, immutable instance of the PayPal
object, so you're code would look like:
val pp: PayPal = new
Derek Chen-Becker wrote:
If you want to tell them to enter a value, I'm sure that you could
write (if it doesn't already exist) a notEmpty validation that would
say the right thing and do something like:
val validations = notEmpty(You must provide an email address) _ ::
valRegex(...
Charles F. Munat wrote:
Oliver Lambert wrote:
Do/should validations stop at the first error message on the field, at
least by default?
I much prefer that they do not. It really irritates me when I'm using an
online form and it tells me that something is invalid, then I fix it,
http://liftweb.net/index.php/RequirementsForForms
David Pollak wrote:
Charles F. Munat wrote:
Oliver Lambert wrote:
Do/should validations stop at the first error message on the field, at
least by default?
I much prefer that they do not. It really irritates me when I'm using
I'm still not clear on what causes this type of error:
XML Parsing Error: prefix not bound to a namespace
Location: http://localhost:8081/
Line Number 37, Column 10: limenu:bind
//li
^
Can anyone explain?
Thanks,
Chas.
If the error is occurring in the browser, it's because the menu:bind/
is not getting processed.
So, what's the page source (the stuff that's getting delivered to the
browser)?
Charles F. Munat wrote:
I'm still not clear on what causes this type of error:
XML Parsing Error: prefix not
Oliver wrote:
I like them to be validated as well, and to short circuit the remainder
of the field validation.
Feel free to set your validation up that way. Personally, I'd like my
validation code to be smart enough to note when two non-redundant
validation problems occur and to mention
Damn. Sometimes I'm a bit dense. I just realized that I created my own
Menu snippet, overriding the default one. A simple copy and paste fixed
things.
Just so I'm clear, the XML error is because the menu:bind / tag
appeared in the output, and the tag appeared in the output because the
group
14 matches
Mail list logo
