[Lift] Re: General Questions

Hah ... glad to hear that ! ... there is a lot of fun writing Scala & Lift code. Enjoy it ! On Sep 23, 7:28 am, philip <[EMAIL PROTECTED]> wrote: > Hi Thnx, > > I think the validation is important as mostly a web app that I would > build is forms, validation, database. > > I generally use PHP Ze

[Lift] Re: Ajax/JSON robustness, new menu features ** Breaking Changes **

Nice craft ! On Sep 23, 1:20 am, "David Pollak" <[EMAIL PROTECTED]> wrote: > Folks, > > I've radically enhanced the robustness of Lift's Ajax support. > > Previously, Lift's Ajax calls would silently fail and would not be retried. > > Now, Ajax calls are retried 3 times (tunable in LiftRules.ajax

[Lift] Re: Ajax/JSON robustness, new menu features ** Breaking Changes **

Very cool! The revised menu handling is especially nice. I had hacked together a custom menu builder snippet a while back to work around some things and this looks much better than the junk I came up with. On Mon, Sep 22, 2008 at 4:20 PM, David Pollak <[EMAIL PROTECTED] > wrote: > Folks, > > I've

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

I like the idea of composing lists of filters and validations for fields. Perhaps I'm being naive, but would it make sense to have corresponding validation "components" that can both do the server-side validation as well as spitting out proper javascript for client-side? It seems like it should be

[Lift] Re: General Questions

Hi Thnx, I think the validation is important as mostly a web app that I would build is forms, validation, database. I generally use PHP Zend Framework due to the ability to outsource some work to reduce my workload as PHP programmers are cheap. You could take some ideas from its validation and f

[Lift] Re: Ajax/JSON robustness, new menu features ** Breaking Changes **

Charles, That should work. There was a Hudson build at 5:39 that should have included these changes: http://scala-tools.org/hudson/job/lift/141/ Can you include the file that's not compiling and the error? Thanks, David On Mon, Sep 22, 2008 at 6:51 PM, Charles F. Munat <[EMAIL PROTECTED]> wro

[Lift] Re: Ajax/JSON robustness, new menu features ** Breaking Changes **

If I want to try these new features, how do I get my app to use the latest and greatest Lift? I tried mvn jetty:run -U, and when that didn't work I blew away .m2 and tried again, but I'm still getting an error that it doesn't recognize LocGroup. This is the dependency in pom.xml:

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

Charles F. Munat wrote: > Sorry, Tim, I wasn't clear. I wasn't arguing for validation to be > specified in the persistence layer. I was just saying that using > annotations -- as JPA allows -- is nice. And it would be nice to do them > in the model, where the validation is right next to the th

[Lift] Re: Ajax/JSON robustness, new menu features ** Breaking Changes **

Wow! This is fantastic. I can't wait to try it out. Thank you very much, David. Chas. David Pollak wrote: > Folks, > > I've radically enhanced the robustness of Lift's Ajax support. > > Previously, Lift's Ajax calls would silently fail and would not be retried. > > Now, Ajax calls are retrie

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

Sorry, Tim, I wasn't clear. I wasn't arguing for validation to be specified in the persistence layer. I was just saying that using annotations -- as JPA allows -- is nice. And it would be nice to do them in the model, where the validation is right next to the thing it validates. Also, I meant

[Lift] Ajax/JSON robustness, new menu features ** Breaking Changes **

Folks, I've radically enhanced the robustness of Lift's Ajax support. Previously, Lift's Ajax calls would silently fail and would not be retried. Now, Ajax calls are retried 3 times (tunable in LiftRules.ajaxRetryCount). The delay between calls is 2 ^ (cnt - 1) seconds. So, the first retry will

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

I agree. I think we should be able to come up with something that is simply another layer in the flow, rather than tying it directly to a persistence layer. Like David said, most of mapper is not directly involved with JDBC, so we should be able to leverage a lot of what's in there to make somethin

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

> I'm sure you already thought of this, but it would be nice to be able to > put the constraints in once and have the code generate both validation > in the persistence layer and client-side JavaScript validation code in > the forms, so the latter degrades gracefully to the former. > > Also, I not

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

one clarification .. by "by which the only benefit that I see is that *this* and MyType are actually of the same type sometimes leading to ease of writing expressions" are really meant that *this* and a that : MyType having the same type can give certain clarity of the expression. Just like SLS ex

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

