[Lift] Re: Making Record a reality [was: Validations, Server side controls etc]
Charles F. Munat wrote: Running Ajax calls between fields for validation is pretty ugly, javascript validation would be better That's what I said. Sorry, Oliver. On re-reading, that sounds a little snippy, but I didn't mean it that way. I just meant that we agree -- after mentioning it as a possibility, I said it would be unnecessary since JavaScript would have to be working anyway. Chas. --~--~-~--~~~---~--~~ 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: Making Record a reality [was: Validations, Server side controls etc]
Hey Chas, No worries, I re-read too and understood the tone of your reply. I'm playing devils advocate on validation to try to get a flexible framework for everyone to use. Ol On 24/09/2008, at 4:07 PM, Charles F. Munat wrote: Charles F. Munat wrote: Running Ajax calls between fields for validation is pretty ugly, javascript validation would be better That's what I said. Sorry, Oliver. On re-reading, that sounds a little snippy, but I didn't mean it that way. I just meant that we agree -- after mentioning it as a possibility, I said it would be unnecessary since JavaScript would have to be working anyway. Chas. --~--~-~--~~~---~--~~ 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: ExtLink not working
Looks to me like a bug. I mean it appears to render the random string generated instead of what createLink returns. Br's, Marius On Sep 24, 12:15 pm, Charles F. Munat [EMAIL PROTECTED] wrote: When I create an external link in the SiteMap thus: Menu(Loc(google, ExtLink(http://google.com/;), Google)) I get an anchor like this: a href=/JQWGEJZP2BM5JTZ030LHGoogle/a But when I click on this, I get a: HTTP ERROR: 404 NOT_FOUND RequestURI=/JQWGEJZP2BM5JTZ030LH I presume this is meant to obscure the external links (though not sure why that would be useful). Shouldn't it redirect? What could be wrong here? Thanks, Chas. --~--~-~--~~~---~--~~ 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] Passing data with JsonHandler?
Hi, I was looking over the JsonHandler stuff and it looks pretty interesting. I thought I'd try it out for a member add page on my latest project, but I can't figure out how to pass state through the snippet. Basically, I have a Team object that I want to add coaches (Member objects) to. I was thinking that I could present a JSON form with a name input so that people could search by name; you'd hit search and the JSON handling would search for members matching the given name and present them as a table of users, each with an Add link next to them. It's the add link that I'm having trouble with. I need to be able to access both the member and the team object when I do the add, but I'm not sure how to pass the Team object along. I have a couple of ideas: 1. Use a stateful snippet - seems easy but it also seems a little heavy for just one method out of many on this snippet class. 2. Add the current team to the session - seems really ugly and is somewhat equivalent to #1 It's early so I may be overthinking this or overlooking something completely obvious. Or am I completely abusing JSON forms? Should I be making this a COMET page instead? For reference, the code follows. Teams.passedTeam is a RequestVar[Can[Team]] that defaults to Empty. Thanks, Derek import JsCmds._ object jsonCoach extends JsonHandler { def performAdd (coach : Member, teamDet : Team) = { val team = Model.merge(teamDet) team.coaches.add(Model.getReference(classOf[Member], coach.id)) Teams.passedTeam(Full(team)) } def apply(in : Any): JsCmd = SetHtml(json_result, in match { case j @ JsonCmd(processForm, _, p: Map[String, _], _) = { val members = Model.findAll[Member](memberLikeUserId, userId - p(name)) val table : NodeSeq = members.flatMap({member = tr td{member.userId}/td td{member.name}/td td{link(viewTeam, () = performAdd(member, Teams.passedTeam.is.open_!), Text(Add))}/td // TODO: This can't be right /tr }) table class=display tr thUser ID/th thName/th th/th /tr { table } /table } case x = bProblem handling search/b }) } def addCoachForm (xhtml : NodeSeq) : NodeSeq = jsonForm(jsonCoach, xhtml) def addCoachHead = head{Script(jsonCoach.jsCmd)}/head --~--~-~--~~~---~--~~ 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: HTTP Client?
Also, when writing immutable objects, constructors suck since they do not encourage object sharing... On Wed, Sep 24, 2008 at 4:36 PM, Kris Nuttycombe [EMAIL PROTECTED]wrote: If you're going to take that approach, why not just make the constructor or factory method ensure that the object is in a valid state to begin with? When I write immutable objects, they usually don't have any setters for that very reason. It doesn't make sense to me that one would construct a PayPal object in an unusable state. Kris On Tue, Sep 23, 2008 at 7:46 PM, David Pollak [EMAIL PROTECTED] wrote: 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 PayPal(sandbox).transactionToken(S.param(tx)).useSSL(true) I'd also update the execute method so that it returns another immutable object that has current state rather than mutating the original PayPal object. Thanks, David Tim Perrett wrote: 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 options like so: /* values can be sanbox or live */ var paypal: PayPal = new PayPal(sandbox) /* self expanitory */ paypal.transactionToken = S.param(tx).openOr() /* set if you need to use SSL (changes port and protocol) */ paypal.useSSL = true /* run the paypal transaction - either with a PDT payload or IPN payload */ paypal.execute(pdt) Anything else / different way of doing it people think I should build in? Tim On Sep 23, 6:24 pm, Derek Chen-Becker [EMAIL PROTECTED] wrote: Tim, you rock :) -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ 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: HTTP Client?
Kris Nuttycombe wrote: If you're going to take that approach, why not just make the constructor or factory method ensure that the object is in a valid state to begin with? When I write immutable objects, they usually don't have any setters for that very reason. It doesn't make sense to me that one would construct a PayPal object in an unusable state. Agreed. The initial builder (no longer using the word Constructor per Viktor's suggestion) should vend an object that can be used. Any additional state (e.g., useSSL) should return a new instance of a mutated object. As to Viktor's suggestion, having a bunch of builder methods on an object rather than an explicit constructor is the right way to go. e.g.: trait PayPal {} object PayPal { def apply(): PayPal = } Kris On Tue, Sep 23, 2008 at 7:46 PM, David Pollak [EMAIL PROTECTED] wrote: 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 PayPal(sandbox).transactionToken(S.param(tx)).useSSL(true) I'd also update the execute method so that it returns another immutable object that has current state rather than mutating the original PayPal object. Thanks, David Tim Perrett wrote: 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 options like so: /* values can be sanbox or live */ var paypal: PayPal = new PayPal(sandbox) /* self expanitory */ paypal.transactionToken = S.param(tx).openOr() /* set if you need to use SSL (changes port and protocol) */ paypal.useSSL = true /* run the paypal transaction - either with a PDT payload or IPN payload */ paypal.execute(pdt) Anything else / different way of doing it people think I should build in? Tim On Sep 23, 6:24 pm, Derek Chen-Becker [EMAIL PROTECTED] wrote: Tim, you rock :) --~--~-~--~~~---~--~~ 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: ExtLink not working
And how did you convert the Loc to an URL? Marius wrote: Looks to me like a bug. I mean it appears to render the random string generated instead of what createLink returns. Br's, Marius On Sep 24, 12:15 pm, Charles F. Munat [EMAIL PROTECTED] wrote: When I create an external link in the SiteMap thus: Menu(Loc(google, ExtLink(http://google.com/;), Google)) I get an anchor like this: a href=/JQWGEJZP2BM5JTZ030LHGoogle/a But when I click on this, I get a: HTTP ERROR: 404 NOT_FOUND RequestURI=/JQWGEJZP2BM5JTZ030LH I presume this is meant to obscure the external links (though not sure why that would be useful). Shouldn't it redirect? What could be wrong here? Thanks, Chas. --~--~-~--~~~---~--~~ 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: ExtLink not working
Sorry, I should have mentioned that I'm using the new group function. When I use builder, it works fine. I notice that the new group function ignores Hidden and doesn't work with ExtLink links. I'm slowly working through it to figure out why, but you probably already know why. Chas. David Pollak wrote: And how did you convert the Loc to an URL? Marius wrote: Looks to me like a bug. I mean it appears to render the random string generated instead of what createLink returns. Br's, Marius On Sep 24, 12:15 pm, Charles F. Munat [EMAIL PROTECTED] wrote: When I create an external link in the SiteMap thus: Menu(Loc(google, ExtLink(http://google.com/;), Google)) I get an anchor like this: a href=/JQWGEJZP2BM5JTZ030LHGoogle/a But when I click on this, I get a: HTTP ERROR: 404 NOT_FOUND RequestURI=/JQWGEJZP2BM5JTZ030LH I presume this is meant to obscure the external links (though not sure why that would be useful). Shouldn't it redirect? What could be wrong here? Thanks, Chas. --~--~-~--~~~---~--~~ 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] About _root_
Hi, I understand from SLS what _root_ does ... but I'm wondering what is the reason behind it in lift. What was the problem? Br's, Marius --~--~-~--~~~---~--~~ 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: About _root_
I believe this is the genesis: http://www.nabble.com/Unfortunate-package-path-conflict-(security-vulnerability-)-tc19618678.html On Sep 24, 4:13 pm, Marius [EMAIL PROTECTED] wrote: Hi, I understand from SLS what _root_ does ... but I'm wondering what is the reason behind it in lift. What was the problem? Br's, Marius --~--~-~--~~~---~--~~ 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] [ANN] Compiling Lift with Scala 2.7.2.RC2 and Eclipse Plugin
DISCLAIMER Nothing is this e-mail is meant to imply that any future public version of Lift will compile with Scala 2.7.2. At the moment, all future public versions of Lift will compile with Scala 2.7.1 until DavidP says otherwise. /DISCLAIMER Here are the instructions for compiling Lift under Scala 2.7.2.RC2 and (optionally) working with the RC2 release of the Eclipse plugin. You will need to compile Lift from source. These instructions were tested with: java -version java version 1.5.0_13 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237) Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing) mvn -version Maven version: 2.0.8 Java version: 1.5.0_13 OS name: mac os x version: 10.5.4 arch: i386 Family: unix git --version git version 1.5.5 (optional) Eclipse SDK Classic Version: 3.4.0 Build id: I20080617-2000 Eclipse Scala Plugin 2.7.2.RC2 #1 Acquire Lift source (If you already have Lift's Git repository, skip to step 2) Execute: git clone git://github.com/dpp/liftweb.git #2 Make sure your Lift source is up-to-date Execute: cd liftweb git checkout master git pull #3 Check out Lift's Scala 2.7.2.RC2 branch git checkout --track -b scala-2.7.2.RC2 origin/scala-2.7.2.RC2 #4 Install Lift without tests mvn clean install -Dmaven.test.skip=true (Tests must be skipped because Scala Specs is not yet compatible with 2.7.2.RC2) You should know have a lift-webkit-0.10-SNAPSHOT.jar in your local Maven repository. Any Maven projects depending on Lift 0.10-SNAPSHOT in Maven will compile with the 2.7.2.RC2 version. This means you need to update the scala.version in the pom.xml file of those Maven projects to 2.7.2-rc2 If you want to go back to using the 2.7.1 version of Lift 0.10-SNAPSHOT, there are two ways you could do that: 1) Delete Lift 0.10-SNAPSHOT from your local Maven repository. The next time you need Lift 0.10-SNAPSHOT, Maven will download it from the public scala-tools.org repository. THE PUBLIC VERSION OF LIFT 0.10-SNAPSHOT WILL CONTINUE TO COMPILE WITH SCALA 2.7.1 2) Alternatively, execute: git checkout master mvn clean install OPTIONAL Instructions for using Eclipse with the 2.7.2.RC2 version of Lift #5 Download and install Eclipse Classic version = 3.4 from http://www.eclipse.org/downloads/ #6 Install Scala Eclipse Plugin version 2.7.2.RC2 with instructions from http://www.scala-lang.org/node/94 #7 Set your Eclipse M2_REPO environment variable to the directory of your local Maven repository Eclipse -- Preferences -- Java -- Build Path -- Classpath Variables -- New Name: M2_REPO Path: Location of your local Maven repository (usually ~/.m2/repository) #8 Prepare your Lift project for Eclipse In the directory for the Lift project you want to import into Eclipse (whether a project that depends on Lift 0.10-SNAPSHOT or Lift 0.10-SNAPSHOT itself), execute: mvn eclipse:eclipse #9 Import project into Eclipse File -- Import -- General -- Existing Projects Into Workspace Then select the root directory of the project you wish to import (WARNING: If you're importing the Lift project itself, be careful. Lift is made up of many sub-projects. Import them one at a time. If you try to import them all at the same time, Eclipse may crash.) /OPTIONAL Enjoy, --j --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---