[Lift] Re: Image Submit Buttons fail to Submit (in IE)
Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. 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: Image Submit Buttons fail to Submit (in IE)
Browser detection is a really bad idea, and I would recommend avoiding it at all costs. A much better solution is object detection. Here's one pretty good description about why this is so: http://developer.apple.com/internet/webcontent/objectdetection.html Here's another: http://www.quirksmode.org/js/support.html And one more (for the unconvinced :-) http://www.evotech.net/blog/2007/07/browser-detection-versus-object-detection/ Chas. Tim Perrett wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. 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: HTTP Client?
Great feedback - thanks guys!
I'll re-jig the PDT stuff to make it more like your suggestions.
Regarding the IPN pay pal stuff - I was having a think about this and
thought that it would be good to do something along the same lines of
ajax_requst.
For instance, when you configure IPN you have to specify a location on
your server where paypal will send the post data regarding the
transaction - if we had:
/context_path/paypal_gateway
Then we could do all the processing and return an object which had all
the data already assigned onto it. Before I start to right a bunch of
stuff, what do people think? I don't want to pollute LiftServlet
unless I really have to - is there someplace else I can put it, or
would that be most suitable?
Cheers
Tim
On Sep 24, 4:48 pm, David Pollak [EMAIL PROTECTED] wrote:
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: Image Submit Buttons fail to Submit (in IE)
Charles ... this is not only about JS level. One may simply click a link or submit a simple form (with NO JS involved) and lift should probably be aware of browser type it can correct some browser specific idiosyncrasies in the resulting markup. Certain applications may need for instance to detect if a mobile browser is used instead of a PC browser. I don't think there is some other option then user-agent. But user- agent can be used today in lift but I agree that a higher abstraction is needed. P.S. At JS level, yeah object detection sounds really good. Br's, Marius On Sep 26, 12:25 pm, Charles F. Munat [EMAIL PROTECTED] wrote: Browser detection is a really bad idea, and I would recommend avoiding it at all costs. A much better solution is object detection. Here's one pretty good description about why this is so: http://developer.apple.com/internet/webcontent/objectdetection.html Here's another: http://www.quirksmode.org/js/support.html And one more (for the unconvinced :-) http://www.evotech.net/blog/2007/07/browser-detection-versus-object-d... Chas. Tim Perrett wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. 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: Image Submit Buttons fail to Submit (in IE)
On Fri, Sep 26, 2008 at 12:15 PM, Charles F. Munat [EMAIL PROTECTED] wrote: Ah, I forgot that you were talking server-side. Hmm. I'll have to think about this. For mobile browsers, are you talking ones that use WML? (Does anyone still use that?) For something like that, I think you could use the Accept HTTP header. User Agent is going to be very tricky. Perhaps you want to have a more light-weighted page for mobile consumers? But for something like this, shouldn't you send a default button (assuming JS is off), and then a JS script that does the object detection client-side and replaces the button with an image button? I'm not clear -- why do you want to do the detection server-side? Chas. Marius wrote: Charles ... this is not only about JS level. One may simply click a link or submit a simple form (with NO JS involved) and lift should probably be aware of browser type it can correct some browser specific idiosyncrasies in the resulting markup. Certain applications may need for instance to detect if a mobile browser is used instead of a PC browser. I don't think there is some other option then user-agent. But user- agent can be used today in lift but I agree that a higher abstraction is needed. P.S. At JS level, yeah object detection sounds really good. Br's, Marius On Sep 26, 12:25 pm, Charles F. Munat [EMAIL PROTECTED] wrote: Browser detection is a really bad idea, and I would recommend avoiding it at all costs. A much better solution is object detection. Here's one pretty good description about why this is so: http://developer.apple.com/internet/webcontent/objectdetection.html Here's another: http://www.quirksmode.org/js/support.html And one more (for the unconvinced :-) http://www.evotech.net/blog/2007/07/browser-detection-versus-object-d. .. Chas. Tim Perrett wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. Cheers Tim -- 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: Image Submit Buttons fail to Submit (in IE)
It would be nice to have some control over this. I work on a site where we forward users to the iPhone version of the site when they access / and their user agent matches the iPhone (or iPod Touch) user agent. But, we also provide them with a link to view the full version of the site. This is just something to consider. We handle the full version switch through some additional paths we have setup, but I've seen cookie- based implementations of this as well. --Bryan On Sep 26, 7:40 am, Marius [EMAIL PROTECTED] wrote: Very true Viktor. Some mobile terminals like some of Nokia S40 series have both service browsers and web browsers (for some awkward reason). Service browsers even if they are capable of WAP or internet connectivity their support of XHTML is very limited. There is an XHTML-MP standard out there. Br's, Marius On Sep 26, 2:24 pm, Viktor Klang [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 12:15 PM, Charles F. Munat [EMAIL PROTECTED] wrote: Ah, I forgot that you were talking server-side. Hmm. I'll have to think about this. For mobile browsers, are you talking ones that use WML? (Does anyone still use that?) For something like that, I think you could use the Accept HTTP header. User Agent is going to be very tricky. Perhaps you want to have a more light-weighted page for mobile consumers? But for something like this, shouldn't you send a default button (assuming JS is off), and then a JS script that does the object detection client-side and replaces the button with an image button? I'm not clear -- why do you want to do the detection server-side? Chas. Marius wrote: Charles ... this is not only about JS level. One may simply click a link or submit a simple form (with NO JS involved) and lift should probably be aware of browser type it can correct some browser specific idiosyncrasies in the resulting markup. Certain applications may need for instance to detect if a mobile browser is used instead of a PC browser. I don't think there is some other option then user-agent. But user- agent can be used today in lift but I agree that a higher abstraction is needed. P.S. At JS level, yeah object detection sounds really good. Br's, Marius On Sep 26, 12:25 pm, Charles F. Munat [EMAIL PROTECTED] wrote: Browser detection is a really bad idea, and I would recommend avoiding it at all costs. A much better solution is object detection. Here's one pretty good description about why this is so: http://developer.apple.com/internet/webcontent/objectdetection.html Here's another: http://www.quirksmode.org/js/support.html And one more (for the unconvinced :-) http://www.evotech.net/blog/2007/07/browser-detection-versus-object-d. .. Chas. Tim Perrett wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. Cheers Tim -- 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: Image Submit Buttons fail to Submit (in IE)
On Fri, Sep 26, 2008 at 2:16 AM, Tim Perrett [EMAIL PROTECTED] wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. Yes... that's what I'm suggesting. Right now, I think the things we care about on the server side are: - IE (and sometime just IE6) to deal with this image submit idiosyncrasy and other places where IE has different mechanisms for achieving things than do FF, Opera, and Safari/WebKit - The iPhone (Android?) -- it'd be nice to choose different style sheets based on these platforms... especially with a snippet I'd surface the browser detection in S (not SHtml). I'd also have snippets such as: lift:Browser if=IE6, Safari./lift:Browser lift:Browser.choose browser:ie6 something /browser:ie6 browser:iphone Something just for the iphone /browser:iphone /lift:Browser.choose Thanks, David Cheers Tim -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ 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: mixin javascript call
I hope it was pleasant :) On Fri, Sep 26, 2008 at 4:12 AM, Oliver Lambert [EMAIL PROTECTED] wrote: Forget that - brain had gone for a holiday. On 26/09/2008, at 12:04 PM, Oliver wrote: Hi Say I want to have a onMouseOver call a javascript function - How? // this doesnt work - I want to output goLite(this.form.name,this.name), not goLite(this.form.name,this.name) submit(?(mySubmit), redirectTo(/wherever)) % (onMouseOver - goLite( this.form.name,this.name) ) cheers Oliver --~--~-~--~~~---~--~~ 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: Image Submit Buttons fail to Submit (in IE)
Not the most popular option out there but I generally detect IE6 from the agent string and redirect to the Get Firefox page ;) On Fri, Sep 26, 2008 at 3:51 AM, Marius [EMAIL PROTECTED] wrote: Charles ... this is not only about JS level. One may simply click a link or submit a simple form (with NO JS involved) and lift should probably be aware of browser type it can correct some browser specific idiosyncrasies in the resulting markup. Certain applications may need for instance to detect if a mobile browser is used instead of a PC browser. I don't think there is some other option then user-agent. But user- agent can be used today in lift but I agree that a higher abstraction is needed. P.S. At JS level, yeah object detection sounds really good. Br's, Marius On Sep 26, 12:25 pm, Charles F. Munat [EMAIL PROTECTED] wrote: Browser detection is a really bad idea, and I would recommend avoiding it at all costs. A much better solution is object detection. Here's one pretty good description about why this is so: http://developer.apple.com/internet/webcontent/objectdetection.html Here's another: http://www.quirksmode.org/js/support.html And one more (for the unconvinced :-) http://www.evotech.net/blog/2007/07/browser-detection-versus-object-d... Chas. Tim Perrett wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. 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: Image Submit Buttons fail to Submit (in IE)
Marius wrote: +1. So is anyone taking ownership on this? ... I could add this support within a week or two maybe. I'd rather you continue to work on the Record/Field stuff. Can we get another taker on this project? Tyler... are you too busy with the book? Jorge... got time? Someone else? Br's, Marius On Sep 26, 6:54 pm, David Pollak [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 2:16 AM, Tim Perrett [EMAIL PROTECTED] wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. Yes... that's what I'm suggesting. Right now, I think the things we care about on the server side are: - IE (and sometime just IE6) to deal with this image submit idiosyncrasy and other places where IE has different mechanisms for achieving things than do FF, Opera, and Safari/WebKit - The iPhone (Android?) -- it'd be nice to choose different style sheets based on these platforms... especially with a snippet I'd surface the browser detection in S (not SHtml). I'd also have snippets such as: lift:Browser if=IE6, Safari./lift:Browser lift:Browser.choose browser:ie6 something /browser:ie6 browser:iphone Something just for the iphone /browser:iphone /lift:Browser.choose Thanks, David Cheers Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Collaborative Task Managementhttp://much4.us Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ 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: Image Submit Buttons fail to Submit (in IE)
Cool. On Sep 26, 7:40 pm, David Pollak [EMAIL PROTECTED] wrote: Marius wrote: +1. So is anyone taking ownership on this? ... I could add this support within a week or two maybe. I'd rather you continue to work on the Record/Field stuff. Can we get another taker on this project? Tyler... are you too busy with the book? Jorge... got time? Someone else? Br's, Marius On Sep 26, 6:54 pm, David Pollak [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 2:16 AM, Tim Perrett [EMAIL PROTECTED] wrote: Am I being dumb here - could we not just run some checks on the user- agent header and respond appropriately? It would be very cool if SHtml was browser aware. Yes... that's what I'm suggesting. Right now, I think the things we care about on the server side are: - IE (and sometime just IE6) to deal with this image submit idiosyncrasy and other places where IE has different mechanisms for achieving things than do FF, Opera, and Safari/WebKit - The iPhone (Android?) -- it'd be nice to choose different style sheets based on these platforms... especially with a snippet I'd surface the browser detection in S (not SHtml). I'd also have snippets such as: lift:Browser if=IE6, Safari./lift:Browser lift:Browser.choose browser:ie6 something /browser:ie6 browser:iphone Something just for the iphone /browser:iphone /lift:Browser.choose Thanks, David Cheers Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Collaborative Task Managementhttp://much4.us Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ 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] mysterious script
In my HTML output there is a script that begins: // ![CDATA[ var lift_ajaxQueue = []; var lift_ajaxInProcess = null; var lift_ajaxShowing = false; var lift_ajaxRetryCount = 3 Is there an easy way to make this download as a separate .js file instead of inline? Or to suppress it if I'm not using AJAX at all? BTW, the script element on this script needs a type=text/javascript attribute or it fails validation. 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: mysterious script
Is there an easy way to make this download as a separate .js file instead of inline? Or to suppress it if I'm not using AJAX at all? Having it inline decreases the number of requests the browser must make. On Fri, Sep 26, 2008 at 4:38 PM, Charles F. Munat [EMAIL PROTECTED] wrote: In my HTML output there is a script that begins: // ![CDATA[ var lift_ajaxQueue = []; var lift_ajaxInProcess = null; var lift_ajaxShowing = false; var lift_ajaxRetryCount = 3 Is there an easy way to make this download as a separate .js file instead of inline? Or to suppress it if I'm not using AJAX at all? BTW, the script element on this script needs a type=text/javascript attribute or it fails validation. 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: lift:surround and multiple templates
I also lost half a day with this error. Is this rule at least documented anywhere? Regards, Mateusz On Thu, Sep 25, 2008 at 9:38 PM, Charles F. Munat [EMAIL PROTECTED] wrote: Ah, ha! I knew it had to be something simple like that. Good to know that hidden-templates can't reuse the names of directories. Thanks! Chas. David Pollak wrote: Charles, The admin template was conflicting with the /admin/ directory. Change the name of the template to admin2.html rather than admin.html and change your 'with=admin' to 'with=admin2' and it'll work. Thanks, David Charles F. Munat wrote: I changed the calling template to (exactly): lift:surround with=admin at=content/ I changed admin.html to (exactly): html/ I did mvn clean and mvn jetty:run -U. I get the same error: Exception occured while processing / Message: java.lang.IllegalArgumentException: line 6 does not exist scala.io.Source.getLine(Source.scala:280) scala.io.Source.report(Source.scala:368) scala.io.Source.reportError(Source.scala:355) scala.io.Source.reportError(Source.scala:344) scala.xml.parsing.MarkupParser$class.reportSyntaxError(MarkupParser.scala:1113) net.liftweb.util.PCDataXmlParser.reportSyntaxError(PCDataMarkupParser.scala:77) scala.xml.parsing.MarkupParser$class.reportSyntaxError(MarkupParser.scala:1117) net.liftweb.util.PCDataXmlParser.reportSyntaxError(PCDataMarkupParser.scala:77) scala.xml.parsing.MarkupParser$class.document(MarkupParser.scala:186) net.liftweb.util.PCDataXmlParser.document(PCDataMarkupParser.scala:77) net.liftweb.util.PCDataXmlParser$.apply(PCDataMarkupParser.scala:88) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1$$anonfun$apply$49.apply(LiftSession.scala:1036) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1$$anonfun$apply$49.apply(LiftSession.scala:1036) net.liftweb.util.Full.flatMap(Can.scala:266) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1.apply(LiftSession.scala:1036) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1.apply(LiftSession.scala:1036) scala.Function1$$anonfun$andThen$1.apply(Function1.scala:48) scala.Stream$class.flatMap(Stream.scala:430) scala.List$$anon$1.flatMap(List.scala:1307) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$class.append(Stream.scala:255) scala.List$$anon$1.append(List.scala:1307) scala.Stream$class.flatMap(Stream.scala:435) scala.List$$anon$1.flatMap(List.scala:1307) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$class.append(Stream.scala:255) scala.List$$anon$1.append(List.scala:1307) scala.Stream$class.flatMap(Stream.scala:435) scala.List$$anon$1.flatMap(List.scala:1307) scala.List$$anon$1.flatMap(List.scala:1307) net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:35) net.liftweb.util.Helpers$.first(Helpers.scala:26) net.liftweb.http.TemplateFinder$.findAnyTemplate(LiftSession.scala:1036) net.liftweb.http.LiftSession.findTemplate(LiftSession.scala:509) net.liftweb.http.LiftSession.findAndMerge(LiftSession.scala:819) net.liftweb.http.LiftSession.net $liftweb$http$LiftSession$$processSurroundElement(LiftSession.scala:813) net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:653) net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:647) scala.PartialFunction$$anon$1.apply(PartialFunction.scala:38) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$35.apply(LiftSession.scala:671) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$35.apply(LiftSession.scala:671) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:24) net.liftweb.http.S$.setVars(S.scala:589) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1.apply(LiftSession.scala:671) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1.apply(LiftSession.scala:668) scala.Seq$class.flatMap(Seq.scala:267) scala.xml.NodeSeq.flatMap(NodeSeq.scala:34) net.liftweb.http.LiftSession.processSurroundAndInclude(LiftSession.scala:667) net.liftweb.http.LiftSession$$anonfun$8.apply(LiftSession.scala:344) net.liftweb.http.LiftSession$$anonfun$8.apply(LiftSession.scala:344) net.liftweb.util.Full.map(Can.scala:264) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:344) net.liftweb.http.LiftServlet.net $liftweb$http$LiftServlet$$dispatchStatefulRequest(LiftServlet.scala:222) net.liftweb.http.LiftServlet$$anonfun$1.apply(LiftServlet.scala:164)
[Lift] Re: mysterious script
Charles F. Munat wrote: In my HTML output there is a script that begins: // ![CDATA[ var lift_ajaxQueue = []; var lift_ajaxInProcess = null; var lift_ajaxShowing = false; var lift_ajaxRetryCount = 3 Is there an easy way to make this download as a separate .js file instead of inline? Or to suppress it if I'm not using AJAX at all? I'll add making it optional (although it's required if there's any Ajax on the page). I thought about making it a separate JS request that can be made on /classpath This functionality is new and I'm still looking for the best place to put it. BTW, the script element on this script needs a type=text/javascript attribute or it fails validation. What validator? 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: mysterious script
Daniel Green wrote: Is there an easy way to make this download as a separate .js file instead of inline? Or to suppress it if I'm not using AJAX at all? Having it inline decreases the number of requests the browser must make. True. But that's one hit and then it's cached. Putting it in the HTML not only mixes the two (which I prefer to avoid when possible), but forces the user to re-download that script on every page, even when there's no AJAX on the page. Actually, what I prefer is to have no JS at all in my HTML code (and that includes event handlers). I'd rather link to a script and have the script use the DOM to assign the event handlers to the code. Then if the script isn't downloaded for any reason, the code is nice and clean. And multiple JS scripts (or CSS stylesheets) could be gzipped up dynamically by Lift into a single gz file and served that way -- much faster -- you only have the single latency. 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: lift:surround and multiple templates
Done. http://liftweb.net/index.php/LiftTags#surround Chas. Mateusz Fiołka wrote: I also lost half a day with this error. Is this rule at least documented anywhere? Regards, Mateusz On Thu, Sep 25, 2008 at 9:38 PM, Charles F. Munat [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ah, ha! I knew it had to be something simple like that. Good to know that hidden-templates can't reuse the names of directories. Thanks! Chas. David Pollak wrote: Charles, The admin template was conflicting with the /admin/ directory. Change the name of the template to admin2.html rather than admin.html and change your 'with=admin' to 'with=admin2' and it'll work. Thanks, David Charles F. Munat wrote: I changed the calling template to (exactly): lift:surround with=admin at=content/ I changed admin.html to (exactly): html/ I did mvn clean and mvn jetty:run -U. I get the same error: Exception occured while processing / Message: java.lang.IllegalArgumentException: line 6 does not exist scala.io.Source.getLine(Source.scala:280) scala.io.Source.report(Source.scala:368) scala.io.Source.reportError(Source.scala:355) scala.io.Source.reportError(Source.scala:344) scala.xml.parsing.MarkupParser$class.reportSyntaxError(MarkupParser.scala:1113) net.liftweb.util.PCDataXmlParser.reportSyntaxError(PCDataMarkupParser.scala:77) scala.xml.parsing.MarkupParser$class.reportSyntaxError(MarkupParser.scala:1117) net.liftweb.util.PCDataXmlParser.reportSyntaxError(PCDataMarkupParser.scala:77) scala.xml.parsing.MarkupParser$class.document(MarkupParser.scala:186) net.liftweb.util.PCDataXmlParser.document(PCDataMarkupParser.scala:77) net.liftweb.util.PCDataXmlParser$.apply(PCDataMarkupParser.scala:88) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1$$anonfun$apply$49.apply(LiftSession.scala:1036) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1$$anonfun$apply$49.apply(LiftSession.scala:1036) net.liftweb.util.Full.flatMap(Can.scala:266) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1.apply(LiftSession.scala:1036) net.liftweb.http.TemplateFinder$$anonfun$findAnyTemplate$1.apply(LiftSession.scala:1036) scala.Function1$$anonfun$andThen$1.apply(Function1.scala:48) scala.Stream$class.flatMap(Stream.scala:430) scala.List$$anon$1.flatMap(List.scala:1307) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$class.append(Stream.scala:255) scala.List$$anon$1.append(List.scala:1307) scala.Stream$class.flatMap(Stream.scala:435) scala.List$$anon$1.flatMap(List.scala:1307) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$$anonfun$flatMap$1.apply(Stream.scala:435) scala.Stream$class.append(Stream.scala:255) scala.List$$anon$1.append(List.scala:1307) scala.Stream$class.flatMap(Stream.scala:435) scala.List$$anon$1.flatMap(List.scala:1307) scala.List$$anon$1.flatMap(List.scala:1307) net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:35) net.liftweb.util.Helpers$.first(Helpers.scala:26) net.liftweb.http.TemplateFinder$.findAnyTemplate(LiftSession.scala:1036) net.liftweb.http.LiftSession.findTemplate(LiftSession.scala:509) net.liftweb.http.LiftSession.findAndMerge(LiftSession.scala:819) net.liftweb.http.LiftSession.net http://net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$processSurroundElement(LiftSession.scala:813) net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:653) net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:647) scala.PartialFunction$$anon$1.apply(PartialFunction.scala:38) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$35.apply(LiftSession.scala:671) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$35.apply(LiftSession.scala:671) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:24) net.liftweb.http.S$.setVars(S.scala:589) net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1.apply(LiftSession.scala:671)
[Lift] Re: mysterious script
David Pollak wrote: BTW, the script element on this script needs a type=text/javascript attribute or it fails validation. What validator? The W3C validator for XHTML: http://validator.w3.org/ BTW, if you use Firefox you can add the Web Developer Plugin: https://addons.mozilla.org/en-US/firefox/addon/60 Which gives you a toolbar full of extremely useful controls, including the ability to validate *local* html and css (and even accessibility). I could not work without this toolbar. (The other absolute necessity is Firebug: https://addons.mozilla.org/en-US/firefox/addon/1843 ) 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: HTTP Client?
Given Lift's focus on security I envisioned that the POST URL would
contain a random element, to reduce the threat of fake PayPal
interactions. It is a small risk, but then it is the small risks that
usually allow a hacker in, eventually.
David said there was support for per session dispatch, which would
mean that URL could be set up before calling PayPal. Once the session
ended, or the transaction, you would remove the URL support after
PayPal responded, or not...
I would favour the PayPal support being able to live independently of
other lift modules, with some (one) StatefulSnippets as an example?
Marc
On 26/09/2008, at 7:34 PM, Tim Perrett wrote:
Great feedback - thanks guys!
I'll re-jig the PDT stuff to make it more like your suggestions.
Regarding the IPN pay pal stuff - I was having a think about this and
thought that it would be good to do something along the same lines of
ajax_requst.
For instance, when you configure IPN you have to specify a location on
your server where paypal will send the post data regarding the
transaction - if we had:
/context_path/paypal_gateway
Then we could do all the processing and return an object which had all
the data already assigned onto it. Before I start to right a bunch of
stuff, what do people think? I don't want to pollute LiftServlet
unless I really have to - is there someplace else I can put it, or
would that be most suitable?
Cheers
Tim
On Sep 24, 4:48 pm, David Pollak [EMAIL PROTECTED] wrote:
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: Weird RequestVar behavior (or something else?)
Well, I figured out what's going on. RequestVar and SessionVar depend upon their *class name* for uniqueness. So, you can't just create a RequestVar instance and expect uniqueness, and in fact if you create a RequestVar as a member of a reusable superclass like my JNDIResource, even with a declaration like object foo extends RequestVar, it will be treated as the same instance in all of the subclasses. If it's created as an anonymous class, it just gets a name like DeclaringClass$$anon$1, the same class name for each instance. BLEAH. This violated my expectations on a number of levels, and cost me several hours of hunting to figure out. I guess that if one wants to create some abstraction that simplifies the setup of some class of RequestVar instances, the only way to do so is to ensure that this abstraction is itself abstract. Of course, if someone goes to extend your abstraction, they have to know that *their* abstraction also must be abstract and never instantiated directly lest they get name collisions... This all seems far too complicated for what RequestVar is doing - associating a variable with the request handling lifecycle in a typesafe manner, though I now understand why it was done this way. So, would it break things to add some random salt to the variable name that's being mapped into that hash? I can work around the issue, I think, but it would be nice if the behavior wasn't quite so unexpected. Kris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