I'll do some noodling on this ... starting first with understanding of the design intent (which I assume it is founded on *ease of use*) I see that Record follows the same parametrization paradigm ... trait Record[MyType <: Record[MyType]] { self: MyType => ... } or trait MetaRecord[BaseR

[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]

I'm definitely not skilled enough in Scala to be anything more than a drag at this point, but I hope you're going to post this stuff to the list as you go along. I'll do my best to learn it, and maybe my ignorant questions will spark a few ideas in more learned heads. I'm sure you already thou

[Lift] Re: Current Loc

Thank you! I added this to the FAQ on the wiki. Chas. David Pollak wrote: > RequestState.location: Can[Loc] > > > On Sun, Sep 21, 2008 at 4:42 PM, Charles F. Munat <[EMAIL PROTECTED] > > wrote: > > > I seem to remember asking this before, but I can't seem to fi

[Lift] Making Record a reality [was: Validations, Server side controls etc]

Folks, For those who want to help, but are not yet Lift committers, please contact me off-list and let's chat about you contributing to this project. If you're a committer, please look at the the wip-record2-dpp branch. What I've been doing to start is to try to decompose the Mapper and Mapped*

[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 > th

[Lift] Re: Multiple menus and LocStuff

On Sun, Sep 21, 2008 at 5:21 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote: > > It would be useful to me to be able to reuse the Menu.builder function > to build different menus, thus: > > > > > > > > > I'm wondering if it would work to extend LocStuff to include a LinkType > list: > > case cl

[Lift] Re: Current Loc

RequestState.location: Can[Loc] On Sun, Sep 21, 2008 at 4:42 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote: > > I seem to remember asking this before, but I can't seem to find the > answer anywhere and a review of the source code hasn't helped. > > Is there a quick way in a snippet to determine

[Lift] Re: JPA and enumerations

Looks good. In keeping with the theme of a Library catalog I'm going to rework "Gender" as "Genre" and add things like Mystery, Horror, Comedy, Childrens' , etc. I think I can just put the Money on as a purchase price. Thanks, Derek On Sun, Sep 21, 2008 at 1:19 AM, Oliver Lambert <[EMAIL PROTECT

[Lift] Re: General Questions

On Sep 22, 3:28 pm, philip <[EMAIL PROTECTED]> wrote: > Hi Marius, > > Thanks for the great replys, I'll just focus on one area. > > About the validation error messages, I mean more specifically can I > have the error messages for each For example if someone types a phone number incorrect, but

[Lift] Re: General Questions

In addition to what Marius said: On Sun, Sep 21, 2008 at 11:13 PM, philip <[EMAIL PROTECTED]> wrote: > > Hi, > > I have some questions as I have been developing and reading examples. > > 1. How can I put validation error messages next to the fields > themselves? > This functionality is about 1/2

[Lift] Re: General Questions

Hi Marius, Thanks for the great replys, I'll just focus on one area. About the validation error messages, I mean more specifically can I have the error messages for each 1. How can I put validation error messages next to the fields > themselves? Please see notices/error/warnings. For instance S

[Lift] Re: AbstractMethodError

On Sat, Sep 20, 2008 at 4:27 PM, David Pollak <[EMAIL PROTECTED]> wrote: > Not until the Eclipse plugin is stabilized on its version (2.7.2) and that > version is the same as Lift's version. 2.7.2 final will be with us very soon, and the situation with Eclipse will be exactly as you want it from

[Lift] Re: General Questions

On Sep 22, 9:13 am, philip <[EMAIL PROTECTED]> wrote: > Hi, > > I have some questions as I have been developing and reading examples. > > 1. How can I put validation error messages next to the fields > themselves? Please see notices/error/warnings. For instance S.error("msgid", "an error") and

[Lift] Re: AbstractMethodError

On Sat, Sep 20, 2008 at 4:16 PM, David Pollak <[EMAIL PROTECTED]> wrote: > If you're using Eclipse to compile your project, then you're using Scala > 2.7.2-RC1/2 which has different method signatures than the version that Lift > is compiled against: 2.7.1 > > So, please exit Eclipse, got into your

[Lift] General Questions

Hi, I have some questions as I have been developing and reading examples. 1. How can I put validation error messages next to the fields themselves? 2. Is there any example of use of the controller directory, I saw the directory in one example but no files in it. I understand from a previous ema