[Lift] Re: Validations
Thanks David, this did the trick.Out of curiosity: where in the docs
could I have found this information?
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/builtin/snippet/Msgs.html
doesn't seem to be updated ..
- suls
On Nov 25, 8:01 pm, David Pollak
wrote:
> On Wed, Nov 25, 2009 at 11:52 AM, suls wrote:
> > Hi guys,
>
> > It seems that I don't completely understand how validations work.. I
> > am having a model with the following property:
>
> > object size extends MappedInt(this) {
> > override def validations = validPosition _ :: super.validations
>
> > def validPosition(in: Int): List[FieldError] =
> > if (-100 until 101 contains in) Nil
> > else List(FieldError(this, Position size must not be greater
> > than +/- 100))
> > }
>
> > And in the snippet I do the following:
>
> > pos.validate match {
> > case Nil => pos.save; S.notice("Position change "
> > + pos.size + " for "
> > + pos.dateOf.asHtml + " successful.")
>
> > case xs => S.error(xs); Log.error("." + xs)
> > }
>
> > Now something I cannot explain to myself happens: If the validation
> > fails, the error gets logged on the console but not displayed in the
> > browser:
>
> > ERROR - .List(Full(position_size) : Position size must not be
> > greater than +/- 100)
>
> > Am I getting something wrong with how validations work?
>
> In your default template (templates-hidden/default.html) change /> to
>
> A few months back, we changed MappedFields to having a field identifier.
> The default Msgs does not render error messages on fields with a field
> identifier set.
>
>
>
>
>
> > Cheers, suls
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@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, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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: Validations, Server side controls etc
David Pollak wrote: > I think the stuff that marius has done is interesting, but it is at > odds with the long promised record/field stuff. > > This morning, I figured out how to ask the right questions in order to > manage the record/field project. If I can get one or two volunteers, I > think we can get the project done in a few weeks. > > Volunteers? > I would love to get involved in this, as it's one of my recurring pet projects. Unfortunately, like most of us, I don't have a lot of spare time and my days are pretty much spoken for. Maybe one way to start would be for me to spew some of the design ideas I've had in this department over the past year or so, and see if they resonate? -0xe1a --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Excellent... How much work do you think this will require ? ... if it helps I could probably spend some time during weekends working on this stuff ( anyways 95% of my lift work is spent during weekends :) ...) ... if you need my limited help please let me know. Where is current work located ...wip-dpp-record, wip-record2-dpp branches? Br's, Marius On Sep 22, 1:17 am, David Pollak <[EMAIL PROTECTED]> wrote: > Tim Perrett wrote: > >> IMHO the form validation framework should work independently from any > >> persistence related stuff ... > > > +1 > > Right. The Record/Field stuff is not about persistence... it's about > richer representation of data than String/Int/Long/Date. It's about the > "stuff" that surrounds the near-bit-level representation of the data. > Seehttp://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w... > Validation is part of the over-all mix. > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Tim Perrett wrote: >> IMHO the form validation framework should work independently from any >> persistence related stuff ... >> > > +1 > Right. The Record/Field stuff is not about persistence... it's about richer representation of data than String/Int/Long/Date. It's about the "stuff" that surrounds the near-bit-level representation of the data. See http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html Validation is part of the over-all mix. > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
> IMHO the form validation framework should work independently from any > persistence related stuff ... +1 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
IMHO the form validation framework should work independently from any persistence related stuff ... this is why my proposal has nothing to do with any persistence layer. Could/should be integrated though. But I admit that I haven't looked at all at your Record/Field stuff. Unfortunately as much as I'd like to volunteer, the next couple of weeks will be pretty rough at work and my spare time will be very limited :( ... but of course I'm curious what you're thinking about with regads of form validations :D Br's, Marius On Sep 21, 10:19 pm, David Pollak <[EMAIL PROTECTED]> wrote: > Folks > > I think the stuff that marius has done is interesting, but it is at > odds with the long promised record/field stuff. > > This morning, I figured out how to ask the right questions in order to > manage the record/field project. If I can get one or two volunteers, I > think we can get the project done in a few weeks. > > Volunteers? > > Thanks > > David > > On Sep 21, 2008, at 12:06 PM, Marius <[EMAIL PROTECTED]> wrote: > > > > > Cool ... have fun ... and I'll keep an eye on it, and let me know if > > you need anything. Of course in the mean time further comments from > > other people are more then welcomed. > > > Br's, > > Marius > > > On Sep 21, 10:03 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > >> Sorry I should have been clearer... Of course, I wouldnt work it > >> straight into master :-) > > >> I'll make a branch or fork then we'll go from there > > >> Cheers Marius, this is great work > > >> Tim > > >> On Sep 21, 7:57 pm, Marius <[EMAIL PROTECTED]> wrote: > > >>> On Sep 21, 9:48 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > That would be sweet ! ... anything particular in mind? ... > > things like > > email, phone number validation etc? > > Totally - nothing crazy to begin with, perhaps with some way of > passing a regex or whatever to ward off boiler plate code thats > repeated by lift users. Conceptually, I think the ones given > byhttp://validatable.rubyforge.org/arequitenice. Like I said, > nothing > crazy, but very functional... e.g. validates_format_of > > > Yes of course ... implement other form fields ALL form input > > types + > > what you very well suggested : common validations for say most > > frequently used validations. Shoul also work for Ajax/json forms > > since > > notices work just fine in such situations just a bit more > > noodling, > > testing etc. > > Exactly - this is very nice and something that IMO, lift has really > been missing. Do you mind if I take your example and extend it and > stick it into lift core? Actually thats a good point where > within > the lift code base would this best sit? Probably net.liftweb.util > maybe? > > >>> Could you create a different git branch ? ... I'd rather wait > >>> until it > >>> is very close to completion (from the framework perspective at > >>> least) > >>> and then commit it into master branch. I welcome you to continue > >>> with > >>> implementation in this branch and I will provide feedback (with > >>> either > >>> comments and code). When we're done with it we present to the > >>> community an example application and then put it in the master > >>> branch > >>> after we get the lift committers consensus and hopefully other > >>> people's fedback. > > >>> I think net.liftweb.http.form package sounds reasonable for this > >>> framework. > > Cheers > > Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Hey David, Thats interesting you say that - can you elaborate what functionality splitting the mapper stuff will have? Its been discussed in broad terms on the list, but im not sure its ever been outlined what the end result will actually leave us with. My understanding was that it would provided us with a method to generically validate objects and apply validation constraints in a generic way? IMO, I think the server-side form construct provides a nice way of grouping validation logic Cheers Tim On 21 Sep 2008, at 20:19, David Pollak wrote: > > Folks > > I think the stuff that marius has done is interesting, but it is at > odds with the long promised record/field stuff. > > This morning, I figured out how to ask the right questions in order to > manage the record/field project. If I can get one or two volunteers, I > think we can get the project done in a few weeks. > > Volunteers? > > Thanks > > David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Folks I think the stuff that marius has done is interesting, but it is at odds with the long promised record/field stuff. This morning, I figured out how to ask the right questions in order to manage the record/field project. If I can get one or two volunteers, I think we can get the project done in a few weeks. Volunteers? Thanks David On Sep 21, 2008, at 12:06 PM, Marius <[EMAIL PROTECTED]> wrote: > > Cool ... have fun ... and I'll keep an eye on it, and let me know if > you need anything. Of course in the mean time further comments from > other people are more then welcomed. > > Br's, > Marius > > On Sep 21, 10:03 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: >> Sorry I should have been clearer... Of course, I wouldnt work it >> straight into master :-) >> >> I'll make a branch or fork then we'll go from there >> >> Cheers Marius, this is great work >> >> Tim >> >> On Sep 21, 7:57 pm, Marius <[EMAIL PROTECTED]> wrote: >> >>> On Sep 21, 9:48 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: >> > That would be sweet ! ... anything particular in mind? ... > things like > email, phone number validation etc? >> Totally - nothing crazy to begin with, perhaps with some way of passing a regex or whatever to ward off boiler plate code thats repeated by lift users. Conceptually, I think the ones given byhttp://validatable.rubyforge.org/arequitenice. Like I said, nothing crazy, but very functional... e.g. validates_format_of >> > Yes of course ... implement other form fields ALL form input > types + > what you very well suggested : common validations for say most > frequently used validations. Shoul also work for Ajax/json forms > since > notices work just fine in such situations just a bit more > noodling, > testing etc. >> Exactly - this is very nice and something that IMO, lift has really been missing. Do you mind if I take your example and extend it and stick it into lift core? Actually thats a good point where within the lift code base would this best sit? Probably net.liftweb.util maybe? >> >>> Could you create a different git branch ? ... I'd rather wait >>> until it >>> is very close to completion (from the framework perspective at >>> least) >>> and then commit it into master branch. I welcome you to continue >>> with >>> implementation in this branch and I will provide feedback (with >>> either >>> comments and code). When we're done with it we present to the >>> community an example application and then put it in the master >>> branch >>> after we get the lift committers consensus and hopefully other >>> people's fedback. >> >>> I think net.liftweb.http.form package sounds reasonable for this >>> framework. >> Cheers >> Tim > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Cool ... have fun ... and I'll keep an eye on it, and let me know if you need anything. Of course in the mean time further comments from other people are more then welcomed. Br's, Marius On Sep 21, 10:03 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > Sorry I should have been clearer... Of course, I wouldnt work it > straight into master :-) > > I'll make a branch or fork then we'll go from there > > Cheers Marius, this is great work > > Tim > > On Sep 21, 7:57 pm, Marius <[EMAIL PROTECTED]> wrote: > > > On Sep 21, 9:48 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > > > That would be sweet ! ... anything particular in mind? ... things like > > > > email, phone number validation etc? > > > > Totally - nothing crazy to begin with, perhaps with some way of > > > passing a regex or whatever to ward off boiler plate code thats > > > repeated by lift users. Conceptually, I think the ones given > > > byhttp://validatable.rubyforge.org/arequitenice. Like I said, nothing > > > crazy, but very functional... e.g. validates_format_of > > > > > Yes of course ... implement other form fields ALL form input types + > > > > what you very well suggested : common validations for say most > > > > frequently used validations. Shoul also work for Ajax/json forms since > > > > notices work just fine in such situations just a bit more noodling, > > > > testing etc. > > > > Exactly - this is very nice and something that IMO, lift has really > > > been missing. Do you mind if I take your example and extend it and > > > stick it into lift core? Actually thats a good point where within > > > the lift code base would this best sit? Probably net.liftweb.util > > > maybe? > > > Could you create a different git branch ? ... I'd rather wait until it > > is very close to completion (from the framework perspective at least) > > and then commit it into master branch. I welcome you to continue with > > implementation in this branch and I will provide feedback (with either > > comments and code). When we're done with it we present to the > > community an example application and then put it in the master branch > > after we get the lift committers consensus and hopefully other > > people's fedback. > > > I think net.liftweb.http.form package sounds reasonable for this > > framework. > > > > Cheers > > > > Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Sorry I should have been clearer... Of course, I wouldnt work it straight into master :-) I'll make a branch or fork then we'll go from there Cheers Marius, this is great work Tim On Sep 21, 7:57 pm, Marius <[EMAIL PROTECTED]> wrote: > On Sep 21, 9:48 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > > > > > > That would be sweet ! ... anything particular in mind? ... things like > > > email, phone number validation etc? > > > Totally - nothing crazy to begin with, perhaps with some way of > > passing a regex or whatever to ward off boiler plate code thats > > repeated by lift users. Conceptually, I think the ones given > > byhttp://validatable.rubyforge.org/arequite nice. Like I said, nothing > > crazy, but very functional... e.g. validates_format_of > > > > Yes of course ... implement other form fields ALL form input types + > > > what you very well suggested : common validations for say most > > > frequently used validations. Shoul also work for Ajax/json forms since > > > notices work just fine in such situations just a bit more noodling, > > > testing etc. > > > Exactly - this is very nice and something that IMO, lift has really > > been missing. Do you mind if I take your example and extend it and > > stick it into lift core? Actually thats a good point where within > > the lift code base would this best sit? Probably net.liftweb.util > > maybe? > > Could you create a different git branch ? ... I'd rather wait until it > is very close to completion (from the framework perspective at least) > and then commit it into master branch. I welcome you to continue with > implementation in this branch and I will provide feedback (with either > comments and code). When we're done with it we present to the > community an example application and then put it in the master branch > after we get the lift committers consensus and hopefully other > people's fedback. > > I think net.liftweb.http.form package sounds reasonable for this > framework. > > > > > Cheers > > > Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
On Sep 21, 9:48 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > > That would be sweet ! ... anything particular in mind? ... things like > > email, phone number validation etc? > > Totally - nothing crazy to begin with, perhaps with some way of > passing a regex or whatever to ward off boiler plate code thats > repeated by lift users. Conceptually, I think the ones given > byhttp://validatable.rubyforge.org/are quite nice. Like I said, nothing > crazy, but very functional... e.g. validates_format_of > > > Yes of course ... implement other form fields ALL form input types + > > what you very well suggested : common validations for say most > > frequently used validations. Shoul also work for Ajax/json forms since > > notices work just fine in such situations just a bit more noodling, > > testing etc. > > Exactly - this is very nice and something that IMO, lift has really > been missing. Do you mind if I take your example and extend it and > stick it into lift core? Actually thats a good point where within > the lift code base would this best sit? Probably net.liftweb.util > maybe? Could you create a different git branch ? ... I'd rather wait until it is very close to completion (from the framework perspective at least) and then commit it into master branch. I welcome you to continue with implementation in this branch and I will provide feedback (with either comments and code). When we're done with it we present to the community an example application and then put it in the master branch after we get the lift committers consensus and hopefully other people's fedback. I think net.liftweb.http.form package sounds reasonable for this framework. > > Cheers > > Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
> That would be sweet ! ... anything particular in mind? ... things like > email, phone number validation etc? Totally - nothing crazy to begin with, perhaps with some way of passing a regex or whatever to ward off boiler plate code thats repeated by lift users. Conceptually, I think the ones given by http://validatable.rubyforge.org/ are quite nice. Like I said, nothing crazy, but very functional... e.g. validates_format_of > Yes of course ... implement other form fields ALL form input types + > what you very well suggested : common validations for say most > frequently used validations. Shoul also work for Ajax/json forms since > notices work just fine in such situations just a bit more noodling, > testing etc. Exactly - this is very nice and something that IMO, lift has really been missing. Do you mind if I take your example and extend it and stick it into lift core? Actually thats a good point where within the lift code base would this best sit? Probably net.liftweb.util maybe? Cheers Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
I thought I replied :) On Sep 21, 9:37 pm, Tim Perrett <[EMAIL PROTECTED]> wrote: > Great minds Marius - you sent your mail at 19:29, and mine at 19:30! > What do you think on my comments above? > > Cheers, Tim > > On 21 Sep 2008, at 19:29, Marius wrote: > > > > > Guys please try running the application above, take a look on the code > > and have feedback. Is it a "sufficient" paradigm (from server side > > validation perspective), is it a simple enough approach from your > > perspective? ... of course it is just a draft. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Great minds Marius - you sent your mail at 19:29, and mine at 19:30! What do you think on my comments above? Cheers, Tim On 21 Sep 2008, at 19:29, Marius wrote: > > Guys please try running the application above, take a look on the code > and have feedback. Is it a "sufficient" paradigm (from server side > validation perspective), is it a simple enough approach from your > perspective? ... of course it is just a draft. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Kind of funny ... we were writing almost in parallel :)
On Sep 21, 9:30 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
> WOW! Marius this is so fricking sweet. well done, awesome stuff
> indeed!
>
> Functionally, I think this would serve as an excellent place to start
> for providing validation in lift right?
Well it's just an idea that I think it would worth to explore.
Perhaps by providing
> convenience methods for common validations rather than needing to code
> it explicitally.
That would be sweet ! ... anything particular in mind? ... things like
email, phone number validation etc?
>
> What other stuff do you think its missing? I have only had a quick
> play with your same, but it looks to be really great :)
Yes of course ... implement other form fields ALL form input types +
what you very well suggested : common validations for say most
frequently used validations. Shoul also work for Ajax/json forms since
notices work just fine in such situations just a bit more noodling,
testing etc.
>
> Cheers
>
> Tim
>
> On Sep 21, 11:58 am, Marius <[EMAIL PROTECTED]> wrote:
>
> > Ok ...
>
> > I just uploaded an example
> > applicationhttp://groups.google.com/group/liftweb/web/liftform.tar.gz
>
> > At the first glance it may look complicated but it's really not. For
> > instance we have this snippet class
>
> > class Form {
> > object who extends RequestVar("0")
> > object sec extends RequestVar("-1")
>
> > val form: LiftForm = new LiftForm(TextField({(v: Int) =>
> > println("who is " + v); who(v toString)}, FieldType.INT)
> > ({case v if v > 10 => },
> > ValidationMessage("who_msg", {
> > case v => who(v);
> > Text("* The value must be a number greater then 10.")
> > })),
>
> > TextField({(v: Float) =>
> > println("sec is " + v); sec(v toString)}, FieldType.FLOAT)
> > ({case v if v <= 0.7f => },
> > ValidationMessage("sec_msg", {
> > case v => sec(v);
> > Text("* The value must be a number smaller then 0.7.")
> > }))
> > )
>
> > def validate(html: Group) : NodeSeq = {
>
> > bind("hello", html,
> > "whoField" -> form.getFields(0).toHtml(who) % ("size" -> "30")
> > % ("id" -> "whoField"),
> > "secField" -> form.getFields(1).toHtml(sec) % ("size" ->
> > "30") % ("id" -> "secField"),
> > "submit" -> submit("Submit", {println("IN SUBMIT");
> > S.notice("FORM IS VALID " + form.passedValidation); })
> > )
>
> > }
>
> > We have a LiftForm reference that contains two FormField-s in
> > particular case 2 TextField's
>
> > TextField({(v: Int) => println("who is " + v); who(v toString)},
> > FieldType.INT)
> > ({case v if v > 10 => },
> > ValidationMessage("who_msg", {
> > case v => who(v);
> > Text("* The value must be a number greater then 10.")
> > }))
>
> > TextField here is the companion module of the TextField class. It
> > takes:
>
> > 1. The function that is called for this field when the form is
> > submitted and validation passed: {(v: Int) => println("who is " + v);
> > who(v toString)}
> > 2. The field type. This FieldType is an enum that knows how to convert
> > from the request string to a particular type.
> > 3. A tuple holding:
> >3.1 The actual validation predicate expressed as a PartialFunction
> >3.2. The ValidationMessage which holds the id of the notice element
> > (basically where we want the error validation message to appear) and a
> > function that receives the original request string and returns a Node
> > which impersonates the actual error message
>
> > Thoughts are more then welcomed !
>
> > P.S.
> > Currently for exemplification only TextField is implemented but we can
> > easily extend it to all possible form fields.
>
> > Br's,
> > Marius
>
> > On Sep 21, 1:28 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > > Actually I just Implemented a small lift app that does typesafe form
> > > validation on server side.
>
> > > I'll attach it in a bit ... it's just an idea
>
> > > Br's,
> > > Marius
>
> > > On Sep 21, 1:08 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > > Sounds good Marius - project wise though we need to address this IMHO;
> > > > as we pick up more users of lift people will want this functionality
> > > > for sure.
>
> > > > I guess we really need to decide at what level we want to apply
> > > > validation - Im not sure that having it tightly coupled to the
> > > > persistence tier (a la rails) is a great idea. Just had a quick look
> > > > at OVal i think a generic approach like that would be good as then
> > > > your just dealing with a single
[Lift] Re: Validations, Server side controls etc
WOW! Marius this is so fricking sweet. well done, awesome stuff
indeed!
Functionally, I think this would serve as an excellent place to start
for providing validation in lift right? Perhaps by providing
convenience methods for common validations rather than needing to code
it explicitally.
What other stuff do you think its missing? I have only had a quick
play with your same, but it looks to be really great :)
Cheers
Tim
On Sep 21, 11:58 am, Marius <[EMAIL PROTECTED]> wrote:
> Ok ...
>
> I just uploaded an example
> applicationhttp://groups.google.com/group/liftweb/web/liftform.tar.gz
>
> At the first glance it may look complicated but it's really not. For
> instance we have this snippet class
>
> class Form {
> object who extends RequestVar("0")
> object sec extends RequestVar("-1")
>
> val form: LiftForm = new LiftForm(TextField({(v: Int) =>
> println("who is " + v); who(v toString)}, FieldType.INT)
> ({case v if v > 10 => },
> ValidationMessage("who_msg", {
> case v => who(v);
> Text("* The value must be a number greater then 10.")
> })),
>
> TextField({(v: Float) =>
> println("sec is " + v); sec(v toString)}, FieldType.FLOAT)
> ({case v if v <= 0.7f => },
> ValidationMessage("sec_msg", {
> case v => sec(v);
> Text("* The value must be a number smaller then 0.7.")
> }))
> )
>
> def validate(html: Group) : NodeSeq = {
>
> bind("hello", html,
> "whoField" -> form.getFields(0).toHtml(who) % ("size" -> "30")
> % ("id" -> "whoField"),
> "secField" -> form.getFields(1).toHtml(sec) % ("size" ->
> "30") % ("id" -> "secField"),
> "submit" -> submit("Submit", {println("IN SUBMIT");
> S.notice("FORM IS VALID " + form.passedValidation); })
> )
>
> }
>
> We have a LiftForm reference that contains two FormField-s in
> particular case 2 TextField's
>
> TextField({(v: Int) => println("who is " + v); who(v toString)},
> FieldType.INT)
> ({case v if v > 10 => },
> ValidationMessage("who_msg", {
> case v => who(v);
> Text("* The value must be a number greater then 10.")
> }))
>
> TextField here is the companion module of the TextField class. It
> takes:
>
> 1. The function that is called for this field when the form is
> submitted and validation passed: {(v: Int) => println("who is " + v);
> who(v toString)}
> 2. The field type. This FieldType is an enum that knows how to convert
> from the request string to a particular type.
> 3. A tuple holding:
> 3.1 The actual validation predicate expressed as a PartialFunction
> 3.2. The ValidationMessage which holds the id of the notice element
> (basically where we want the error validation message to appear) and a
> function that receives the original request string and returns a Node
> which impersonates the actual error message
>
> Thoughts are more then welcomed !
>
> P.S.
> Currently for exemplification only TextField is implemented but we can
> easily extend it to all possible form fields.
>
> Br's,
> Marius
>
> On Sep 21, 1:28 pm, Marius <[EMAIL PROTECTED]> wrote:
>
> > Actually I just Implemented a small lift app that does typesafe form
> > validation on server side.
>
> > I'll attach it in a bit ... it's just an idea
>
> > Br's,
> > Marius
>
> > On Sep 21, 1:08 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > Sounds good Marius - project wise though we need to address this IMHO;
> > > as we pick up more users of lift people will want this functionality
> > > for sure.
>
> > > I guess we really need to decide at what level we want to apply
> > > validation - Im not sure that having it tightly coupled to the
> > > persistence tier (a la rails) is a great idea. Just had a quick look
> > > at OVal i think a generic approach like that would be good as then
> > > your just dealing with a single methodology to spec validation
> > > criterion on any object.
>
> > > Also, conceptually, a server side representation of a form seems to be
> > > a different notion to the bind() style we have with snippets. Im not
> > > sure how we could get it to work in a clean way - would it be an
> > > abstraction on top of bind() ?
>
> > > Anyway, great to noodle this as its certainly very important going
> > > forward
>
> > > Cheers
>
> > > Tim
>
> > > On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
>
> > > > Right ...
>
> > > > IMHO the key things that we need to have :
>
> > > > 1. Typesafe validation (predicates as partial functions sounds very
> > > > good to me ;) ... )
> > > > 2. Scala objects abstracting forms ... maybe in a way you similar wi
[Lift] Re: Validations, Server side controls etc
Guys please try running the application above, take a look on the code
and have feedback. Is it a "sufficient" paradigm (from server side
validation perspective), is it a simple enough approach from your
perspective? ... of course it is just a draft.
Br's,
Marius
On Sep 21, 1:46 pm, Oliver Lambert <[EMAIL PROTECTED]> wrote:
> On 21/09/2008, at 8:08 PM, Tim Perrett wrote:
>
>
>
> > Sounds good Marius - project wise though we need to address this IMHO;
> > as we pick up more users of lift people will want this functionality
> > for sure.
>
> Yes, or be forced to roll their own validation
>
>
>
> > I guess we really need to decide at what level we want to apply
> > validation - Im not sure that having it tightly coupled to the
> > persistence tier (a la rails) is a great idea. Just had a quick look
> > at OVal i think a generic approach like that would be good as then
> > your just dealing with a single methodology to spec validation
> > criterion on any object.
>
> It would be nice to be able to mixin the same major validations (e.g
> notNull, Range)
> automatically to the client via prewriten javascript, as well as the
> "bind" and
> the persistence layer
>
> > Also, conceptually, a server side representation of a form seems to be
> > a different notion to the bind() style we have with snippets. Im not
> > sure how we could get it to work in a clean way - would it be an
> > abstraction on top of bind() ?
>
> I like the idea of a server side representation of a form with
> validation.
> I think the "bind style" may change when a compiler plugin gets rid
> of its redundancy
>
> > Anyway, great to noodle this as its certainly very important going
> > forward
>
> > Cheers
>
> > Tim
>
> > On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
> >> Right ...
>
> >> IMHO the key things that we need to have :
>
> >> 1. Typesafe validation (predicates as partial functions sounds very
> >> good to me ;) ... )
> >> 2. Scala objects abstracting forms ... maybe in a way you similar
> >> with
> >> what presented here (also this has been mentioned in other posts)
> >> 3. An easy way of obtaining markup from "Form" classes
> >> 4. An easy way of processing the form (this is the easiest part as we
> >> have all we need here)
>
> >> I'll also do some noodling on this and let's come with concrete
> >> proposals.
>
> >> P.S.
> >> Some ideas are currently
> >> here:http://liftweb.net/index.php/Unified_Validation
>
> >> Br's,
> >> Marius
>
> >> On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> >>> Guys,
>
> >>> Myself and Marius have just been talking over IM about generic
> >>> ways to
> >>> build validation into lift.
>
> >>> IMHO, right now it seems that there is not any cohesive way to
> >>> validate user input (without a bunch of manual coding). One of the
> >>> things we talked about is server-side form representation... I
> >>> wonder
> >>> if there is a way to abstract form building so that it was somehow
> >>> generic and let you specify field content & type and also the
> >>> validation that needs to be applied to that control.
>
> >>> This just pure spitballing, but what about something like:
>
> >>> class MyDemoFrom extends LiftForm {
> >>> def someInput = TextInput(SHtml.text(), Validatons({
> >>> // whatever validation here
> >>> }))
>
> >>> }
>
> >>> Or whatever - I just want to try and talk through the idea rather
> >>> than
> >>> propose code at this stage. Even when we extract the validation
> >>> stuff
> >>> from mapper, we'll still need some way of implementing those
> >>> validation constraints on controls wont we?
>
> >>> Interesting in what people think
>
> >>> Cheers
>
> >>> Tim
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
On 21/09/2008, at 8:08 PM, Tim Perrett wrote:
>
> Sounds good Marius - project wise though we need to address this IMHO;
> as we pick up more users of lift people will want this functionality
> for sure.
Yes, or be forced to roll their own validation
>
> I guess we really need to decide at what level we want to apply
> validation - Im not sure that having it tightly coupled to the
> persistence tier (a la rails) is a great idea. Just had a quick look
> at OVal i think a generic approach like that would be good as then
> your just dealing with a single methodology to spec validation
> criterion on any object.
It would be nice to be able to mixin the same major validations (e.g
notNull, Range)
automatically to the client via prewriten javascript, as well as the
"bind" and
the persistence layer
> Also, conceptually, a server side representation of a form seems to be
> a different notion to the bind() style we have with snippets. Im not
> sure how we could get it to work in a clean way - would it be an
> abstraction on top of bind() ?
I like the idea of a server side representation of a form with
validation.
I think the "bind style" may change when a compiler plugin gets rid
of its redundancy
> Anyway, great to noodle this as its certainly very important going
> forward
>
> Cheers
>
> Tim
>
>
> On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
>> Right ...
>>
>> IMHO the key things that we need to have :
>>
>> 1. Typesafe validation (predicates as partial functions sounds very
>> good to me ;) ... )
>> 2. Scala objects abstracting forms ... maybe in a way you similar
>> with
>> what presented here (also this has been mentioned in other posts)
>> 3. An easy way of obtaining markup from "Form" classes
>> 4. An easy way of processing the form (this is the easiest part as we
>> have all we need here)
>>
>> I'll also do some noodling on this and let's come with concrete
>> proposals.
>>
>> P.S.
>> Some ideas are currently here:http://liftweb.net/index.php/Unified_Validation
>>
>> Br's,
>> Marius
>>
>> On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>>
>>> Guys,
>>
>>> Myself and Marius have just been talking over IM about generic
>>> ways to
>>> build validation into lift.
>>
>>> IMHO, right now it seems that there is not any cohesive way to
>>> validate user input (without a bunch of manual coding). One of the
>>> things we talked about is server-side form representation... I
>>> wonder
>>> if there is a way to abstract form building so that it was somehow
>>> generic and let you specify field content & type and also the
>>> validation that needs to be applied to that control.
>>
>>> This just pure spitballing, but what about something like:
>>
>>> class MyDemoFrom extends LiftForm {
>>> def someInput = TextInput(SHtml.text(), Validatons({
>>> // whatever validation here
>>> }))
>>
>>> }
>>
>>> Or whatever - I just want to try and talk through the idea rather
>>> than
>>> propose code at this stage. Even when we extract the validation
>>> stuff
>>> from mapper, we'll still need some way of implementing those
>>> validation constraints on controls wont we?
>>
>>> Interesting in what people think
>>
>>> Cheers
>>
>>> Tim
> >
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Ok ...
I just uploaded an example application
http://groups.google.com/group/liftweb/web/liftform.tar.gz
At the first glance it may look complicated but it's really not. For
instance we have this snippet class
class Form {
object who extends RequestVar("0")
object sec extends RequestVar("-1")
val form: LiftForm = new LiftForm(TextField({(v: Int) =>
println("who is " + v); who(v toString)}, FieldType.INT)
({case v if v > 10 => },
ValidationMessage("who_msg", {
case v => who(v);
Text("* The value must be a number greater then 10.")
})),
TextField({(v: Float) =>
println("sec is " + v); sec(v toString)}, FieldType.FLOAT)
({case v if v <= 0.7f => },
ValidationMessage("sec_msg", {
case v => sec(v);
Text("* The value must be a number smaller then 0.7.")
}))
)
def validate(html: Group) : NodeSeq = {
bind("hello", html,
"whoField" -> form.getFields(0).toHtml(who) % ("size" -> "30")
% ("id" -> "whoField"),
"secField" -> form.getFields(1).toHtml(sec) % ("size" ->
"30") % ("id" -> "secField"),
"submit" -> submit("Submit", {println("IN SUBMIT");
S.notice("FORM IS VALID " + form.passedValidation); })
)
}
We have a LiftForm reference that contains two FormField-s in
particular case 2 TextField's
TextField({(v: Int) => println("who is " + v); who(v toString)},
FieldType.INT)
({case v if v > 10 => },
ValidationMessage("who_msg", {
case v => who(v);
Text("* The value must be a number greater then 10.")
}))
TextField here is the companion module of the TextField class. It
takes:
1. The function that is called for this field when the form is
submitted and validation passed: {(v: Int) => println("who is " + v);
who(v toString)}
2. The field type. This FieldType is an enum that knows how to convert
from the request string to a particular type.
3. A tuple holding:
3.1 The actual validation predicate expressed as a PartialFunction
3.2. The ValidationMessage which holds the id of the notice element
(basically where we want the error validation message to appear) and a
function that receives the original request string and returns a Node
which impersonates the actual error message
Thoughts are more then welcomed !
P.S.
Currently for exemplification only TextField is implemented but we can
easily extend it to all possible form fields.
Br's,
Marius
On Sep 21, 1:28 pm, Marius <[EMAIL PROTECTED]> wrote:
> Actually I just Implemented a small lift app that does typesafe form
> validation on server side.
>
> I'll attach it in a bit ... it's just an idea
>
> Br's,
> Marius
>
> On Sep 21, 1:08 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > Sounds good Marius - project wise though we need to address this IMHO;
> > as we pick up more users of lift people will want this functionality
> > for sure.
>
> > I guess we really need to decide at what level we want to apply
> > validation - Im not sure that having it tightly coupled to the
> > persistence tier (a la rails) is a great idea. Just had a quick look
> > at OVal i think a generic approach like that would be good as then
> > your just dealing with a single methodology to spec validation
> > criterion on any object.
>
> > Also, conceptually, a server side representation of a form seems to be
> > a different notion to the bind() style we have with snippets. Im not
> > sure how we could get it to work in a clean way - would it be an
> > abstraction on top of bind() ?
>
> > Anyway, great to noodle this as its certainly very important going
> > forward
>
> > Cheers
>
> > Tim
>
> > On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
>
> > > Right ...
>
> > > IMHO the key things that we need to have :
>
> > > 1. Typesafe validation (predicates as partial functions sounds very
> > > good to me ;) ... )
> > > 2. Scala objects abstracting forms ... maybe in a way you similar with
> > > what presented here (also this has been mentioned in other posts)
> > > 3. An easy way of obtaining markup from "Form" classes
> > > 4. An easy way of processing the form (this is the easiest part as we
> > > have all we need here)
>
> > > I'll also do some noodling on this and let's come with concrete
> > > proposals.
>
> > > P.S.
> > > Some ideas are currently
> > > here:http://liftweb.net/index.php/Unified_Validation
>
> > > Br's,
> > > Marius
>
> > > On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > > Guys,
>
> > > > Myself and Marius have just been talking over IM about generic ways to
> > > > build validation into lift.
>
> > > > IMHO, right now
[Lift] Re: Validations, Server side controls etc
Actually I just Implemented a small lift app that does typesafe form
validation on server side.
I'll attach it in a bit ... it's just an idea
Br's,
Marius
On Sep 21, 1:08 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
> Sounds good Marius - project wise though we need to address this IMHO;
> as we pick up more users of lift people will want this functionality
> for sure.
>
> I guess we really need to decide at what level we want to apply
> validation - Im not sure that having it tightly coupled to the
> persistence tier (a la rails) is a great idea. Just had a quick look
> at OVal i think a generic approach like that would be good as then
> your just dealing with a single methodology to spec validation
> criterion on any object.
>
> Also, conceptually, a server side representation of a form seems to be
> a different notion to the bind() style we have with snippets. Im not
> sure how we could get it to work in a clean way - would it be an
> abstraction on top of bind() ?
>
> Anyway, great to noodle this as its certainly very important going
> forward
>
> Cheers
>
> Tim
>
> On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
>
> > Right ...
>
> > IMHO the key things that we need to have :
>
> > 1. Typesafe validation (predicates as partial functions sounds very
> > good to me ;) ... )
> > 2. Scala objects abstracting forms ... maybe in a way you similar with
> > what presented here (also this has been mentioned in other posts)
> > 3. An easy way of obtaining markup from "Form" classes
> > 4. An easy way of processing the form (this is the easiest part as we
> > have all we need here)
>
> > I'll also do some noodling on this and let's come with concrete
> > proposals.
>
> > P.S.
> > Some ideas are currently
> > here:http://liftweb.net/index.php/Unified_Validation
>
> > Br's,
> > Marius
>
> > On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > Guys,
>
> > > Myself and Marius have just been talking over IM about generic ways to
> > > build validation into lift.
>
> > > IMHO, right now it seems that there is not any cohesive way to
> > > validate user input (without a bunch of manual coding). One of the
> > > things we talked about is server-side form representation... I wonder
> > > if there is a way to abstract form building so that it was somehow
> > > generic and let you specify field content & type and also the
> > > validation that needs to be applied to that control.
>
> > > This just pure spitballing, but what about something like:
>
> > > class MyDemoFrom extends LiftForm {
> > > def someInput = TextInput(SHtml.text(), Validatons({
> > > // whatever validation here
> > > }))
>
> > > }
>
> > > Or whatever - I just want to try and talk through the idea rather than
> > > propose code at this stage. Even when we extract the validation stuff
> > > from mapper, we'll still need some way of implementing those
> > > validation constraints on controls wont we?
>
> > > Interesting in what people think
>
> > > Cheers
>
> > > Tim
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Sounds good Marius - project wise though we need to address this IMHO;
as we pick up more users of lift people will want this functionality
for sure.
I guess we really need to decide at what level we want to apply
validation - Im not sure that having it tightly coupled to the
persistence tier (a la rails) is a great idea. Just had a quick look
at OVal i think a generic approach like that would be good as then
your just dealing with a single methodology to spec validation
criterion on any object.
Also, conceptually, a server side representation of a form seems to be
a different notion to the bind() style we have with snippets. Im not
sure how we could get it to work in a clean way - would it be an
abstraction on top of bind() ?
Anyway, great to noodle this as its certainly very important going
forward
Cheers
Tim
On Sep 21, 7:44 am, Marius <[EMAIL PROTECTED]> wrote:
> Right ...
>
> IMHO the key things that we need to have :
>
> 1. Typesafe validation (predicates as partial functions sounds very
> good to me ;) ... )
> 2. Scala objects abstracting forms ... maybe in a way you similar with
> what presented here (also this has been mentioned in other posts)
> 3. An easy way of obtaining markup from "Form" classes
> 4. An easy way of processing the form (this is the easiest part as we
> have all we need here)
>
> I'll also do some noodling on this and let's come with concrete
> proposals.
>
> P.S.
> Some ideas are currently here:http://liftweb.net/index.php/Unified_Validation
>
> Br's,
> Marius
>
> On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > Guys,
>
> > Myself and Marius have just been talking over IM about generic ways to
> > build validation into lift.
>
> > IMHO, right now it seems that there is not any cohesive way to
> > validate user input (without a bunch of manual coding). One of the
> > things we talked about is server-side form representation... I wonder
> > if there is a way to abstract form building so that it was somehow
> > generic and let you specify field content & type and also the
> > validation that needs to be applied to that control.
>
> > This just pure spitballing, but what about something like:
>
> > class MyDemoFrom extends LiftForm {
> > def someInput = TextInput(SHtml.text(), Validatons({
> > // whatever validation here
> > }))
>
> > }
>
> > Or whatever - I just want to try and talk through the idea rather than
> > propose code at this stage. Even when we extract the validation stuff
> > from mapper, we'll still need some way of implementing those
> > validation constraints on controls wont we?
>
> > Interesting in what people think
>
> > Cheers
>
> > Tim
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Validations, Server side controls etc
Right ...
IMHO the key things that we need to have :
1. Typesafe validation (predicates as partial functions sounds very
good to me ;) ... )
2. Scala objects abstracting forms ... maybe in a way you similar with
what presented here (also this has been mentioned in other posts)
3. An easy way of obtaining markup from "Form" classes
4. An easy way of processing the form (this is the easiest part as we
have all we need here)
I'll also do some noodling on this and let's come with concrete
proposals.
P.S.
Some ideas are currently here: http://liftweb.net/index.php/Unified_Validation
Br's,
Marius
On Sep 20, 8:46 pm, Tim Perrett <[EMAIL PROTECTED]> wrote:
> Guys,
>
> Myself and Marius have just been talking over IM about generic ways to
> build validation into lift.
>
> IMHO, right now it seems that there is not any cohesive way to
> validate user input (without a bunch of manual coding). One of the
> things we talked about is server-side form representation... I wonder
> if there is a way to abstract form building so that it was somehow
> generic and let you specify field content & type and also the
> validation that needs to be applied to that control.
>
> This just pure spitballing, but what about something like:
>
> class MyDemoFrom extends LiftForm {
> def someInput = TextInput(SHtml.text(), Validatons({
> // whatever validation here
> }))
>
> }
>
> Or whatever - I just want to try and talk through the idea rather than
> propose code at this stage. Even when we extract the validation stuff
> from mapper, we'll still need some way of implementing those
> validation constraints on controls wont we?
>
> Interesting in what people think
>
> Cheers
>
> Tim
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
